Eran tres copias (94% a 97% iguales). Se verifico con un servidor simulado
que el resultado es identico al anterior en reintento por 401, 204 sin cuerpo,
rechazo y log de errores. PatchAsyncSBA no se toca.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Sin cambios de comportamiento. Comentarios en Picking, Recibo,
ConnectionServiceLayer, CreditNotesRepository, InvoiceRepository y
RepositoryWrapper.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- ConnectionServiceLayer: ValidarCertificado, Logout, CancelAsyncSBA, DeleteAsyncSBA y throw inalcanzable en PatchAsyncSBA
- HelperDB (SET ejecutaba SQL arbitrario, sin llamadores)
- RepositoryWrapper/IRepositoryWrapper: 11 propiedades que ningun controller usa
- PickingRepository: TotalDetalle_Parcial y _Invoice sin uso; ReciboRepository: SerieOrigen sin uso
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Se mueve de CreditNotesRepository a ConnectionServiceLayer (PostAsync,
PatchAsyncSBA, PatchNoContentAsync) con un hook asignado en Startup.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
PostReOpen deserializaba el cuerpo vacio del 204 a null y fallaba al marcar
Exito, devolviendo "La Factura no se puede reabrir" aunque SAP la reabria.
Picking ahora agrega el mensaje real de SAP a ese error.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>