Revisado el 30 de septiembre de 2026. Guía para responsables de una instalación con adaptaciones propias.
¿Una personalización puede romper una actualización de ERPNext?
Sí. Una adaptación puede depender de campos, métodos, permisos o comportamiento que cambien entre versiones. Separar el desarrollo en una app facilita su mantenimiento, pero no garantiza compatibilidad automática. Para actualizar con criterio necesitas un inventario de cambios, versiones compatibles y pruebas de los procesos que esas adaptaciones afectan.
La pregunta útil antes de desarrollar es qué proceso necesitas resolver y cómo comprobarás que sigue funcionando después. Un campo informativo, una validación contable y una integración con una tienda tienen consecuencias diferentes. Su mantenimiento debe formar parte de la decisión inicial.
Configuración, personalización o aplicación propia
Empieza por comprobar si el comportamiento estándar cubre el proceso y documenta la diferencia que queda. Después elige el mecanismo que permita mantener y probar el cambio. Crear una aplicación tiene sentido cuando existe lógica que gestionar; no hace falta convertir cada dato adicional en un proyecto de desarrollo.
| Necesidad | Primera vía que evaluar | Prueba que debes conservar |
|---|---|---|
| Registrar un dato adicional | Campo personalizado y permisos | Crear, consultar y exportar el dato |
| Añadir una aprobación | Configuración de flujo de trabajo | Transiciones y usuarios autorizados |
| Cambiar el aspecto de un documento | Formato de impresión | PDF con casos reales de longitud y datos |
| Validar una regla de negocio | Lógica de servidor adecuada al entorno | Operación desde interfaz y desde API |
| Conectar otro sistema | Integración y estado de sincronización | Reintento, fallo y conciliación |
| Añadir un proceso empresarial | App Frappe si el alcance lo exige | Recorrido completo y permisos por rol |
Estas vías requieren revisar las capacidades y restricciones de tu alojamiento y versión. Una comprobación en el navegador no sustituye una regla de servidor cuando también se crean documentos por API o importación.
Frappe ofrece hooks para extender el comportamiento de las aplicaciones. Su disponibilidad depende de la versión: por ejemplo, la documentación sitúa extend_doctype_class en v16 o posterior. No copies una solución para otra versión sin comprobar esa dependencia.
El inventario mínimo de una adaptación
Anota para cada cambio su finalidad, ubicación, responsable y proceso afectado. Añade la versión en la que se probó y cómo reproducir la prueba. Esta ficha permite decidir qué revisar al actualizar y evita depender de que una sola persona recuerde por qué existe una validación o un campo.
Ejemplo didáctico: una empresa pide autorizar pedidos por encima de un importe antes de confirmarlos. La ficha debe explicar el umbral acordado, quién autoriza y qué ocurre con pedidos enviados por API. La prueba debe intentar confirmar un pedido permitido, uno bloqueado y uno autorizado. Es un ejemplo de evaluación, no un proyecto atribuido a un cliente.
Si el cambio conecta aplicaciones, añade el contrato de datos: identificadores, campos obligatorios, estados y tratamiento de errores. La guía de integraciones sin duplicados desarrolla esa parte.
Cómo ensayar una actualización
Prepara una copia aislada, aplica allí la actualización y recorre los procesos prioritarios antes de intervenir en producción. El ensayo debe incluir las apps propias y las integraciones, además de ERPNext. Registra fallos y correcciones; una pantalla de acceso disponible solo demuestra que puedes iniciar sesión, no que el negocio funciona.
- Registrar versiones actuales, apps, cambios propios y dependencias externas.
- Preparar una copia restaurable con los datos y archivos necesarios.
- Desactivar envíos reales, correos automáticos y tareas externas en la copia.
- Revisar las notas de migración de las versiones que se van a atravesar.
- Actualizar la copia y ejecutar las pruebas de aceptación acordadas.
- Resolver incompatibilidades y repetir las pruebas afectadas.
- Acordar ventana, responsables y recuperación antes del cambio real.
Incluye compras, ventas, stock, contabilidad y permisos cuando tu adaptación los afecte. Comprueba también informes y formatos que el equipo utiliza para trabajar. Una prueba automática ayuda a detectar regresiones repetibles; la revisión del usuario confirma que el resultado sirve para la operación.
El plan de recuperación debe contemplar las operaciones nuevas realizadas tras actualizar. Volver a una copia anterior sin conciliarlas puede causar pérdida de datos. Define esa gestión durante el ensayo, con responsables del negocio y del sistema.
Qué pedir en una propuesta de desarrollo
Pide que la propuesta explique el mecanismo elegido, qué versiones se soportan y cómo se entrega el trabajo. Debe incluir pruebas de aceptación, dependencias y responsabilidad de mantenimiento. El coste inicial pierde sentido si no sabes quién puede modificar el código y qué habrá que revisar cuando cambie ERPNext.
Solicita repositorio y documentación según los derechos acordados, instrucciones de despliegue y una lista de límites conocidos. Para un alcance más amplio, consulta desarrollo con Frappe para empresas y la guía para comparar presupuestos.
Preguntas frecuentes
¿Una app propia garantiza que ERPNext se actualizará sin problemas?
No. Separar el código facilita su mantenimiento, pero la app puede depender de interfaces o comportamiento que cambien. Hay que revisar compatibilidad y probar el proceso afectado en la versión de destino.
¿Conviene modificar directamente el código de ERPNext?
Antes de hacerlo, evalúa configuración y mecanismos de extensión. Un cambio directo aumenta el trabajo de comparación y mantenimiento con nuevas versiones. Si resulta necesario, debe documentarse y tener una estrategia explícita de actualización.
¿Se pueden conservar los campos personalizados al actualizar?
Puede ser posible, pero hay que comprobar conflictos, permisos y usos de esos campos en scripts, informes e integraciones. Conservar el campo no demuestra que todos los procesos que dependen de él sigan funcionando.
Sobre el autor
Lleva desde 2014 implantando ERPNext y desarrollando sobre Frappe Framework, que es lo único a lo que se dedica CodigoNext: ni una línea de negocio con otro ERP. Ha construido el módulo VeriFactu de la casa y trabaja el día a día de pymes españolas y de proyectos en Latinoamérica. Escribe aquí lo que se encuentra en los proyectos, incluido lo que no funciona y lo que no compensa. Conoce al equipo.
CodigoNext se dedica exclusivamente a ERPNext y Frappe desde 2014. Trabajamos en desarrollo a medida y actualizaciones para España y Latinoamérica. Si heredas una instalación, empieza también por el inventario para cambiar de proveedor.