Dos ventas, dos reservas distintas: verificación local antes de firmar el e-CF

Por qué la asignación local merece su propia verificación antes de la firma

Cuando agregas una segunda caja al mismo emisor de e-CF, hay una decisión de ingeniería que ocurre antes de la firma y que determina qué número local recibe cada venta. Esa decisión alimenta al documento con su identificador.

La asignación local no es lo mismo que la serialización del cuerpo del XML (cubierta en otra nota). Tampoco es lo mismo que la reconciliación después de una transmisión sin respuesta. Aquí el foco es anterior: cómo tu conector fiscal reparte identificadores locales entre dos cajas independientes que emiten en paralelo.

Si esa capa no se prueba, el riesgo es claro: firmar un comprobante que otro camino cree libre. Conviene pedir una demostración antes de aceptar el servicio.

Qué le preguntas al proveedor sobre dos cajas y dos ventas simultáneas

Antes de firmar el contrato, pídele a tu proveedor que te muestre, con datos ficticios, qué pasa cuando dos ventas independientes parten al mismo tiempo desde dos cajas distintas. La pregunta concreta es: qué identificador local reserva cada venta.

Conviene pactar antes el esquema. La estructura mínima de un e-NCF, según el §7 del Informe Técnico e-CF v1.0 de la DGII, marzo 2026 (publicación informativa sin validez legal), es la letra E seguida de dos dígitos de tipo y diez dígitos secuenciales. La secuencia es válida desde la autorización hasta el 31 de diciembre del año siguiente; no puede usarse después de su vencimiento.

Como alcance de unicidad recomendado en ingeniería, lo natural es que esa combinación emisor + tipo + secuencia opere como restricción de unicidad, diseñada para detectar y bloquear colisiones según la implementación y revisión acordadas; caja y punto de venta quedan como metadatos para correlacionar la reserva con la venta, no como parte de esa restricción. Esa distinción es materia de diseño, no una garantía instalada.

Conviene también pactar cómo se evitan colisiones cuando dos cajas piden número al mismo instante. Una reserva atómica del lado servidor, pactada por escrito, es una opción: una sola operación que entregue el número y lo persista, no varias intermedias. Si el proveedor te dice que basta un identificador aleatorio por venta, falta control: un UUID no impide que dos cajas pidan el mismo número fiscal si la fuente de verdad de la secuencia no está protegida.

Datos ficticios que sirven para la prueba (y los que no)

La demostración debe correr con etiquetas inventadas, no fiscales. Algo como TEST-A y TEST-B como rótulos locales de caja, y referencias internas que no se parezcan a un e-NCF real. No firmes nada, no llames al servicio web de la DGII, no uses certificados ni credenciales productivas.

Tampoco metas datos reales de clientes, RNC ni montos que se confundan con una factura verdadera. La idea es ejercer la lógica de asignación y restauración del conector con tráfico paralelo, en un ambiente aislado.

Lo que sí puedes acordar con el proveedor es el formato del log o bitácora que va a registrar: qué caja pidió, a qué hora, qué identificador recibió y cómo respondió el servidor. Ese log es la evidencia que vas a revisar después.

Reserva, firma, envío, resultado fiscal y cierre comercial: no son lo mismo

Conviene separar estas fases, porque mezclarlas confunde la decisión de qué número reusar o reasignar. La reserva local es un registro de ingeniería que dice "este número quedó tomado por esta venta"; no es recepción por parte de la DGII, no es aceptación oficial, no es comprobante de cobro. El resultado fiscal lo determina la DGII con sus reglas, no una reserva local exitosa.

Una respuesta local vacía o un identificador ausente no autorizan, por recomendación de ingeniería, a reusar un número ni a emitir otro comprobante en su lugar.

Qué observar en la respuesta del proveedor y qué significa un PASS local

Cuando el proveedor corra la prueba, fíjate en que las dos ventas simultáneas dejen dos reservas distintas y persistidas, cada una ligada a la venta y a la caja que la pidió, para rastrearlas después. Si las dos reservas son distintas, hay un indicio de que la fuente de verdad responde a la concurrencia; la explicación de cómo se protege esa fuente de verdad bajo condiciones de carrera, y la revisión de esas salvaguardas, se piden por separado al proveedor.

Que el log muestre una sola operación entregando y persistiendo el número es una pista útil, pero no basta para afirmar atomicidad bajo todas las condiciones de carrera; la atomicidad se pacta como criterio de aceptación explícito, no se presume solo porque el log se vea limpio. Un UUID por venta tampoco demuestra que la fuente de verdad esté protegida.

Un PASS local dice solo una cosa: los casos que acordaste con el proveedor, ejecutados con datos ficticios, se comportaron como esperabas. Nada más. Un PASS local no significa que la DGII vaya a aceptar tus comprobantes, ni que nunca verás duplicados, ni que tu historial fiscal esté completo. Es una evidencia concreta de que la capa de asignación responde a una concurrencia real, dentro del alcance que definiste.

