Identificador

Esta documentación es para todos los web service.

Al llamar al método "registrar" (o "FEAutRequest", "FEAutRequestAFIP", "registrarConNumero", "bregistrar", "bRegistrarConNumero", "sRegistrar", "sRegistrarConNumero", "xRegistrar", "xRegistrarConNumero") debe indicase un tercer argumento "identificador" tipo string (pero en realidad se refiere a un número). Este identificador debería ser único cada vez que se intenta emitir una nueva factura (sugerimos usar un campo "autonumérico" que muchas bases de datos ofrecen o algo basado en la hora del sistema). A continuación reproducimos una parrafo de la documentación de la AFIP para explicar la importancia de este argumento. Tambien es importante leer la documentación referente a reproceso y el Test de lote y reproceso.

Errores de comunicación.

En el diseño de la AFIP se ha previsto que -dada la complejidad actual de las comunicaciones pueden ocurrir interrupciones en la comunicación entre el cliente y y la AFIP; básicamente, el problema podría resumirse al siguiente escenario: el cliente envía una solicitud de factura a la AFIP y se queda esperando una respuesta que no llega, hasta que transcurrido algún tiempo se corta la conexión o se produce una condición de time-out o tiempo agotado.

En ese caso, el cliente no sabrá si la solicitud le llegó a la AFIP y esta asignó un CAE y la falla de comunicación se produjo durante el retorno de la información, o bien si la falla ocurrió durante el envío de la solicitud y simplemente AFIP nunca la recibió.

En el segundo caso, con simplemente enviar una nueva solicitud todo quedaría resuelto, pero en el primer caso, si el cliente envía una nueva solicitud (con un <identificador> nuevo) la factura se volverá a emitir con otro CAE.

Aqui es donde se hace evidente la importancia del "identificador" junto con las propiedades "id" y "reproceso" del control.

AFIP archiva en su base de datos todas las respuestas que devuelve junto con su ID de lote; cuando recibe una nueva solicitud, primeramente verifica si en su base de datos ya tiene archivada una respuesta con es el mismo ID de lote recibido en la solicitud actual, si no la tiene, procede a procesar la solicitud actual normalmente y devuelve la respuesta con la propiedad <reproceso>="N". Si hubiese encontrado en su base de datos una respuesta archivada con el mismo ID de lote de la solicitud actual (aunque los datos de la solicitud actual sean totalmente diferentes), simplemente procedería a devolver la misma respuesta que tiene archivada, pero con la propiedad <reproceso>="S".

De esta descripción surgen algunas conclusiones importantes:

● Es fundamental asegurarse de no repetir accidentalmente el <identificador>.

● Debe archivarse el <identificador> de cada solicitud puesto que que va a ser el único modo de recuperar en caso de error en la comunicación de retorno de la información. Tener en cuenta que será casi imposible recuperar un CAE emitido por AFIP y no recibido por el cliente si no se dispone del <identificador> de la solicitud que dio lugar a la emision de ese CAE originalmente.

● Cuando se corrija un error de datos que motivó un rechazo anterior, debe enviarse un <identificador> nuevo, de lo contrario, se volverá a obtener el mismo error anterior (ver <reproceso>="S"). En caso de confusión de alguno de estos datos, se puede sacar provecho de algunos de los métodos de apoyo del Servicio, por ej.: FEUltNroRequest que devuelve el último <identificador> recibido por AFIP o FERecuperaLastCMPRequest que devuelve el último nro de comprobante aceptado por AFIP para un tipo de comprobante y punto de venta dados. Existen métodos similares para lo otros web service (WSBFE / WSSEG) y WSFEX.