La historia de cómo un cliente me empujó a construir algo que no tenía ni idea de cómo hacer — y por qué al final fue una de las mejores decisiones técnicas que tomé.
El problema llegó con un cliente
No fue una decisión planeada. No fue un proyecto que puse en mi roadmap con semanas de anticipación. Fue un cliente que necesitaba un sistema, y ese sistema necesitaba facturación electrónica. Así de simple, así de repentino.
En ese momento yo no tenía nada. Sin código previo, sin experiencia con el Ministerio de Hacienda, sin un colega que ya lo hubiera hecho antes al que pudiera preguntarle. Solo tenía el requerimiento sobre la mesa y la presión de que había que hacerlo funcionar.
Lo primero que hice fue lo que hace cualquier desarrollador en esa situación: buscar documentación.
Descargando el mundo del MH
El Ministerio de Hacienda de El Salvador publica los documentos técnicos necesarios para implementar el sistema de emisión de Documentos Tributarios Electrónicos (DTE). Así que me puse a descargar todo:
- Los documentos técnicos oficiales
- Los esquemas JSON de cada tipo de documento
- El firmador oficial que provee el Ministerio
Con eso en mano empecé a leer. Mucho. Y entre más leía, más preguntas surgían.
La primera gran decisión: ¿dependo del firmador oficial o no?
El Ministerio ofrece un firmador listo para usar. La ruta fácil hubiera sido integrarlo y seguir adelante. Pero algo me detuvo.
El firmador oficial es una pieza externa que no controlo. Si falla, si cambia, si tiene un comportamiento inesperado, mi sistema queda atado a eso. Así que desde el principio decidí que no quería depender de él. Quería entender el proceso de firma digital por dentro y construir mi propia solución.
Fue una decisión que me costó tiempo al inicio — y que me generó uno de los tropiezos más grandes que tuve, del que hablaré en un post más adelante. Pero hoy, viéndolo en retrospectiva, no lo cambiaría.
La segunda gran decisión: ¿integrado o como API?
Originalmente pensaba construir la facturación electrónica integrada directamente dentro del sistema del cliente. Tenía lógica en ese momento: un solo proyecto, menos complejidad aparente.
Pero entonces me puse a pensar más allá de ese cliente.
¿Qué pasa cuando el siguiente cliente también necesite facturación electrónica? ¿Voy a reescribir todo otra vez?
Esa pregunta lo cambió todo. Decidí hacer un esfuerzo único: construir la facturación electrónica como una API independiente, de manera que cualquier sistema que desarrollara después solo tuviera que integrarse a ella. Sin duplicar código, sin reinventar la rueda cada vez.
Ciertas partes entre sistemas siempre van a ser similares — la lógica de negocio, las entidades, algunos flujos. Pero la parte más compleja y especializada, todo lo relacionado con el DTE, firmas, envíos y manejo de respuestas del MH, eso viviría en un solo lugar.
¿Por qué fue una buena decisión?
Porque desde entonces, cada sistema nuevo que he tenido que construir con necesidad de facturación simplemente consume la API. No hay reescritura. No hay reaprendizaje. El conocimiento quedó encapsulado en un servicio que evoluciona de forma independiente.
Además, tener la facturación como API te da beneficios que no parecen obvios al inicio:
- Puedes versionar la API sin afectar los sistemas que la consumen
- Puedes escalarla de forma independiente
- Puedes probarla de forma aislada
- Si el MH cambia algo en el esquema, solo actualizas un lugar
Lo que viene
Este post es el punto de partida de una serie donde voy a documentar todo el proceso: la arquitectura que usé, los patrones de diseño que me ayudaron, los errores que cometí y cómo los resolví, y cómo construir cada tipo de documento paso a paso.
Si estás por enfrentarte a la facturación electrónica en El Salvador — o simplemente te interesa ver cómo se resuelve un problema técnico complejo desde cero — esta serie es para ti.
Nos vemos en el siguiente post: Entendiendo el ecosistema — DTE, Hacienda y el flujo general.
¿Te ha pasado algo parecido? ¿Un cliente que te lanzó a implementar algo que nunca habías tocado? Cuéntame en los comentarios.
RELATED POSTS
View all