Pronóstico de Ventas en Protheus: Configuración, Importación y Gobernanza en SIGAPCP, SIGACOM y CRM

TL;DR. El pronóstico de ventas en Protheus no es un reporte decorativo del área comercial. Es el documento que SIGAPCP toma como base para calcular el MRP y generar órdenes de producción 1. Se registra en la rutina MATA700 y vive en una tabla distinta a los pedidos de venta reales 2. Cuando el dato viene de digitación manual y no de eventos capturados en el sistema, el MRP termina planificando sobre pipeline ficticio, no sobre demanda real 1. El problema no es falta de disciplina del vendedor: es arquitectura de captura de datos.
¿Qué es el pronóstico de ventas en Protheus y cuál es su función dentro del MRP y del Plan Maestro de Producción?

El pronóstico de ventas en Protheus es una estimación cuantitativa de la demanda futura de un producto o servicio para un período determinado. No es un pedido confirmado, sino un cálculo basado en tendencia de mercado e histórico comercial3. En Protheus, ese cálculo no se queda en una hoja de referencia: alimenta directamente el módulo SIGAPCP para que el MRP determine qué materiales, mano de obra y capacidad hacen falta antes de que exista una sola orden real1.
El Plan Maestro de Producción (MPS) usa ese pronóstico para decidir qué fabricar, cuándo y en qué volumen4. Si el dato de entrada está mal calibrado, el problema no se queda en ventas: el MPS termina generando órdenes de producción ficticias o insuficientes. El sistema ejecuta exactamente lo que se le pidió, sin criterio propio para corregir un pronóstico débil1.
La tabla SC4, dentro de SIGACOM, es el repositorio central donde Protheus almacena y permite consultar estos pronósticos1. Desde ahí, SIGAPCP los consume durante el cálculo de MRP para proyectar salidas previstas5.
Es importante no confundir pronóstico con pedido. El pedido de venta se registra en la rutina MATA410 y vive en tablas distintas (SC5/SC6). Cuando ambos coexisten para el mismo producto y período, Protheus los suma como salidas previstas, a menos que se configure lo contrario2.
Pronóstico vs. pedido de venta
| Concepto | Rutina | Tabla | Naturaleza |
|---|---|---|---|
| Pronóstico de ventas | MATA700 | SC4 | Estimación, orden de magnitud3 |
| Pedido de venta | MATA410 | SC5/SC6 | Compromiso confirmado2 |
¿Cómo importar y configurar el pronóstico de ventas para el cálculo del MRP mediante PCPA712 y PCPA144?

