Una muestra de proyectos en producción.

Contexto

Quantix se construyó como un sistema productivo para empresas que necesitan controlar inventario y facturación en múltiples compañías y sucursales sin duplicar plataforma.

Enfoque de solución

• La plataforma se organizó en módulos de inventario, facturación, reportería, catálogos y configuración sobre un backend .NET.
• La interfaz en C# se diseñó alrededor del contexto por empresa y sucursal para recorrer el mismo núcleo sin duplicar flujos.
• La capa de datos se centralizó en Azure SQL Database para preservar trazabilidad, consistencia y reportería consolidada.

Resultados

• Múltiples empresas operan hoy sobre una misma plataforma con control por sucursal.
• Los módulos críticos comparten una sola fuente de datos para inventario, facturación y consulta.
• El sistema puede crecer con nuevos catálogos, reportes y configuraciones sin romper el núcleo operativo.

Restricciones

• Cada empresa debía convivir en el mismo sistema con sus propias reglas, catálogos y configuración.
• Inventario y facturación exigían consistencia de datos y respuesta confiable en la operación diaria.
• La plataforma debía crecer por módulos sin convertir la experiencia en un sistema fragmentado.

Decisiones clave

• Se priorizó un núcleo compartido multiempresa sobre despliegues aislados por cliente.
• La separación por empresa se resolvió en el modelo de datos y configuración, no en instancias separadas del sistema.
• Se eligió Azure SQL Database para sostener consistencia transaccional y escalabilidad operativa en la nube.

Lecciones aprendidas

• En sistemas multiempresa, modelar bien el contexto y la configuración vale más que acumular pantallas.

Contexto

Diseñado para una empresa en Nicaragua que operaba Dynamics 365 Business Central con LS Central BackOffice y POS, donde el cierre nocturno de statements necesitaba mucho más que una alerta de bloqueo.

Enfoque de solución

• Se agregó una acción Insufficiencies mediante una page extension sobre Open Statement para abrir una lista acotada al statement con todos los items insuficientes.
• Se construyó una segunda page extension sobre el setup existente para que la empresa pudiera activar o desactivar el bloqueo de posteo y la lógica complementaria de insuficiencias.
• Se implementaron codeunits dedicadas en AL para cálculo y guard de posteo, incluyendo la validación que detiene Post Statement cuando las insuficiencias siguen existiendo.
• Se añadieron capacidades de trace y exportación operativa para que el usuario pasara de la alerta a la corrección con evidencia concreta por item.

Resultados

• Ahora los usuarios pueden ver cada producto insuficiente asociado al statement actual antes de intentar el posteo.
• Los ajustes de inventario y movimientos correctivos se realizan con evidencia real a nivel de statement en lugar de suposiciones.
• El cierre nocturno se volvió más limpio porque el posteo se detiene solo después de presentar detalle accionable de insuficiencias.

Restricciones

• La funcionalidad debía vivir dentro de Open Statement para que la operación nocturna no dependiera de pantallas externas ni de workarounds manuales.
• La solución tenía que explicar las insuficiencias exactas para ese statement y fecha concretos, no solo indicar que algo estaba mal.
• Las reglas de negocio debían seguir siendo configurables desde setup, incluyendo el bloqueo del posteo y la lógica de cálculo más profunda.

Decisiones clave

• La funcionalidad se incrustó en la página de LS BackOffice en vez de crear un proceso aislado, maximizando adopción dentro del flujo nocturno real.
• Setup, punto de entrada UI, motor de cálculo y guard de posteo se separaron para mantener las reglas de negocio mantenibles y auditables.
• Se priorizó evidencia accionable por statement sobre el mensaje genérico nativo, porque operación necesitaba corregir inventario antes del cierre.

Lecciones aprendidas

• En flujos de backoffice retail, bloquear no basta; el sistema debe explicar el problema exactamente donde el usuario puede resolverlo.

Contexto

Producto digital diseñado específicamente para Nicaragua con el objetivo de cerrar la brecha entre números y entendimiento en préstamos, salarios y liquidaciones.

Enfoque de solución

• Se construyeron calculadoras contextuales que guían al usuario explicando riesgos y puntos clave junto a los números.
• Se integró un asistente con IA para resolver dudas específicas y orientar al usuario hacia herramientas puntuales internas.

Resultados

• La plataforma operando en vivo ha logrado traducir cálculos complejos en consejos asimilables y aplicables.
• Se demostró un despliegue sólido end-to-end; abarcando desde UI hasta integraciones complejas en el Edge.

Restricciones

• Los usuarios usualmente no tienen la experiencia técnica o económica para interpretar resultados financieros crudos.
• Se requería un contexto local robusto y específico sobre nómina, derechos laborales y sector bancario en Nicaragua.

Decisiones clave

• Se eligió una arquitectura Edge (Serverless) para el backend garantizando latencia ultrabaja y la escalabilidad con OpenAI.
• Se favoreció principios offline-first y persistencia local para mantener fuera el estado de bases de datos externas.

Lecciones aprendidas

• Desarrollar productos con impacto social genuino comprueba una disciplina mayor que seguir modas tecnológicas.