Version 2.1.14.0: se quita PatchAsyncSBA; UpdateCreateCreditNotes usa PatchNoContentAsync (PATCH exitoso = 204 sin cuerpo)

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -10,7 +10,7 @@ comprimido (versión antigua)**.
 
 ## Versión y control de versiones
 
-- **Versión actual: 2.1.13.0** (rama `limpieza-2.1.8.0`; `main` = 2.1.7.0) (`Net.Business.Services.csproj`: `Version`,
+- **Versión actual: 2.1.14.0** (rama `limpieza-2.1.8.0`; `main` = 2.1.7.0) (`Net.Business.Services.csproj`: `Version`,
   `AssemblyVersion`, `FileVersion`). Cada versión tiene su commit; al publicar
   se sube la versión (ver `publicar.ps1`).
 - **Git**: rama `main`, remoto `origin` =
@@ -59,7 +59,7 @@ transferencias siempre, sin depender de `Notificacion`. Detalle y tabla en
 - **v2.1.5.0 — log del JSON enviado al Service Layer cuando SAP lo rechaza**
   (cualquier documento, no solo la NC): `ConnectionServiceLayer` llama a
   `ErrorLogger` (asignado en `Startup` a `Net.Data/HelperData/Log/HelperLogServiceLayer.AddError`)
-  en los fallos de `PostAsync`, `PatchAsyncSBA` y `PatchNoContentAsync`. Guarda en
+  en los fallos de `PostAsync` y `PatchNoContentAsync` (hasta la 2.1.13.0 también `PatchAsyncSBA`). Guarda en
   `ITC_WMS_SAP.ITCA_LOG_INTEGRACION`: `ORIGEN = "ServiceLayer"`,
   `PROCESO = "ServiceLayer Error"`, `NRO_ORDEN` = ruta del recurso (p. ej.
   `CreditNotes`), `DOCENTRY` = `BaseEntry` de la primera línea del JSON (factura o
@@ -145,6 +145,12 @@ transferencias siempre, sin depender de `Notificacion`. Detalle y tabla en
   la NC estaban copiados en Picking DESPACHO, Picking PICKING (estado 13) y Recibo Devolución; ahora están en
   `Net.Data/ServicesLayer/CreditNotes/CabeceraNotaCredito.Completar` (con comentarios de la regla de la 2.1.7.0).
   Cada llamador pasa los datos de su origen (factura o, en Recibo sin factura, la solicitud de devolución).
+- **v2.1.14.0 — se quitó `PatchAsyncSBA`**: su único llamador (`CreditNotesRepository.UpdateCreateCreditNotes`, que agrega
+  a la NC las referencias de las transferencias automáticas) usa ahora `PatchNoContentAsync`. En el Service Layer un PATCH
+  exitoso es un `204` sin cuerpo; `PatchAsyncSBA` devolvía `null` en ese caso (y en cualquier error de red) y el llamador
+  lo tomaba como fallo. Ahora el éxito es éxito y un rechazo de SAP lanza su mensaje (se captura y devuelve como error;
+  `Crear` sigue ignorando el resultado). Sigue sin reintentar el 401 (hace login antes de cada llamada). Los docs de
+  `docs/PORTE_FUNCIONALIDAD_NUEVA.md` y `docs/SOLICITUD_TRANSFERENCIA.md` mencionan `PatchAsyncSBA` como historia del porte.
 - Sin probar contra SAP: confirmar con la factura 292410 que SAP devuelve
   `BaseType`/`BaseEntry` en las líneas y `BatchNumbers` en las de la Entrega.
 
@@ -197,8 +203,6 @@ Picking, columna `HORA` en `B_Log`. Lo que **no** se trajo: `Chatbots` y
 
 - `BE_ResultadoTransaccion<T>.NombreEstacion`: setter con recursión infinita
   (bomba de tiempo; hoy nada lo asigna).
-- `ConnectionServiceLayer.PatchAsyncSBA<T>`: con un `204` real devuelve `null`
-  sin marcar éxito.
 - El cliente HTTP `bypass-ssl-validation` acepta cualquier certificado TLS hacia
   el Service Layer (se quitó el método `ValidarCertificado`, que no se usaba).
 - `appsettings.json` (fuera de git, en `.gitignore`) contiene credenciales