En la tabla de comprobantes del cliente, las columnas resultadoFacturacion y
estadoNotificacionEmail guardaban mensajes genéricos (ej. ERROR:ARCA no disponible
o respuesta invalida). El personal de soporte veía la fila y no podía entender qué había
pasado ni para qué comprobante.
Objetivo: que la fila deje claro en qué etapa falló, para qué comprobante, con qué datos y por qué; y poder seguir el XML enviado/recibido al servidor.
| Archivo | Cambio |
|---|---|
utils/ErrorUtil.java NUEVO |
Arma el mensaje claro ERROR[ETAPA]: <causa real> | Comp:.. Tipo:.. CondIVA:.. Doc:...
Desenvuelve la cadena de excepciones y toma la causa más profunda (no el wrapper). |
service/MainTaskManager.java |
Los 3 puntos de error (CAE / PDF / EMAIL) usan ErrorUtil.describe(...) en lugar de
"ERROR:" + exception.getMessage(). |
ws/SoapTrafficLoggingHandler.java NUEVO |
Handler JAX-WS que vuelca el envelope SOAP (request y response) de cada llamada a un log dedicado. |
ws/GenericWSClient.java |
Engancha el handler en setProperties() — un solo punto, cubre los dos clientes WS. |
utils/Parametros.java |
Nuevo flag soap_traffic y registro del path absoluto del appender TRAFFIC
(evita que el log caiga en system32). |
TiFacturaOnlineSvc.properties |
Appender TRAFFIC → logs\traffic-soap.log (archivo aparte, additivity=false,
no ensucia el log operativo) + soap_traffic=false. |
resultadoFacturacion = ERROR[CAE]: [10243] El campo Condicion IVA receptor no es valido... | Comp:0559-00302591 Tipo:FacturaB CondIVA:Responsable Inscripto Doc:20304...
resultadoFacturacion = Facturado Ok estadoNotificacionEmail = ERROR[EMAIL]: EMAIL_ENVIO_FALLIDO: comprobante 302591 intento 1/1 SMTP 5xx 550 buzon inexistente | Comp:0559-00302591 Tipo:FacturaB CondIVA:Responsable Inscripto Doc:20304...
La factura salió (CAE ok); sólo el mail marca el error, en su propia columna.
El XML enviado y recibido a los WS se escribe en logs\traffic-soap.log
(rotativo, 15 MB × 10). Apagado por defecto: costo cero cuando no se usa.
Se configura en el archivo TiFacturaOnlineSvc.properties (mismo directorio del ejecutable),
en la sección [Conexion al WS], junto a dump_http:
#-------------------------------# # Conexion al WS # #-------------------------------# request_timeout=3000 dump_http=false # Loguea el XML SOAP enviado/recibido a logs\traffic-soap.log (para seguimiento de soporte). soap_traffic=true
Poner soap_traffic=true y reiniciar el servicio para que tome el cambio.
Volver a false cuando no se necesite (el log crece rápido).
/TiFacturaOnlineManagerWS del servidor
TIFacturaOnlineNext, compartido con el POS V1 (C++ embebido, campo resultado = 80 chars).faultstring antes de enviarlo, para proteger el buffer fijo del POS
(PosSafeError / PosFaultCuradorInterceptor).EMAIL_ENVIO_FALLIDO, EMAIL_NO_APROBADO, EMAIL_TEMPLATE_NO_ENCONTRADO,
EMAIL_DIRECCION_INVALIDA…) que pasan la curación intactos y llegan tipados a este servicio.ORA-xxxxx, mantenimiento, stacktrace), la curación colapsa todo al genérico
ARCA no disponible o respuesta invalida. Ese detalle sólo se corrige en el repo Next.Extracción de señal en PosSafeError.esInseguro(): en vez de colapsar al genérico,
extraer un token corto y seguro (≤80 ASCII, una línea, sin markup) del payload:
ORA-\d{5} → AFIP error BD: ORA-06550AFIP respondio HTML no-XMLSAXParseException → Respuesta AFIP no es XML validoAFIP HTTP 503Complemento opcional: ref-id corto (reusar el correlation-id de TrafficMdc) que
apunte a la línea del log server-side con el cuerpo crudo.
Revisar aparte: PosSafeError.MAX = 180 pero el campo del POS es 80 → posible desborde;
evaluar bajar a 80.
NO se pide restaurar trxErrores/getErrores: cambio del tipo compartido y,
por ser lookup read-only, no traería el crudo de los casos "inseguros" (que sólo vive en el log).