Importar y calcular el pronóstico de ventas en Protheus exige dos rutinas distintas trabajando en secuencia: PCPA712 ejecuta el MRP en memoria y consume lo que ya está cargado en la tabla SC4. PCPA144, por su parte, muestra los resultados y permite generar los documentos derivados de esa demanda^62.
Antes de ejecutar el cálculo, PCPA712 exige parámetros de horizonte de planificación. También valida la configuración mediante puntos de entrada específicos. El punto P712VLD, por ejemplo, valida los parámetros de ejecución y puede bloquear el avance si detecta errores de parametrización — un control crítico para equipos de PCP que operan con múltiples líneas de negocio6.
Flujo mínimo de importación y cálculo
- Cargar la previsión de ventas en SC4 vía MATA700, respetando el período de vigencia.
- Ejecutar PCPA712, que lee la demanda y aplica los puntos de entrada de validación y ajuste de saldo inicial6.
- Revisar resultados en PCPA144, donde el ticket generado identifica el setup y el período procesado7.
- Generar los documentos derivados solo si el ticket pasa la validación de P144VLGD6.
Un desajuste entre las fechas de vigencia del pronóstico en SC4 y el horizonte configurado en el MRP omite demanda del cálculo. Esto genera compras o producción insuficientes — el mismo riesgo estructural que ocurre cuando el pronóstico se carga sin disciplina de datos1.
¿Cómo registrar y mantener el pronóstico de ventas directamente en la tabla SC4 mediante inclusión manual?
Registrar el pronóstico de ventas directamente en la tabla SC4 significa capturar a mano cada previsión mediante la rutina MATA700 — producto, período, unidad y cantidad — sin esperar a que un proceso automático importe los datos. Es el método más directo que ofrece Protheus. También es el más expuesto al error humano cuando la operación crece.
Campos obligatorios en SC4
Cada registro necesita, como mínimo, cuatro datos: código del producto (CODIGO), familia de compra (FAMCIA), período de la previsión (PERIODO) y cantidad prevista (QUANTIDADE). Sin estos cuatro campos completos y consistentes, el MRP no puede incorporar el registro al cálculo de necesidades1.
Vigencia: el detalle que más se olvida
Cada previsión debe llevar fecha de inicio y fecha fin alineadas al calendario de planificación. Un pronóstico con fecha vencida simplemente no es leído por la rutina de cálculo del MRP (PCPA712), aunque el registro siga existiendo en la tabla6. Esto explica por qué, muchas veces, el plan de producción no refleja lo que el analista cree haber cargado: el dato está en SC4, pero fuera de ventana de consumo.
¿Para quién funciona la inclusión manual?
| Escenario | Inclusión manual en SC4 |
|---|---|
| Empresa pequeña, pocos SKUs | Viable, bajo riesgo |
| Ajuste puntual o excepción | Adecuado |
| Empresa mediana/grande, múltiples líneas | Riesgo alto de inconsistencia y duplicación de esfuerzo |
La rutina de previsión de ventas (MATA700) se diseñó como herramienta de apoyo para empresas que fabrican contra stock (make to stock). Permite que el área de Planificación y Control de la Producción programe cantidades y cuantifique necesidades de material, mano de obra y equipos1. Pero esa misma lógica manual, replicada en decenas de categorías de producto, multiplica el esfuerzo y el margen de error en operaciones de mayor escala1.
Validación contra pedidos reales
Protheus permite que previsión y pedido de venta coexistan para el mismo producto y período — de hecho, ambos se suman al saldo de salidas previstas del MRP2. Pero al momento de generar la Central de Compras, el sistema prioriza la demanda real (pedidos confirmados) sobre la previsión, y así evita que un pronóstico desactualizado dispare compras innecesarias8. Validar esta superposición antes de confirmar cada inclusión es, por tanto, un paso obligatorio — no opcional — del proceso manual en SC4.
¿Cómo usar el pronóstico de ventas en la Central de Compras mediante la rutina MATA179 (SIGACOM)?

