Saltar a contenido

Blog 2019🔗

Agosto🔗

Retomando los catálogos del SAT🔗

Este no es un tema sencillo, los catálogos que publica el SAT para CFDI y sus complementos son muy extensos. Algunos catálogos están repetidos (por ejemplo, en CFDI y el Complemento de Comercio Exterior) o sufren actualizaciones constantes (como el catálgo de número de pedimento de CFDI).

El problema raíz es que el SAT no tiene una orientación de consistencia. Sería muy bueno que hiciera publicaciones de sus catálogos con formatos estándar, incluso tipados, la sea xml, json o hasta un volcado de base de datos sql. Esto no excluye que publique la información en archivos en formato entendible, como xlsx, pero incluso, teniendo la información de los catálogos sistematizada la generación de sus archivos de validación de esquemas xsd o los mismos archivos para lectura xlsx podrían emitirse en forma homogénea y estándar.

Lamentablemente esto no va a ocurrir, entonces, al no solucionarlo la autoridad, lo tenemos que solucionar nosotros. Por lo tanto, el problema tiene varias partes:

  • Descargar los catálogos del SAT para CFDI y complementos
  • Extraer la información
  • Interpretar la información
  • Generar un nuevo formato
  • Publicar la información de catálogos

Origen de la información🔗

El origen de los catálogos se encuentra disperso en el sitio del SAT, en diferentes páginas y los archivos a los que hace referencia se encuentran en formatos poco amigables, en su mayoría archivos de MS Excel 97, que carecen de una estructura homogénea en los encabezados y la información contenida.

Además, existe el problema de detectar cuándo un catálogo ha cambiado, si el SAT no tiene consistencia en su publicación o en su estructura, mucho menos en sus momentos de actualización.

Convertir la información en estructuras entendibles🔗

Para poder convertir los catálogos en estructuras entendibles, es necesario primero poderlas entender. Esta tarea consiste en poder interpretar correctamente los archivos xls publicados.

La tarea en sí misma es ardua, a la conclusión que he llegado es a convertirlos a formato xlsx y posteriormente pasarlos a csv.

No puedo pasar directamente de xls a csv porque las herramientas libres no permiten una exportación limpia. Open Office no exporta correctamente todas las hojas en archivos individuales, afortunadamente sí hace una buena conversión de xls a xslt y luego con xlsx2csv podemos pasar todo el contenido de las hojas a archivos csv individuales.

Luego nos enfrentamos con otro problema, el SAT (en su infinita inteligencia) ha dividido las hojas en varias partes, usando un patrón diferente en cada división. Como ejemplo de los retos a superar:

  • Hay hojas que dicen al final Continúa en c_CodigoPostal_Parte_2
  • Hay hojas que se llaman c_Colonia_1, c_Colonia_2 y c_Colonia_3 que son un mismo origen c_Colonia
  • Hay hojas c_CodigoPostal_Parte_1 y c_CodigoPostal_Parte_2 que nos llevan a c_Codigo_Postal (patrón diferente al anterior)
  • Había hojas c_CodigoPostal (Parte 1)

Interpretar y generar un nuevo formato🔗

Una vez con la información en archivos csv es mucho más sencillo poder trabajar en la automatización de la interpretación de los contenidos, en teoría, porque el SAT publica los formatos como quiere, por ejemplo, para fechas y boleanos utiliza diferentes formatos (a veces Sí, Si o 1).

Y nos ha tocado que frecuentemente cambia el lugar donde inician los encabezados, agrega o elimina encabezados o cambia su orden. Por ello es necesario que verifiquemos que la estructura obtenida coincide exactamente con la estructura esperada, tanto en columnas como en el lugar de inicio.

Esto nos lleva a conversiones más precisas, por ejemplo, de fechas o boleanos o números.

Vale la pena comentar que, aunque pareciera que los catálogos son simplemente registros que se pueden identificar (que tienen algún tipo de ID o unicidad), esto no es lo que sucede. Hay "catálogos" que en realidad son reglas y que no tienen unicidad ni se deben tomar como un conjunto de clave + información.

Generación de información🔗

Una vez que pudimos leer, validar e interpretar el contenido de los catálogos y obtener todas las entradas, viene la pregunta ¿qué tipo de formato deberemos producir?.

La primer idea fue generar un archivo json o xml, en un formato estructurado de fácil lectura, pero debemos entender los casos donde existen conjuntos de información con miles de registros y el resultado de estos catálogos será igualmente extenso por lo que la búsqueda o filtrado de información será muy complicada o cuando menos pesada.

Por lo anterior es que nos decidimos por un archivo en formato sqlite, que tiene muchas ventajas:

  • Los datos tienen un tipo simple
  • Puede tener conjuntos con llaves y sin llaves
  • Es un formato libre
  • Se puede leer desde cualquier lenguaje de programación moderno
  • Permite consultar información sin tener que cargar todo el contenido

Publicación de la información🔗

Dado que el SAT no avisa ni tiene un lugar público automatizable para detectar que los catálogos han cambiado, es necesario revisar periódicamente (al menos una vez al día) que los catálogos han sido actualizados.

Y es justo aquí donde nos quedamos con algunas dudas para poder hacer una publicación:

  • ¿Deberíamos de publicar la base de datos versionada?
  • Si se versiona, ¿se hace por fecha?, ¿por tag de git?
  • ¿Cómo se publica y versiona automáticamente?
  • ¿Cómo saben los proyectos que utilicen esta base de datos que hay una actualización?

Posiblemente el versionado sea del tipo <mayor>.<minor>.<update> siguiendo SemVer y donde mayor refleja un cambio que rompe compatibilidad con versiones anteriores, como eliminar un catálogo o un campo de un catálogo, minor refleja un cambio compatible, como que se agregó un catálogo o un campo y update es una fecha que indica el momento de actialización o momento de cambio.

Así entonces podríamos ver versiones como 1.1.20190720 y 1.1.20190828 que indica que ambas versiones son compatibles, seguida de 1.2.20190915 que indica que se mejoró la estructura pero no deberías tener problemas para seguirla utilizando y cuando llegue 2.0.20191001 entonces sabrás que hay cambios estructurales que podrían hacer que tu aplicación se rompa por tablas o campos inexistentes.

Iniciando con http://www.phpcfdi.com🔗

Después de muchos intentos con varios generadores de sitios estáticos al final he implementado la solución que a mi parecer ha sido la más sencilla y limpia: mkdocs con material theme.

Tengo la impresión de que se pueden introducir mejoras al tema sin necesidad de duplicarlo, usando extra_css extra_javascript y extra_templates

Una de las cosas que no pude agregar fue el icono de Discord porque la versión de Font Awesome que viene en el tema no la tiene incluida y aún no publican la actualización que soporte la versión 5.

Tampoco tiene un landing page de mi agrado, por lo que terminé creando un landing page básico usando el tema de bulma.

Si te interesa el tema de generadores estáticos en https://www.staticgen.com/ tienen listado muy extenso con información clave de lenguaje utilizado y templates.