El alcance antes del código
El diseño parte del estudio de la normativa, las instrucciones del modelo y las especificaciones técnicas. Antes de desarrollar hay que enumerar los casos incluidos y excluidos, las fuentes que deben verificarse y los puntos en los que la herramienta debe detenerse y solicitar una decisión profesional.
Datos producidos por el ERP
Los inputs típicos incluyen libros de IVA mensuales, liquidaciones, resultados contables, créditos o deudas del período y la lista completa de códigos de IVA utilizados en el ERP. Los formatos pueden ser PDF o Excel, pero deben describirse con precisión: columnas, signos, líneas de total, documentos que deben ignorarse y datos ausentes.
Mapping de tax codes a campos VP
El mapping traduce el lenguaje del ERP al lenguaje de la comunicación. Para cada tax code se definen la naturaleza de la operación, su inclusión o exclusión, el campo VP de destino y las posibles condiciones. Un código nuevo o no reconocido no debe clasificarse automáticamente sin evidencia: debe aparecer entre las anomalías.
- Mapping importable y exportable para conservar la memoria por sociedad.
- Histórico de cambios y decisiones.
- Diagnóstico de códigos sin regla o con regla incompleta.
Resultados y conciliaciones
El resultado no se limita a los campos VP1–VP14. Debe mostrar cómo se ha construido cada importe, qué operaciones lo componen, qué códigos se han excluido y qué diferencias surgen frente a las liquidaciones y la contabilidad. Solo después de estos controles puede generarse el eventual archivo XML o el estado que se utilizará para el envío.
- Conciliación entre libros de IVA y liquidaciones mensuales.
- Conciliación con los resultados contables del período.
- Drill-down desde el campo VP hasta las operaciones subyacentes.
- Lista explícita de exclusiones, anomalías y datos ausentes.
Pruebas ordinarias, casos límite e inputs erróneos
Antes de la publicación se construye una matriz PASS/FAIL. El dataset debe incluir un trimestre limpio, tax codes nuevos, abonos, importes cero, signos inesperados, archivos incompletos y casos poco frecuentes. El resultado esperado se define antes de ver el prototipo.
Revisión y estado del proyecto
La revisión se realiza en una conversación separada a la que se proporcionan el brief, el código y la matriz de pruebas. La petición no consiste en confirmar el resultado, sino en identificar cómo podría estar equivocado. La documentación debe indicar límites, supuestos abiertos, casos no gestionados y condiciones de uso.
Esta página describe el método de diseño aplicado al Generador LIPE, ahora disponible en Tax Automation Lab. La herramienta sigue siendo un instrumento de apoyo: la clasificación de códigos de IVA, la revisión del cuadro VP y la validación del archivo telemático siguen siendo responsabilidad del profesional.