La rutina MATA179 (Central de Compras) toma el pronóstico registrado en MATA700 — almacenado en la tabla SC4 — y lo cruza con el histórico de consumo para generar propuestas de compra automáticas, filtrables por familia de producto, almacén y período1. El comprador no parte de cero: el sistema ya le entrega una sugerencia calculada.
Esto funciona mediante el método de Demanda Generada, que exige una secuencia de configuración obligatoria antes de que la Central de Compras pueda sugerir algo útil8:
- Crear el producto (MATA010) e insertar su saldo inicial (MATA220).
- Registrar el proveedor (MATA020) y vincularlo al producto (MATA061).
- Definir la matriz de abastecimiento (MATA001).
- Registrar movimientos de entrada y salida de varios meses.
- Calcular costo de entrada (MATA190) y costo de reposición (MATA320).
- Ejecutar la demanda generada (MATA285) y, finalmente, MATA179.
En una demostración con movimientos mensuales reales, la Central detectó un saldo negativo de -23 unidades tras enero, febrero y marzo. Al configurar 120 días de cobertura, sugirió comprar exactamente esas 23 unidades8. Es la lógica demanda-versus-oferta funcionando sin intervención manual del comprador.
Aquí está el punto que casi nadie en PCP se detiene a verificar: la Central de Compras es tan buena como el pronóstico que la alimenta. Si el área comercial no actualiza la previsión en SC4 — porque el pronóstico vive aislado del CRM, en una hoja de cálculo o en la memoria del gerente de ventas — MATA179 generará propuestas de compra basadas en una demanda que ya no existe2. No es un error del sistema. Es la consecuencia directa de un pronóstico que no se sincroniza con la realidad comercial diaria.
¿Cómo dar seguimiento al pronóstico de ventas y a las oportunidades a través del módulo CRM?
El módulo CRM (SIGACRM) de Protheus da seguimiento al pronóstico cuando funciona como puente entre lo que el vendedor negocia y lo que PCP y Compras planifican. Captura oportunidad, probabilidad de cierre, monto estimado y período de cada negociación, y esos datos pueden exportarse hacia la tabla SC4 como insumo para la previsión de ventas (MATA700)1. El área de trabajo del CRM (CRMA290) concentra en una sola pantalla accesos directos a pedidos de venta y a "mis oportunidades", lo que facilita que el vendedor registre esa información sin saltar entre módulos9.
El problema es que la conversión de oportunidad a pronóstico casi nunca es automática. Requiere una acción manual o una rutina de importación configurada expresamente para ese fin. Si nadie la mantiene, CRM y Compras (SIGACOM) terminan operando en silos: oportunidades cerradas que no actualizan SC4 generan pronósticos fantasma que no corresponden a ninguna negociación real.
Medir la desviación entre pronóstico y ventas realizadas te dice si ese puente existe de verdad. Una brecha superior al 20-30% suele señalar que el área comercial no está sincronizada con PCP, no que el mercado cambió de forma impredecible.
Esto no es un problema de disciplina del vendedor. Es un problema de arquitectura, porque el dato depende de que alguien capture manualmente un paso intermedio. En Play2sell SalesOS, el módulo Leads resuelve justo esa brecha: captura eventos comerciales por integración, sin depender de que el vendedor tipee la oportunidad, y entrega datos limpios y en tiempo real al resto de la operación. El siguiente paso concreto: audita cuántas oportunidades cerradas en tu CRM nunca llegaron a SC4 el trimestre pasado.
¿Cuáles son las diferencias e integración entre SIGAPCP, SIGACOM y CRM en el tratamiento del pronóstico de ventas?
SIGAPCP, SIGACOM y CRM tratan el pronóstico de ventas de forma distinta porque cada uno tiene un rol fijo en la cadena: solo SIGACOM es dueño de la tabla SC4, donde vive el pronóstico oficial (MATA700); SIGAPCP la consume para calcular necesidades de material vía MRP; y el CRM casi nunca la toca de forma nativa2.
Esto crea una cadena de dependencia, no una integración real.
| Módulo | Rol frente al pronóstico | Limitación |
|---|---|---|
| SIGACOM | Custodio de SC4; registra y distribuye el pronóstico a compras1 | Depende de carga manual o de integración con S&OP1 |
| SIGAPCP | Consume SC4 para el cálculo del MRP (PCPA712)6 | No tiene interface directa con el CRM |
| CRM (SIGACRM) | Genera oportunidades y proyecciones comerciales en el área de trabajo del vendedor9 | Carece de mecanismo nativo para publicar el pronóstico en SC4 |
En la práctica, el flujo típico se ve así:
- El CRM registra oportunidades y proyecciones de cierre.
- Un analista exporta esos datos a Excel de forma manual.
- Alguien los importa a SC4 vía MATA700 o una rutina personalizada.
- SIGAPCP consume esa información en el cálculo del MRP10.
Cada paso manual es un punto de fallo y de retraso. No es un defecto de las personas — es una arquitectura sin puente nativo entre ventas y planificación.
¿Cuáles son las buenas prácticas para obtener datos confiables del área comercial y alimentar el pronóstico de ventas?
Un pronóstico de ventas confiable depende de reglas claras de gobernanza, no del esfuerzo aislado del analista que lo captura. Sin un propietario único y un ciclo de revisión definido, los datos que alimentan el MRP se degradan con el tiempo. Ese deterioro arrastra errores de planificación a toda la cadena2.
Gobernanza mínima para el pronóstico
- Designa un propietario único — analista de PCP o gerente comercial — responsable de validar y autorizar cada cambio en la previsión antes de que impacte el MRP1.
- Establece un ciclo de actualización mensual como mínimo, alineado con la lógica de previsión por categoría que usan los sistemas comerciales modernos1.
- Exige que ventas entregue el pipeline estructurado: producto, cantidad, período y probabilidad de cierre.
- Excluye oportunidades con probabilidad menor a 40% y trata las mayores a 80% como demanda confirmada.
- Compara el pronóstico propuesto contra lo realmente vendido en los últimos 12 meses. Una desviación sistemática señala que la metodología necesita ajuste, no solo el dato puntual11.
El punto ciego sigue siendo la captura manual: cuando el vendedor tiene que tipear el dato, el dato llega tarde o no llega. Las plataformas que capturan eventos de venta directamente desde el CRM vía integración — como el módulo Leads de Play2sell SalesOS — eliminan esa dependencia. Así, el pronóstico se actualiza con mayor frecuencia sin exigir trabajo administrativo adicional al equipo comercial.
¿Cuáles son los errores comunes y puntos de atención en la parametrización del pronóstico de ventas en Protheus?

