Ficha técnica

Qué hace#

a3ERP genera el XML de factura electrónica con los datos que él conoce. Cuando la administración receptora, el cliente o el punto general de entrada exigen algún dato adicional —una referencia de contrato, un código de expediente, un centro administrativo—, ese dato existe en la factura pero no llega al fichero.

El módulo se engancha al momento en que a3ERP acaba de generar ese XML y, antes de que se entregue, añade los nodos que se hayan configurado, tomando los valores de campos de la cabecera o de las líneas de la factura.

La correspondencia entre campo de origen y nodo de destino es configuración, no programación: se declara en una tabla del diccionario y se puede cambiar por empresa sin tocar el módulo.

Un ejemplo de extremo a extremo#

Un organismo exige la referencia del contrato y el periodo facturado. La factura FV/2026/0341 lleva anotado CTR-2026-0143 en el campo de referencia de contrato de la cabecera, y las fechas 01/01/2026 y 31/03/2026 en los del periodo.

El XML que entrega a3ERP contiene, en el bloque de datos de emisión, sólo lo que el ERP conoce:

<InvoiceIssueData>
  <IssueDate>2026-04-03</IssueDate>
  <InvoiceCurrencyCode>EUR</InvoiceCurrencyCode>
  <TaxCurrencyCode>EUR</TaxCurrencyCode>
  <LanguageName>es</LanguageName>
</InvoiceIssueData>

Y tras pasar por el módulo:

<InvoiceIssueData>
  <IssueDate>2026-04-03</IssueDate>
  <InvoicingPeriod>
    <StartDate>2026-01-01</StartDate>
    <EndDate>2026-03-31</EndDate>
  </InvoicingPeriod>
  <InvoiceCurrencyCode>EUR</InvoiceCurrencyCode>
  <TaxCurrencyCode>EUR</TaxCurrencyCode>
  <LanguageName>es</LanguageName>
  <ReceiverContractReference>CTR-2026-0143</ReceiverContractReference>
</InvoiceIssueData>

Tres cosas a observar. El bloque InvoicingPeriod no existía y lo ha creado el módulo, porque las dos fechas cuelgan de él. Cada nodo se ha insertado en la posición que exige el esquema, no al final: el formato define una secuencia y colocarlos en otro orden invalidaría el fichero. Y lo que ya estaba no se ha tocado.

Alcance: qué se resuelve configurando y qué no#

Es la distinción más importante de todo el artículo, porque determina si una petición del cliente se atiende con una fila en una tabla o con un desarrollo.

El módulo hace una cosa: copiar el valor de una columna existente a un nodo previsto por el esquema de Facturae. De ahí salen sus dos límites.

El destino debe existir en el esquema. No se pueden generar nodos que el formato no contemple, ni en posiciones que su secuencia no admita. Un nodo no reconocido se descarta y se registra.

El origen debe existir como columna. El módulo lee de CABEFACV y LINEFACT, ya sean columnas propias de a3ERP, las que añade este diccionario o las que haya añadido otra extensión. Copia el valor tal cual, con la conversión de tipo y el formato declarados en el mapeo.

Lo que no entra en el alcance:

Todo eso es viable, pero corresponde a un módulo adicional a medida, y conviene precederlo de una consultoría que concrete el requisito: qué dato, de dónde sale, quién y cuándo lo introduce, y qué pasa cuando falta. Conviene decirlo pronto en la implantación, antes de que se dé por supuesto que basta con configurar.

Qué no hace, y por qué importa#

No modifica la factura. No escribe en CABEFACV ni en LINEFACT, ni siquiera en columnas propias añadidas por su diccionario. Sólo lee.

No altera ningún dato con relevancia fiscal del XML. Número y serie, fechas de expedición y operación, identificación fiscal de las partes, importes, impuestos, totales y firma están vetados por código, y ese veto no es configurable. Si un mapeo apunta a uno de esos nodos, se descarta al cargar la configuración y se registra la incidencia.

Es una decisión de diseño tomada por el reglamento de sistemas informáticos de facturación: el fichero que se entrega no puede contradecir lo que el ERP tiene registrado. Si un dato fiscal sale mal, la vía es corregirlo en la factura y volver a emitir.

Requisitos#

Qué se instala#

El instalador despliega la carpeta de extensión con la estructura habitual:

Extensiones\Sofitec\SIT_FACE_EXT\
├── binarios\        la librería, sus dependencias y regDlls.ini
├── diccionarios\DSIT_FACE_EXT\
└── imagenes\

Después hacen falta tres pasos que el instalador no hace y que se detallan en el artículo de instalación: registrar la DLL en la tabla DLLS de cada empresa donde deba actuar, aplicar el diccionario desde a3ERP, y dar de alta la vista SQL de consulta de incidencias.

Qué crea en la base de datos#

Además añade columnas propias a CABEFACV y LINEFACT, que son las que el usuario rellena cuando el dato a enviar no existe ya en la factura. Todas llevan el prefijo SIT_FACE_EXT_ y su descripción empieza por FACe: para distinguirlas de las columnas del ERP y de las de otras extensiones.

Cuándo se ejecuta#

El módulo se suscribe a tres eventos de a3ERP:

Toda la lectura y la escritura ocurren dentro de la transacción del ERP, sobre la conexión que éste facilita.

Configuración#

En SIT_FACE_EXT_CONFIG, una fila por empresa:

El parámetro de truncado es el que más consecuencias tiene. Con T el documento sale, con el valor recortado; con F no sale ninguno, y el usuario recibe un mensaje del ERP que indica qué campo, qué valor, qué longitud y cuál es el límite. Cuál de los dos comportamientos conviene depende de si el dato afectado es relevante para el receptor.

Versiones de Facturae admitidas#

3.1, 3.2, 3.2.1 y 3.2.2. El módulo detecta la versión a partir del espacio de nombres del XML generado y coloca cada nodo en la posición que exige el esquema correspondiente. Ante una versión no reconocida no interviene, y lo registra.

Dónde mirar cuando algo no funciona#

El resultado de cada factura está en la vista SIT_FACE_EXT_V_INCIDENCIAS, con el tipo, la serie, el número, la fecha, el cliente, el estado —O correcto, E error—, el motivo y la fecha de proceso. La forma prevista de consultarla es la vista SQL «Errores XML FACe (Ext)» que se da de alta en el ERP durante la instalación.

La traza está por defecto en C:\Logs, con un fichero por módulo, fecha, usuario y proceso. Subiendo SIT_FACE_EXT_NIVELTRAZA a 1 se registra el detalle de cada decisión: qué mapeo se aplicó, cuál se omitió y por qué.

Si el módulo no parece ejecutarse, la comprobación es el alta en la tabla DLLS de esa empresa concreta: el registro es por empresa, y una empresa nueva no lo hereda.

Límites conocidos#

Las líneas de kit. a3ERP escribe una línea de cabecera de kit y una línea por componente, pero al fichero de factura electrónica sólo emite la del kit. El módulo descarta los componentes para que el emparejamiento entre líneas de la factura y líneas del XML cuadre. Si el recuento no cuadra aun así, no aplica nada en las líneas y lo registra, en lugar de arriesgarse a colocar un dato en la línea equivocada.

Convivencia con VeriFactu. El diseño evita cualquier escritura en facturación y cualquier modificación de nodos fiscales, precisamente para no interferir con el registro de facturación. Queda pendiente de contrastar en una empresa con VeriFactu activo.

Convivencia con otras extensiones. El módulo aísla su traza y resuelve sus dependencias desde su propia carpeta para no interferir con otras extensiones cargadas en el mismo proceso. Pendiente de contrastar en una instalación con varias.