Un software de gestión de pedidos a medida hace falta cuando tus pedidos siguen reglas que el ERP estándar no recoge: tarifas pactadas con cada cliente, entregas parciales, aprobaciones internas o varios canales que comparten el mismo almacén. Si hoy esas reglas viven en hojas de cálculo y correos, ese es el momento de plantear un software de gestión de pedidos a medida en Madrid que las aplique de forma automática.
El problema rara vez es la falta de un programa. La mayoría de empresas ya tienen un ERP, pero el pedido real no cabe en él: el comercial apunta el descuento en un correo, el almacén sirve lo que hay y avisa por teléfono de lo que falta, y administración rehace el albarán antes de facturar. Antes de escribir código conviene mapear los procesos de pedidos de una empresa en Madrid y ver dónde se pierde el tiempo.
Al terminar sabrás qué señales indican que el ERP se queda corto, cómo modelar el pedido para que no se pueda saltar pasos y cómo conectarlo con el ERP y el almacén, con criterios para calcular la inversión en un software propio.
Qué es un software de gestión de pedidos a medida
Es la aplicación que recoge cada pedido, venga del canal que venga, aplica tus reglas comerciales, decide qué se puede servir y desde qué almacén y sigue su recorrido hasta la factura. A medida significa que esas reglas se programan según cómo vendes tú y viven en la capa de servidor que guarda la lógica de negocio.
No sustituye necesariamente al ERP. En los módulos y fases de un ERP propio explicamos el sistema completo; aquí nos centramos solo en el pedido, que es la pieza que más se complica y la que antes suele justificar un desarrollo.
Señales de que el ERP estándar se queda corto
Un ERP estándar resuelve bien el pedido típico. Los problemas aparecen con las excepciones que en tu empresa son la norma. Estas son las señales que vemos con más frecuencia cuando una empresa nos pide comparar una herramienta SaaS con un desarrollo propio:
- Tarifas por cliente: precios pactados, descuentos por volumen o por familia de producto y condiciones que caducan. Si el comercial los calcula fuera del sistema, cada pedido es una ocasión de error.
- Pedidos parciales y backorders: sirves lo que tienes y el resto queda pendiente con fecha prometida. Si el ERP solo entiende pedido servido o no servido, alguien lleva el pendiente en un Excel.
- Aprobaciones: pedidos por encima de un importe, con margen por debajo del mínimo o de clientes que han superado su riesgo. Necesitan un paso de aprobación con responsable y registro.
- Varios canales: comerciales, portal B2B, tienda online y marketplaces que generan pedidos con formatos distintos sobre el mismo stock.
- EDI con grandes cuentas: cadenas y distribuidores que solo aceptan pedidos y confirmaciones en formato electrónico estandarizado.
- Excepciones en notas: instrucciones de entrega, embalajes especiales o portes pactados que viajan como texto libre y nadie comprueba.
Si te reconoces en dos o más, el coste de seguir con parches suele superar al de construir el módulo, y conviene elegir proveedor para el software de pedidos con estas situaciones sobre la mesa.
Un solo modelo de pedido para todos los canales
Cada canal llega con su formato: la tienda online con pedidos B2C en Madrid envía el pedido ya pagado, el portal B2B donde tus clientes repiten pedidos lo envía pendiente de condiciones y la app para comerciales que toman pedidos en Madrid puede enviarlo horas después, cuando recupera la cobertura. La regla es traducir todos a un único modelo interno nada más entrar, con el canal como un dato más. Así las tarifas, el stock y las aprobaciones se aplican una sola vez y de la misma forma.
Pedidos por EDI
Muchas cadenas de distribución trabajan con EANCOM, el estándar EDI de GS1, un subconjunto de UN/EDIFACT que solo incluye los elementos que necesitan las aplicaciones de negocio. En la práctica, el pedido electrónico entra por un conector, se traduce al modelo interno y sigue el mismo camino que cualquier otro. Lo que cambia es la exigencia: el cliente espera confirmaciones automáticas, y para eso el sistema necesita saber en cada momento qué puede servir, algo que en Codezone resolvemos con conectores programados a medida en lugar de automatizaciones externas.
El pedido como máquina de estados
Un pedido pasa por estados: borrador, pendiente de aprobación, confirmado, servido en parte, servido, facturado o cancelado. Una máquina de estados define cuáles existen y qué transiciones son válidas desde cada uno. Si el código lo impone, nadie puede facturar un pedido que no se ha servido ni editar uno ya facturado, y cada regla queda en un solo sitio, separada del resto del código como propone la arquitectura hexagonal para aislar las reglas del pedido.
Cada cambio de estado guarda quién lo hizo y cuándo. Ese historial es el que luego consultas en el panel interno donde se revisa la trazabilidad de cada pedido cuando un cliente reclama una entrega.
CodeZone Pro Tip: centraliza los cambios de estado del pedido en una sola función que valide cada transición
// Estados del pedido y transiciones permitidas: lo que no está en la lista, no se puede hacer
type Estado = "borrador" | "pendiente_aprobacion" | "confirmado" | "parcial" | "servido" | "facturado" | "cancelado";
const transiciones: Record<Estado, readonly Estado[]> = {
borrador: ["pendiente_aprobacion", "confirmado", "cancelado"],
pendiente_aprobacion: ["confirmado", "cancelado"], // lo decide quien tiene permiso de aprobar
confirmado: ["parcial", "servido", "cancelado"],
parcial: ["parcial", "servido"], // cada envío parcial deja el resto pendiente (backorder)
servido: ["facturado"],
facturado: [], // estado final: se corrige con un abono, nunca editando
cancelado: [],
};
interface Cambio { de: Estado; a: Estado; usuario: string; fecha: string }
export interface Pedido { id: string; estado: Estado; historial: readonly Cambio[] }
// Única puerta para cambiar el estado: valida la transición y deja rastro de quién y cuándo
export function cambiarEstado(p: Pedido, a: Estado, usuario: string): Pedido {
if (!transiciones[p.estado].includes(a)) throw new Error(`Transición no permitida: ${p.estado} -> ${a} (${p.id})`);
const cambio: Cambio = { de: p.estado, a, usuario, fecha: new Date().toISOString() };
return { ...p, estado: a, historial: [...p.historial, cambio] };
}
// Prueba: el flujo normal pasa y un pedido ya servido no puede volver a confirmado
let p: Pedido = { id: "PV-1042", estado: "borrador", historial: [] };
p = cambiarEstado(p, "pendiente_aprobacion", "ana");
p = cambiarEstado(cambiarEstado(p, "confirmado", "jefe.ventas"), "parcial", "almacen");
let bloqueado = false;
try { cambiarEstado(p, "confirmado", "ana"); } catch { bloqueado = true; }
if (p.historial.length !== 3 || !bloqueado) throw new Error("La máquina de estados no se comporta como debe");
console.log(`OK: ${p.id} en estado "${p.estado}" con ${p.historial.length} cambios registrados; retroceso bloqueado`);El tipo `Estado` es una unión de literales, así que el compilador rechaza un estado mal escrito, tal como describe la documentación de TypeScript sobre uniones discriminadas y comprobación exhaustiva. La tabla de transiciones es la única fuente de verdad: añadir un paso de aprobación nuevo es tocar una línea. Para el negocio significa menos pedidos facturados por error y un historial que responde en segundos a la pregunta de quién cambió qué, una de las ventajas del tipado estático frente a JavaScript sin tipos.
Integración con el ERP y con el almacén
Lo primero es decidir qué sistema manda en cada dato. Lo habitual es que el ERP siga siendo el dueño de clientes, artículos y facturación, y que el módulo de pedidos sea el dueño del ciclo de vida del pedido. Es la misma pregunta que planteamos en la integración de pedidos entre ERP y CRM en Madrid, aplicada aquí al pedido. Los eventos que suelen cruzar entre sistemas son estos:
- Pedido confirmado: reserva el stock y genera la orden de preparación para el almacén.
- Expedición parcial: el almacén confirma lo enviado, el pedido pasa a parcial y lo pendiente queda como backorder.
- Pedido servido: el albarán viaja al ERP, que emite la factura con su numeración.
- Cambio de estado relevante: el cliente recibe el aviso por correo, por el portal o por mensajería.
Cada mensaje entre sistemas debe poder repetirse sin efectos duplicados, porque las redes fallan y los reintentos son normales. Si el sistema es nuevo, el módulo de pedidos encaja bien como un módulo con fronteras propias dentro de un monolito modular, sin necesidad de montar servicios separados desde el principio.
Cómo plantear el proyecto sin parar las ventas
Empieza por el canal con más volumen o más errores y deja los demás para fases posteriores. Los pedidos abiertos del sistema anterior se trasladan con un plan para migrar los pedidos pendientes y su histórico y una conciliación de cifras antes del corte. Si parte del proceso sigue en hojas de cálculo, la guía para pasar a una aplicación el Excel de pedidos te ayuda a ordenar ese primer paso.
El alcance condiciona el coste más que la tecnología: cada canal, cada integración y cada regla de tarifa suman horas. En nuestra guía de rangos de precio de un desarrollo a medida tienes cifras orientativas según la complejidad, y conviene sumar desde el principio el coste de mantenerlo.
El Coste de Gestionar Pedidos a Mano
Cada pedido que se corrige a mano consume tiempo de varias personas y deja la puerta abierta a errores que el cliente ve primero: precios mal aplicados, entregas incompletas sin aviso o facturas que hay que abonar. Un módulo de pedidos con reglas claras convierte esas excepciones en procesos, y es una de las piezas que más rápido se notan en la operativa de un estudio que desarrolla software de pedidos en Madrid para empresas de distribución.
En Codezone diseñamos, desarrollamos e integramos el módulo de pedidos con tu ERP y tu almacén, y seguimos con el mantenimiento del software de pedidos en Madrid una vez en marcha. Si tus pedidos ya no caben en el sistema que tienes, cuéntanos cómo entran hoy tus pedidos y te decimos por dónde empezar.
