Mapeos de referencia

El módulo se entrega con ocho mapeos preparados que cubren los casos que más se piden. Sirven como punto de partida y, sobre todo, como ejemplo de cómo se declara uno nuevo.

Los ocho que vienen de serie#

Todos se entregan activos salvo el 60, y todos con el comportamiento prudente ante nodo existente: rellenar sólo si está vacío.

Por qué algunos están limitados a 3.2.2#

ReceiverContractReference y ReceiverTransactionReference sólo existen a nivel de cabecera a partir de Facturae 3.2.2. A nivel de línea existen desde antes, y por eso los mapeos 70 y 80 no llevan límite de versión.

Si la empresa emite en una versión anterior, los mapeos de cabecera se ignoran sin error y los de línea siguen funcionando. Es el comportamiento buscado: la misma configuración vale para empresas que emiten en versiones distintas.

Por qué el mapeo 60 viene desactivado#

a3ERP ya emite el número de expediente en el FileReference de cada línea, a partir del campo correspondiente de la cabecera. El mapeo 60 lo añadiría además en la cabecera del documento.

Actívalo sólo si el organismo receptor lo exige ahí. Activarlo «por si acaso» duplica el dato en el fichero.

El nodo intermedio del periodo#

Los mapeos 30 y 40 son dos reglas independientes que apuntan al mismo nodo padre, InvoiceIssueData/InvoicingPeriod, que no existe en el XML que genera a3ERP. El módulo lo crea en la posición que exige el esquema y cuelga de él las dos fechas.

Es el patrón a seguir cuando el dato de destino vive bajo un nodo agrupador: no hay que declarar el agrupador, basta con nombrarlo en la ruta del padre.

Cargar los mapeos por defecto#

Se entregan como script en la carpeta sql de la extensión, para ejecutar sobre la base de datos de la empresa —no sobre la de sistema— después de aplicar el diccionario.

El script es idempotente: puede ejecutarse varias veces sin duplicar filas, y no modifica los mapeos existentes. Si en la instalación se ajustó alguno, se respeta tal como está. La identidad de un mapeo, a estos efectos, es la combinación de nivel, nodo padre, nodo y rango de versiones, que es la misma que impone el índice único de la tabla.

Al terminar informa de cuántas filas insertó y lista el contenido de la tabla, que sirve de verificación inmediata.

Añadir un mapeo nuevo#

El caso típico: el organismo receptor pide un dato que no está en la lista.

1. Localizar el nodo de destino en el esquema. Hay que saber su nombre exacto, de qué nodo cuelga, qué longitud admite y desde qué versión de Facturae existe. Ese último dato es el que decide si hay que acotar el mapeo por versión.

2. Decidir de dónde sale el valor. Si ya existe en la factura, se usa esa columna. Si no, lo habitual es aprovechar una de las columnas que añade el diccionario, siempre que el tipo y la longitud encajen.

3. Dar de alta la fila en la tabla de mapeos, desde tablas adicionales. Conviene dejar la descripción clara: es lo que se lee al revisar la configuración meses después.

4. Salir y volver a entrar en la empresa. Los mapeos se leen al entrar. Y mirar el aviso de arranque: si el campo de origen no existe o el nodo está vetado, se informa ahí y el mapeo queda descartado.

5. Emitir una factura de prueba y comprobar el nodo en el XML. Con la traza en nivel Debug queda registrado si el mapeo se aplicó o por qué se omitió.

Cuándo un mapeo no basta#

Antes de prometer al cliente que su requisito se resuelve con una fila, conviene comprobar que encaja en lo que el módulo sabe hacer: copiar el valor de una columna existente a un nodo previsto por el esquema.

Encaja bien, y se resuelve configurando:

• El dato ya está en una columna de la factura, propia de a3ERP o añadida por un diccionario.
• El destino es un nodo que el esquema de Facturae contempla.
• Basta con copiarlo, convirtiendo el tipo y aplicando un formato de fecha o de número.
• Sólo aplica desde cierta versión de Facturae, o sólo hasta cierta versión.

No encaja, y necesita un desarrollo aparte:

Ninguna de estas es descabellada, y todas son abordables como módulo a medida. Lo que no conviene es intentar forzarlas con mapeos ni prometerlas como configuración: lo razonable es una consultoría previa que concrete el dato, su origen, quién lo introduce y qué debe ocurrir cuando falta.

Lo que no se puede mapear#

Los nodos con relevancia fiscal están vetados por código y el veto no es configurable. Están enumerados en el artículo de configuración.