Lo que más nos preguntan

CGestion es el ERP empresarial de Cosmos basado en motor Informix o Multibase, en producción en cientos de empresas españolas desde mediados de los noventa. No es un sistema "obsoleto", es un sistema estable: SQL-89 sobre Informix sigue siendo más fiable bajo carga real que muchos stacks recientes. Lo que hacemos es modernizarlo por fuera (PWA, REST, móvil) sin tocar la lógica de negocio que lleva 25 años funcionando.

Sí, con ambos. La mayoría de instalaciones de CGestion en construcción y áridos están sobre Informix; en cooperativas agrícolas hay un volumen importante sobre Multibase. Multibase es compatible con SQL-89 y con drivers Informix vía ODBC, así que la capa REST que montamos funciona igual sobre los dos motores.

Depende del alcance, pero damos siempre presupuesto cerrado tras una reunión inicial de toma de requisitos (sin coste). Lo más habitual: una integración REST sencilla sobre CGestion son 2–4 semanas de desarrollo; una PWA sectorial completa con offline, 8–12 semanas. Mantenimiento posterior con horas mensuales pactadas, sin sorpresas.

Si lo que funciona es la lógica de negocio (gestión de obra, costes, pedidos, contabilidad) y lo que duele es la interfaz, el móvil, la integración con bancos o con la AEAT, no merece la pena migrar: cuesta más, rompe procesos y el ROI se diluye. Si la lógica de negocio se ha quedado pequeña (multiempresa internacional, multimoneda, BI avanzado), entonces sí. Hacemos el diagnóstico honestamente, sin agenda comercial.

Con un sistema multicanal. En obra, los operarios sin móvil corporativo fichan por IVR (llamada telefónica con DNI + PIN) o por terminal físico en la caseta. Los técnicos y oficinas, por PWA en su smartphone o por web. Geolocalización solo cuando el puesto lo justifica (lo dice la AEPD) y siempre con consentimiento informado. CIRHU lo implementa exactamente así.

Sí, es uno de nuestros tres sectores principales. Tenemos integraciones específicas para alta de partidas en cuaderno de explotación, cálculo de líneas de ayuda, cierre de campaña y exportación al SGA del FEGA. Lo que viene del CGestion del cooperativista (entregas, anticipos, retenciones) se cruza con la PAC sin re-tecleo.

Para los sectores que cubrimos (construcción mediana, áridos, cooperativas agrarias), sí. SAP y Dynamics son enormes pero su coste de implantación y de licencias rara vez se amortiza en una empresa de 20–200 empleados. Odoo es atractivo en precio pero su núcleo de gestión de obra y de campaña agrícola es flojo frente a CGestion. Lo que aporta GPInfor es que sí podemos darle a CGestion el front moderno y las integraciones que la gente asocia con SAP/Odoo.

Es lo esperable, y es bueno. El histórico es un activo. No tocamos los datos: la capa REST y los frontales móviles consultan el mismo Informix/Multibase que ya está en producción. Si en algún momento se quiere migrar el motor (de Multibase a Informix Dynamic Server, por ejemplo), hacemos el plan de migración aparte; nunca se mezcla con un proyecto de desarrollo.

Ambos. De hecho, la mayoría de nuestro trabajo recurrente es mantenimiento evolutivo de aplicaciones que desplegamos hace años y que han ido creciendo. Tenemos contratos de horas mensuales con clientes desde 2003. Y mantenemos también infraestructura: servidores Linux, copias, backups Informix, monitorización.

Estamos en El Saucejo (Sevilla). Cubrimos toda la península. La mayoría del trabajo se hace en remoto (acceso a sistemas del cliente vía VPN, despliegues controlados, soporte por canal acordado). Para hitos importantes (kickoff, formación a usuarios, go-live) nos desplazamos. No facturamos desplazamiento dentro de Andalucía Occidental; el resto del país, dietas estándar.

Sí. Todo lo que sacamos como PWA tiene modo offline-first: el operario abre la app sin red, ficha o registra avance de obra, y los datos se sincronizan automáticamente cuando vuelve la cobertura. Es la única forma realista de cubrir obra pública en zonas sin señal, áridos en cantera o agricultura en zonas rurales.

El código fuente es del cliente. Lo entregamos en un repositorio Git con el histórico completo y documentación de despliegue. Las bases de datos siguen siendo siempre del cliente. No usamos formatos propietarios cerrados. Si en algún momento se prefiere otro proveedor o equipo interno, la transición es directa.

Desde el 5 de octubre de 2026. A partir de esa fecha el documento de control administrativo del transporte público de mercancías por carretera debe emitirse en formato electrónico y estar disponible para la inspección mediante un código QR, según la Resolución de 5 de junio de 2026 de la Dirección General de Transporte Terrestre y Ferroviario (BOE-A-2026-12784). El contenido del documento sigue siendo el del artículo 6 de la Orden FOM/2861/2012, en la redacción del Real Decreto 70/2019. Nosotros lo cubrimos con miDeCA.

No. La norma exige un PDF nativo digital de menos de 5 MB, con la fecha y hora de creación y de modificación dentro del propio fichero, y con un código QR que apunte a una URL única por https que descargue el documento directamente, sin registro ni pantallas intermedias. Una foto o un escaneo del papel no cumplen ninguno de esos requisitos.

Sí, y es lo recomendable cuando se emiten muchos documentos al día. miDeCA expone una API REST con tokens para que el programa que ya imprime el albarán emita también la carta de porte y se quede con la URL y el código QR, que se imprimen en ese mismo albarán. El operario de báscula no hace ningún paso nuevo: pesa e imprime. Es el mismo patrón de capa REST sobre el sistema existente que aplicamos con CGestion.