Restauración del registro local de reservas: por qué copiar contador e historial del mismo punto puede omitir reservas

Hay un segundo escenario que conviene probar. Si tu conector se cae y se restaura desde una copia de seguridad tomada en un instante T, qué pasa con los identificadores reservados entre T y la caída.

Copiar solo el contador no basta, y copiar contador e historial desde la misma copia antigua tampoco garantiza nada: si entre esa copia y la caída se reservaron números nuevos, esos números quedan fuera del archivo restaurado y el sistema puede reusarlos silenciosamente.

Como criterio de ingeniería separado de lo anterior, conviene acordar con tu proveedor una prueba controlada y enteramente sintética sobre el valor único de restaurar autoritativamente. El orden de los pasos importa y debe quedar acordado como criterio de aceptación.

Primero, capturar una instantánea inicial del estado del asignador (por ejemplo, contador y reservas hasta un punto T1 acordado) como punto de partida. Más adelante, con esa instantánea cargada en un ambiente de prueba aislado, se registran dos ventas ficticias independientes desde las cajas TEST-A y TEST-B, usando etiquetas inventadas; esas dos ventas obtienen reservas durables propias, referenciadas por rótulos internos de venta (por ejemplo, VTA-TEST-A-001 y VTA-TEST-B-001), que nada tienen que ver con un e-NCF real, y cada reserva se conserva por separado en un registro autoritativo sintético del propio ambiente de prueba, aislado de cualquier rastro de producción.

En un tercer paso, restaurar la instantánea desactualizada en ese mismo ambiente aislado y comparar contra ese registro autoritativo sintético posterior a T1: comprobar que las reservas durables posteriores se preservan, asignar identificadores distintos no usados, o detener la asignación para investigación si el estado del asignador no se puede reconciliar. En ningún momento se firma, se transmite ni se llama a la DGII; toda la demostración es ficticia y permanece en el ambiente de prueba.

Como consejo de ingeniería, una reserva original no resuelta no debe declararse disponible ni reiniciarse solo porque el contador restaurado haya vuelto atrás: la trazabilidad local exige saber qué pasó con esa reserva antes de liberar su hueco. Cómo se resuelve fiscalmente cada caso queda en manos del proveedor fiscal y del contador, bajo las reglas de la DGII; aquí solo se describe el sentido común de ingeniería que conviene dejar acordado en una checklist de aceptación con tu proveedor antes de salir a producción.

Cómo puede ayudarte Antreva Tech

En Antreva Tech podemos proponerte una revisión técnica acotada para emisores que pasan de una caja a dos o más y quieren una segunda opinión antes de cerrar el contrato o de salir a producción, si tu proveedor fiscal está abierto a una verificación conjunta.

La propuesta, siempre como ingeniería propuesta junto a tu proveedor fiscal existente y no como producto ya instalado, cubre: mapeo del asignador compartido entre los puntos de venta, dejando emisor + tipo + secuencia como restricción de unicidad y caja y punto de venta como metadatos de correlación; un rastro durable de reserva a venta que permita trazabilidad local. Incluye además pruebas sintéticas controladas, en ambiente aislado, que ejerzan dos ventas simultáneas y la restauración desde una copia desactualizada, con el objetivo operativo de dar visibilidad y reducir ambigüedad, no de garantizar ausencia de colisiones.

Esta revisión parte de desarrollo de software a la medida, donde mapeamos tu flujo actual y definimos por escrito los criterios de aceptación. Esta revisión no sustituye el criterio fiscal de la DGII ni el de tu contador. La aceptación del e-CF la determina la DGII; el ciclo de vida de cada número reservado lo manejan tu proveedor fiscal y tu contador.

Si quieres profundizar en la verificación complementaria (serialización del cuerpo del XML antes de firmar), revisa los chequeos de datos a XML antes de firmar un e-CF. Conversa con Antreva Tech para definir el alcance concreto de esta revisión del asignador compartido.

Preguntas frecuentes

¿Un PASS local en la prueba de asignación significa que la DGII va a aceptar el e-CF?

No. El PASS local solo dice que los casos acordados, con datos ficticios, se comportaron como esperabas. La aceptación fiscal la determina la DGII con sus reglas, no una prueba interna de tu conector.

¿Por qué la verificación de dos cajas independientes no se sustituye con solo mirar la pantalla del POS?

Porque con dos cajas en paralelo dos peticiones pueden pedir el mismo número antes de que ninguna haya quedado persistida. La pantalla por sí sola no basta: hace falta observar dos reservas distintas y persistidas en la prueba controlada, y pedir al proveedor que explique y documente las salvaguardas de concurrencia.

¿Restaurar una copia de seguridad del contador equivale a tener un historial fiscal válido?

No. El contador dice hasta dónde llegaste en la numeración; la bitácora local dice qué pasó con cada número reservado. Si solo restauras el contador sin el historial durable completo, o desde una copia antigua, puedes reusar números sin darte cuenta. La bitácora local es evidencia para tu revisión; la aceptación fiscal la emite la DGII, no tu conector.