FEGW-GPT · Módulo fiscal

Casos de uso
CAE / CAEA · POS ↔ Gateway ↔ ARCA

El POS siempre envía la misma identidad comercial — sucursal + nroPos + nroTicket — y el Gateway resuelve la autorización. Según cómo responda ARCA y si el POS llega a ver la respuesta, el intercambio cae en uno de cinco casos. Lo que el POS recibe siempre tiene la misma forma: nro de comprobante, tipo de autorización (CAE o CAEA) y nro de PV.

Modelo de comportamiento. Estos cinco casos describen el comportamiento esperado del flujo POS↔Gateway↔ARCA, no el estado actual del código. El fallback automático CAE→CAEA y la consulta de reintento del POS son parte del diseño objetivo; ver ¿Quién decide? para qué está implementado hoy y qué no.

Caso	Camino CAE *	Camino CAEA *	¿POS ve la respuesta?	El POS termina con
A	OK	—	Sí	comprobante CAE + tipo CAE + PV CAE
B	Error	OK	Sí	comprobante CAEA + tipo CAEA + PV CAEA
C	OK	—	No → reconsulta	comprobante CAE + tipo CAE + PV CAE
D	Error	OK	No → reconsulta	comprobante CAEA + tipo CAEA + PV CAEA
E	Error	Error	Sí (error)	error · sin comprobante

* Cada «camino» abarca consulta del último comprobante + solicitud del CAE/CAEA, ambas contra ARCA. Si falla cualquiera de las dos, ese camino se considera fallido: si es el camino CAE, se intenta CAEA; si es el camino CAEA, termina en error.

El mapeo del POS: PV CAE y PV CAEA

¿De dónde saca el Gateway qué punto de venta usar? De la configuración del POS. Cada POS registrado tiene asociados dos puntos de venta fiscales distintos: uno para CAE (online) y otro para CAEA (contingencia). El POS interno y los PV fiscales son cosas separadas.

Por qué importa. Cuando el POS factura un ticket, el Gateway resuelve la identidad comercio + sucursal + nroPos y de ahí obtiene el PV CAE y el PV CAEA. Con ese PV (según vaya por CAE o por CAEA) y el tipo de comprobante, consulta el último número. El nroPos interno no viaja a ARCA; lo que ARCA conoce es el PV fiscal.

Jerarquía comercio → sucursal → POS, y los dos PV fiscales que cuelgan de cada POS.

Tabla pos (campos relevantes para la numeración):

Campo	Qué es
`nro`	Número interno del POS. Identidad comercial junto con sucursal y ticket. No viaja a ARCA.
`nro_pv_cae`	Punto de venta fiscal para emisión online (CAE). Es el PV que ARCA conoce para este POS en modo normal.
`nro_pv_caea`	Punto de venta fiscal para contingencia (CAEA). Distinto del de CAE.
`pv_cae_valido_arca` · `pv_caea_valido_arca`	Resultado de validar cada PV contra ARCA (más fecha y mensaje del control). Sirve para saber si el PV está habilitado antes de operar.

Ejemplo de un POS configurado:

comercio (cuit)	sucursal nro	POS nro (interno)	nro_pv_cae	nro_pv_caea
30-12345678-9	1	3	1	11

Cómo lo usa el flujo. El POS factura el ticket de sucursal 1 · POS 3. El Gateway resuelve ese POS, toma PV CAE = 1 para pedir el CAE; si cae a contingencia, usa PV CAEA = 11 para la CAEA. La numeración (último + 1) se consulta sobre el PV que corresponda en cada caso.

El POS solo factura el ticket: el Gateway resuelve todo

El POS hace una sola llamada: «facturar este ticket» (sucursal + nroPos + nroTicket). No arma el número de comprobante ni consulta nada. El Gateway se encarga de todo y responde OK con los datos emitidos (CAE o CAEA, según lo que se haya generado) o error.

La numeración es lógica interna del Gateway. Para saber qué cbteNro enviar a ARCA, el Gateway consulta primero el último comprobante emitido y usa último + 1. Esa consulta se hace por tipo de autorización (CAE o CAEA), punto de venta correspondiente y tipo de comprobante. El POS no se entera de esto: solo recibe el resultado final.

