Por qué la postventa de tu promoción debería vivir en tu ERP (y no en una herramienta aislada)

Hay una pregunta que casi nunca se hace en los comités de dirección de las promotoras, y que sin embargo cambia la forma de mirar la operación: “¿Dónde están realmente los costes de postventa de cada promoción?”. La respuesta más honesta —en la mayoría de empresas medianas del sector— es: “no lo sé del todo”. Están en facturas dispersas de industriales, en albaranes que se pagan sin imputar a un proyecto concreto, en horas internas de coordinación que nadie cuantifica, en repuestos comprados a granel sin trazabilidad por inmueble.

¿Por qué? Porque la postventa, en la mayoría de promotoras, vive fuera del ERP. Vive en un buzón de correo, en hojas de cálculo, en una herramienta aislada de tickets, o en la cabeza del jefe de postventa. Y todo lo que vive fuera del ERP nunca llega bien a la cuenta de resultados.

Este artículo explica por qué la postventa debería vivir dentro del ERP de la promotora —especialmente si ese ERP es Microsoft Dynamics 365 Business Central—, qué cambia cuando se hace bien, y qué buscar en una solución vertical que no rompa la integración a las primeras de cambio.

El problema de la postventa como silo

Cuando la postventa vive fuera del ERP, ocurren cinco cosas previsibles:

1. Los costes no se imputan al proyecto correcto. Las facturas de los industriales llegan al departamento de compras. El responsable de compras las contabiliza en una cuenta de gasto genérica de “mantenimiento” o “subcontratas”. Nadie las asigna a la promoción específica donde se gastó el dinero. Resultado: la cuenta de resultados de la promoción “Residencial El Mirador” no refleja los 18.000 € que se gastaron en arreglar incidencias durante su primer año post-entrega.

2. Las garantías se pierden. Cuando una caldera se cambia bajo garantía del fabricante, debería haber un registro automático: la factura del repuesto se debe imputar contra la promoción, pero también se debe enlazar con la garantía vigente para reclamarla al fabricante. Sin integración, esto se pierde 8 de cada 10 veces.

3. La rentabilidad por proyecto se distorsiona. El financiero cierra el ejercicio y dice: “esta promoción salió con un margen del 18 %”. Pero si se hubieran imputado los 18.000 € de postventa, el margen real sería del 16,2 %. Esa diferencia, multiplicada por todas las promociones de la cartera, define si el negocio es rentable o no.

4. Los proveedores no se evalúan con datos reales. ¿Cuál es el industrial más rentable de tu red? ¿El que cobra menos por intervención, o el que resuelve a la primera y no genera reincidencias? Sin datos integrados, todo el mundo tiene una opinión y nadie tiene una respuesta basada en hechos.

5. La planificación de las próximas promociones no aprende. ¿Qué tipo de incidencias son las más caras? ¿Qué materiales fallan más? ¿Qué constructores entregan promociones con menos defectos? Esa inteligencia operativa solo aparece cuando los datos de postventa están en el mismo sistema que los datos de coste y de proveedor.

Por qué Business Central es el sitio natural

Microsoft Dynamics 365 Business Central se ha convertido en el ERP de referencia para promotoras medianas en España y Europa. Por una razón económica (Microsoft ha hecho la transición a la nube accesible incluso para empresas de 30-100 empleados) y por una razón funcional (la base contable, financiera y de proyectos es sólida).

Pero Business Central, de fábrica, no incluye un módulo específico de postventa para promoción inmobiliaria. Tiene un módulo genérico de Service Management que sirve para mantenimiento de equipos industriales y poco más. No conoce el dato del sector: promoción, finca, inmueble, propietario, escritura, contrato, garantías. No tiene un portal del cliente final con login. No tiene una app móvil para industriales. No clasifica las incidencias por gremio inmobiliario.

Por eso la postventa inmobiliaria sobre Business Central necesita una extensión vertical. Y aquí es donde aparece la siguiente pregunta importante: “¿una extensión nativa o una integración por API?”.

Extensión nativa AL vs integración por API: por qué importa la diferencia

Hay dos formas de añadir funcionalidad a Business Central:

Integración por API (la opción débil). Una herramienta de postventa externa se conecta a Business Central mediante llamadas API. Cada vez que se crea una incidencia, el sistema externo llama a BC para registrar algo. Cada vez que se factura una intervención, el sistema externo manda los datos a BC.

Problema: cada actualización de Business Central es un riesgo. Microsoft saca una versión nueva cada 6 meses (forzosamente, en cloud). Cualquier cambio en el endpoint, en el formato de datos o en los permisos puede romper la integración. Y la dependencia de un sistema externo significa que si la herramienta de postventa cae, también cae el flujo de datos hacia BC. La latencia entre los dos sistemas genera datos desincronizados que el equipo descubre demasiado tarde.

Extensión nativa AL (la opción robusta). La funcionalidad de postventa se desarrolla dentro de Business Central, en el lenguaje propio del ERP (AL), publicada como app certificada en AppSource. No hay sistema externo: la postventa ES Business Central. Las tablas de incidencias, las facturas a industriales, los maestros de promociones e inmuebles, todo vive en el mismo motor de datos que Finanzas, Compras y Servicio.

Ventajas concretas:

• Microsoft te garantiza la compatibilidad con cada versión nueva de BC. Cuando sale BC 26 o BC 27, la extensión AL sigue funcionando porque está construida sobre las APIs internas y certificadas del ERP.
• No hay latencia entre sistemas. La factura de un industrial se contabiliza en el mismo segundo en que se cierra la incidencia.
• Los maestros son los mismos. El industrial que aparece en la app móvil es el mismo proveedor que está dado de alta en BC. La promoción es la misma. El cliente es el mismo. Sin duplicidad, sin reconciliación periódica.
• Los permisos heredan los del ERP. Si un usuario tiene acceso a Compras en BC, lo tiene también a la postventa de su promoción. Sin gestionar dos sistemas de roles distintos.

Para promotoras que ya están en Business Central, la extensión nativa es la única opción que escala sin generar deuda técnica. La integración por API es una solución temporal que tarde o temprano se rompe.

Qué cambia cuando la postventa vive en BC

Cuando la postventa pasa a ser una extensión nativa de Business Central, hay cinco cosas que cambian de manera visible para la dirección:

1. La cuenta de resultados de cada promoción es real. Cada euro gastado en postventa —factura del industrial, repuesto comprado, gestión interna imputada— se asigna automáticamente a la promoción y al inmueble específico. El cierre mensual ya no necesita reconciliaciones manuales: los números están bien desde el primer registro.

2. La conciliación bancaria incluye la postventa. Cuando llega el extracto bancario y se importa en formato Norma 43, las facturas de industriales aparecen ya conciliadas porque están dentro del mismo ERP. Sin saltos a otro sistema, sin esperar al cierre del software de tickets.

3. Las garantías se vinculan al inmueble. Cuando se cambia un componente bajo garantía, la extensión registra la operación contra la garantía activa de ese inmueble. Si la garantía es del fabricante, se genera el reclamo automáticamente. Si es del constructor (durante el primer año), se contabiliza en una cuenta específica para hacer la reclamación al cierre del periodo de garantía decenal.

4. El analítico por proveedor es continuo. El Role Center del jefe de postventa muestra al inicio de sesión: cuántas incidencias activas, cuáles llevan más de 7 días sin resolverse, cuál es el tiempo medio de cierre por industrial, qué proveedor tiene mejor ratio de resolución a la primera. Datos en tiempo real, generados desde las mismas tablas que la contabilidad.

5. Las promociones futuras heredan inteligencia. Cuando arranca una promoción nueva, el sistema sabe automáticamente qué proveedores son los más fiables para cada gremio en esa zona, qué tipos de incidencias generaron las promociones similares anteriores, y qué materiales hay que reforzar en las especificaciones para evitar problemas conocidos.

Lo que hay que mirar al elegir la extensión

Si estás evaluando una solución de postventa sobre Business Central, estos son los puntos que conviene revisar:

• ¿Está publicada en AppSource con certificación de Microsoft? AppSource solo lista extensiones validadas por Microsoft (Co-sell ready, App Source Certified). Las que no aparecen ahí son desarrollos privados sin garantía de compatibilidad futura.
• ¿Qué tablas de BC usa y cuáles añade? Una buena extensión usa los maestros existentes (proveedores, clientes, dimensiones financieras) y añade solo lo que es específico del sector (promociones, inmuebles, incidencias, garantías).
• ¿Cómo se actualiza? Si actualizas BC, la extensión debería actualizarse automáticamente desde AppSource sin intervención manual del consultor.
• ¿Funciona también para empresas que aún no están en BC? Una extensión bien diseñada debería poder operar también como sistema autónomo (sin BC detrás) o conectada a otro ERP mediante integraciones controladas, para clientes que aún están en transición.

La pregunta de fondo

Si tu promotora ya está en Business Central —o tiene un proyecto de migración a corto plazo—, la pregunta no es “¿qué herramienta de postventa elegimos?”. La pregunta es:

“¿Por qué la postventa va a vivir fuera del ERP donde ya viven nuestras compras, nuestras ventas y nuestra contabilidad?”

La respuesta razonable es: no debería. Y la única forma de evitarlo es elegir una extensión nativa AL que convierta la postventa en una parte natural del ciclo de operación de la promoción, no en un anexo aislado que el equipo financiero recibe en hojas de cálculo cada cierre de mes.

En resumen

• La postventa que vive fuera del ERP nunca llega bien a la cuenta de resultados: los costes no se imputan a la promoción correcta y la rentabilidad por proyecto se distorsiona.
• Business Central es el ERP de referencia para promotoras medianas, pero no incluye módulo de postventa inmobiliaria de fábrica: necesita una extensión vertical específica.
• Una extensión nativa AL publicada en AppSource es radicalmente más robusta que una integración por API: Microsoft garantiza compatibilidad con cada versión, los maestros son únicos, y no hay latencia entre sistemas.
• Cuando la postventa vive dentro de BC, cambian cinco cosas observables: la cuenta de resultados es real, las garantías se vinculan al inmueble, el analítico por proveedor es continuo, las promociones futuras heredan inteligencia y la conciliación bancaria es nativa.
• Si tu promotora ya está en BC o lo va a estar pronto, elegir una herramienta externa es generar deuda técnica que tarde o temprano hay que pagar.

---

¿Quieres ver una extensión AL nativa para postventa inmobiliaria sobre Business Central? En Davisa hemos creado dvive, publicada en AppSource, que conecta cliente, promotor e industrial en el mismo ERP donde ya viven tus compras, tu contabilidad y tus proyectos. Funciona también de forma autónoma o con tu ERP actual si todavía no estás en BC. Calcula tu tarifa o pide una demo en menos de 24 h.