La parametrización del pronóstico de ventas en Protheus falla cuando tres cosas quedan sin control: la vigencia de los registros en SC4, la deduplicación frente a pedidos reales y la sincronización con el área comercial. Cualquiera de estas grietas deja al MRP tomando decisiones sobre datos que ya no representan la realidad del negocio.
- Pronóstico vencido sin alerta. Si un registro de previsión en SC4 queda fuera de vigencia, el cálculo de MRP (PCPA712) ignora esa demanda sin generar aviso visible. El faltante aparece después, cuando ya es tarde para corregirlo 2.
- Duplicación de demanda. Cuando un producto tiene previsión y pedido de venta confirmado en el mismo período, el sistema suma ambos documentos al saldo de salidas previstas — a menos que se configure explícitamente el parámetro ¿Descuenta PV. de Previsión? al generar la Demanda del MRP 2.
- Desconexión entre CRM y previsión. El módulo de ventas del CRM (CRMA290) concentra pedidos y oportunidades en un panel propio 9. Pero si ese flujo comercial no está integrado operativamente con la rutina MATA700, la actualización del pronóstico depende de una carga manual separada — y cualquier demora ahí se traslada directo al MRP.
- Parametrización débil en PCPA144. Sin un mapeo correcto de categorías de producto, la inclusión de previsiones falla silenciosamente o se agrupa de forma genérica. La función de cuadrícula, además, exige configurar previamente el parámetro MV_GRADE en "T" — si se omite, lo registrado no coincide con lo que el MRP realmente planifica 1.
- Ausencia de trazabilidad. Los puntos de entrada de PCPA712, como P712VLD, permiten validar parámetros antes de avanzar en el cálculo 6. Pero sin un historial de versiones del pronóstico fuera de esa validación técnica, ningún gerente comercial puede explicar después por qué una orden de producción falló.
Estos cinco puntos no son errores de digitación: son huecos estructurales en cómo el dato comercial entra al sistema. El mismo patrón —datos que dependen de la buena voluntad del equipo de ventas— explica por qué tantas operaciones comerciales viven atrapadas en reportes que nadie confía del todo.
Preguntas frecuentes sobre pronóstico de ventas en Protheus
Estas son las dudas que más recibimos de analistas de PCP y administradores de ventas al configurar el pronóstico dentro de Protheus. Cada respuesta parte de cómo funciona el motor de cálculo del MRP, no de una preferencia de configuración.
¿Puedo importar el pronóstico desde Excel?
Sí. La importación se hace mediante la rutina MATA700, dentro de SIGAFAT, con una plantilla que respeta la estructura de la tabla SC41. No es un proceso en tiempo real. Es manual y requiere, como mínimo, una revisión semanal para que el dato siga siendo representativo del mercado3.
¿Qué pasa si el pronóstico queda en cero?
Un pronóstico en cero no significa falta de dato — es un dato explícito de no-demanda. PCPA712 lo procesa como tal y genera un MPS en cero para ese producto. La sugerencia de producción se detiene, salvo que existan pedidos de venta reales cargados en SC5/SC62.
¿El pronóstico debe ir por familia o por producto?
SC4 admite ambas estructuras. Protheus permite crear previsiones sobre categorías de productos, lo que facilita el trabajo cuando distintos responsables gestionan distintas líneas1. Lo granular por producto da precisión, pero exige más mantenimiento. El enfoque híbrido suele rendir mejor en campo.
¿Cada cuánto se debe actualizar?
El mínimo operativo es mensual. Semanal es el estándar óptimo cuando la captura no depende de digitación manual del vendedor3.
¿Cuál es la diferencia entre pronóstico y demanda?
El pronóstico es una estimación; la demanda son pedidos de venta confirmados. Protheus suma ambos saldos en el MRP salvo que se active el parámetro de descuento. Sin esa configuración, el sistema puede sobreestimar las salidas previstas2.
Próximos pasos: Moderniza tu captura de pronóstico con automatización de eventos
El problema de fondo no es que tu equipo de ventas sea indisciplinado al capturar datos: es que el flujo entre CRM y pronóstico depende de tipeo manual, y todo flujo que depende de tipeo manual se degrada con el tiempo. Cuando el vendedor registra una propuesta o un cierre días después de que ocurrió, esa información llega tarde a la tabla SC4, y el MRP calcula con datos viejos. Por eso la previsión de ventas registrada en MATA700 solo vale lo que valga la disciplina de captura detrás de ella1.
La solución estructural es capturar el evento comercial en el momento en que ocurre, sin depender de que el vendedor abra el CRM y lo escriba. Play2sell SalesOS —específicamente el módulo Leads— opera encima de tu CRM actual, sin reemplazarlo. Captura eventos como propuesta enviada, negociación avanzada o cierre directamente por integración, y alimenta el pronóstico de forma continua en lugar de depender de actualizaciones semanales manuales.
Qué hacer esta semana
- Audita tu flujo actual: desde que el vendedor avanza una oportunidad hasta que ese dato aparece en SC4. Si el proceso es manual o se actualiza una vez por semana, ya tienes una brecha de varios días entre lo que pasa en campo y lo que ve PCP.
- Mide la desviación actual entre pronóstico y venta real antes de cambiar nada. Esa es tu línea base.
- Solicita una demostración de cómo la captura automática de eventos sincroniza el pronóstico sin exigir esfuerzo adicional al vendedor.
La métrica que importa es simple: reducir la desviación entre pronóstico y venta real en más de 40%. Con captura automática de eventos, los equipos que migran de actualización manual a eventos en tiempo real suelen ubicarse entre 15% y 25% de desviación a los 90 días —muy por debajo de las brechas que aparecen cuando el dato depende de que alguien recuerde escribirlo.
## Fuentes- MATA700 – Previsión de Ventas — https://centraldeatendimento.totvs.com/hc/es/articles/35201464649367-Cross-Segmentos-TOTVS-BackOffice-L%C3%ADnea-Protheus-MI-Facturaci%C3%B3n-SIGAFAT-MATA700-Previsi%C3%B3n-de-Ventas ↩
- Cómo trata el MRP las previsiones de venta y los pedidos de venta — https://centraldeatendimento.totvs.com/hc/es/articles/22692718926615-TOTVS-MANUFACTURA-TOTVS-Manufactura-L%C3%ADnea-Protheus-MI-Planificaci%C3%B3n-y-Control-de-la-Producci%C3%B3n-SIGAPCP-C%C3%B3mo-trata-el-MRP-las-previsiones-de-venta-y-los-pedidos-de-venta ↩
- Pronósticos de venta (LATAM) — https://www.infor.com/latam/blog/sales-forecasts ↩
- Introducción a la gestión de inventarios: Explicación del plan maestro de producción (MPS) — https://www.optiproerp.com/es/blog/inventory-management-101-master-production-schedule-mps-explained ↩
- MRP (em Memória) – PCPA712 — https://mastersiga.tomticket.com/kb/planejamento-e-controle-de-producao-sigapcp/mrp-em-memoria-pcpa712 ↩
- Puntos de Entrada para la rutina PCPA712 — https://centraldeatendimento.totvs.com/hc/es/articles/10062708121495-TOTVS-Manufactura-Totvs-Manufactura-L%C3%ADnea-Protheus-MI-Planificaci%C3%B3n-y-Control-de-la-Producci%C3%B3n-SIGAPCP-Puntos-de-Entrada-para-la-rutina-PCPA712 ↩
- Protheus – Geração de Documentos no Novo MRP (em Memória) — https://www.youtube.com/watch?v=Z9JMDeP-x0U ↩
- How To | SIGACOM – Central de Compras – Método Demanda Gerada — https://www.youtube.com/watch?v=qm8qJEus_YU ↩
- How To | MP – SIGACRM – Área de Trabalho (CRMA290) — https://www.youtube.com/watch?v=MhAYbWHxqog ↩
- Integração Protheus e CRM: Como fazer, benefícios e dicas — https://erpserv.com.br/integracao-protheus-e-crm-como-fazer-beneficios-e-dicas ↩
- Conozca el sistema Protheus de TOTVS — https://es.totvs.com/blog/cat-erp/conozca-el-sistema-protheus-de-totvs ↩