El POS factura; el Gateway numera y autoriza por dentro y devuelve el resultado.

Qué hace el POS	Una sola llamada: «facturar ticket». Recibe OK con los datos del comprobante (CAE o CAEA) o error. No conoce ni arma la numeración.
Qué hace el Gateway (interno)	Consulta el último comprobante autorizado (`FECompUltimoAutorizado`), calcula `cbteNro = último + 1`, solicita CAE y, si corresponde, CAEA.
Clave de la numeración	Por tipo de autorización (CAE o CAEA) → PV correspondiente (PV CAE o PV CAEA, son distintos) + tipo de comprobante (`cbteTipo`: Factura A=1, B=6, FCE MiPyME A=201…).
nroTicket	Identidad comercial interna del POS. No se envía a ARCA y no interviene en la numeración fiscal.

Si la consulta del último comprobante falla, es error de ARCA. La consulta es una llamada a ARCA, así que cuenta como parte del camino:

Falla en la etapa CAE (consulta del PV CAE) → no se sigue por CAE, pero el Gateway igual puede pasar a CAEA (consultar el PV CAEA y solicitar la contingencia).
Falla en la etapa CAEA (consulta del PV CAEA) → no hay forma de numerar la contingencia → termina en error · sin comprobante (Caso E).

En los diagramas, el «error / no responde» de cada camino incluye tanto la consulta del último número como la solicitud del CAE/CAEA: si cualquiera de las dos falla, ese camino se considera fallido.

Caso A · CAE OK camino feliz

El Gateway consulta el último comprobante, pide el CAE, ARCA lo autoriza y el POS recibe la respuesta. Sin contingencia.

Caso A — autorización directa.

Caso B · CAE falla → CAEA contingencia

ARCA responde error al CAE (o no responde). El Gateway pasa a contingencia, consulta el último comprobante del PV CAEA, pide la CAEA, ARCA la autoriza y el POS recibe la respuesta con datos de CAEA.

Caso B — el Gateway resuelve la contingencia y devuelve CAEA.

Caso C · CAE OK pero el POS no ve la respuesta → reconsulta

ARCA autorizó el CAE, pero el POS perdió la respuesta (corte, timeout, reinicio). El POS reconsulta al Gateway por la misma identidad comercial y el Gateway le devuelve el CAE que ya tenía.

Caso C — idempotencia: el Gateway devuelve el CAE ya obtenido.

Caso D · CAEA OK pero el POS no ve la respuesta → reconsulta

Como el Caso B (el CAE falló y se autorizó CAEA), pero el POS tampoco vio esa respuesta. Reconsulta al Gateway y recibe los datos de la CAEA ya obtenida.

Caso D — reconsulta sobre una contingencia ya resuelta.

Caso E · CAE falla y CAEA falla sin comprobante

ARCA rechaza (o no responde) tanto el CAE como la CAEA. No hay autorización posible: el POS recibe error y la venta no queda facturada.

Caso E — ni CAE ni CAEA: la venta no puede facturarse electrónicamente.

Sobre B vs E. La diferencia entre el Caso B y el Caso E es únicamente la respuesta de ARCA a la segunda solicitud (la CAEA): si autoriza, hay comprobante de contingencia (B); si también falla, no hay forma de facturar (E).

Resumen comparativo

Sobre B vs E. Ambos arrancan con el camino CAE fallido. Se diferencian en el camino CAEA: si la consulta del último comprobante y la solicitud de CAEA salen OK, hay comprobante de contingencia (B); si falla cualquiera de las dos, no hay forma de facturar (E).

Patrón común a todos los casos. (1) El Gateway resuelve el próximo cbteNro consultando a ARCA el último autorizado por PV + tipo. (2) Pide CAE; si falla la consulta o la solicitud, pasa a CAEA. (3) Si también falla el camino CAEA (consulta o solicitud), termina en error. (4) Si el POS no ve la respuesta, reconsulta por la identidad comercial. (5) El POS siempre termina con nroCbte + tipo de autorización + PV, o con error si ni CAE ni CAEA se pudieron autorizar.