Registro de pedidos (Orders Registry) en el CRM

Visión general

El Registro de pedidos (Orders Registry) es un historial de compras centrado en el contacto. Para cada contacto (y, opcionalmente, para cada negocio) registras los pedidos con título, valor, moneda, estado y fecha, armando una vista clara de todo lo que esa persona ya compró.

Es importante entender lo que es y lo que no es: el registro de pedidos es un log, no una pasarela de pago. No cobra, no reembolsa ni concilia dinero — del cobro se encarga el módulo de Pagos. Marcar un pedido como "reembolsado" o "cancelado" aquí es solo una anotación en el historial, no una operación financiera.

Los pedidos pueden llegar de varias orígenes: cargados manualmente, recibidos vía webhook, creados por la API, originados del módulo de Pagos o de integraciones de comercio.

Requisitos previos

• El Registro de pedidos es opcional y viene desactivado por defecto. Pide a un administrador que lo habilite para la cuenta.
• Permiso de gestión de CRM para crear y editar pedidos.
• Contactos cargados — todo pedido pertenece a un contacto.

Paso a paso

1. Confirma con un administrador que el Registro de pedidos esté habilitado.
2. En el menú lateral, abre Pedidos. La página reúne los pedidos que puedes consultar, incluidos los vinculados a contactos y negocios existentes.
3. Usa la búsqueda, período, origen, gateway, estado y ordenación para llegar al recorte deseado. Esos filtros quedan en la dirección de la página, por lo que se pueden recargar o compartir.
4. Crea un pedido manual indicando contacto existente, título, valor, moneda y estado.
5. Cuando haya productos, consulta el nombre, cantidad, precio unitario y descuento; conservan la fotografía financiera de la venta.
6. Opcionalmente, indica la fecha del pedido y la fecha de pago, y vincula el pedido a un negocio.
7. Exporta el mismo recorte a CSV o selecciona pedidos manuales para la acción masiva disponible. Los pedidos de integraciones están protegidos contra edición y eliminación en la pantalla: su casilla queda deshabilitada y Seleccionar todos los pedidos manuales de estos filtros también alcanza solo los manuales.
8. Si un pedido integrado tiene el cliente o los vínculos incorrectos, usa Corregir el cliente y los vínculos de la venta. Elige el contacto, revisa el cobro y la recuperación relacionados y aplica la vista previa. Esto no edita la foto financiera y funciona aunque el registro integrado sea inmutable.

Configuración y opciones

• Estado del pedido: pendiente, pagado, parcialmente pagado, en mora, reembolsado, cancelado y fallido.
• Origen (source): manual, webhook, API, Pagos o comercio — identifica de dónde vino el registro.
• Vínculos: todo pedido pertenece a un contacto y puede vincularse a un negocio del CRM.
• Moneda y valor: cada pedido tiene su propio valor y moneda (por defecto BRL).
• Identificador externo: los pedidos de integraciones traen un ID externo que evita duplicados.
• Ítems del pedido: el nombre y los valores de cada ítem son una foto de la venta. Los cambios posteriores en el Catálogo no reescriben lo vendido; cuando existe, el ítem también conserva el vínculo al producto o variación de la misma cuenta.
• Cartera por responsable: cuando la privacidad por responsable está activa, cada vendedor ve solo los pedidos de los contactos/negocios a los que puede acceder.
• Lista global y CSV: la página Pedidos está paginada en el servidor; la exportación respeta los filtros y la selección actual, sin incluir datos fuera de tu alcance.
• Editar vs corregir vínculos: solo los pedidos manuales tienen edición y eliminación normales. La corrección separada de contacto, organización, negocio y conversación conserva importe, estado, ítems, fechas e identidad externa.

Casos de uso

• Mantener el historial de compras de cada cliente directo en el perfil del contacto.
• Seguir, en el negocio, los pedidos ya realizados en esa oportunidad.
• Consolidar pedidos de varios orígenes (manual, Pagos, comercio) en un único log.
• Alimentar automatizaciones e informes según lo que cada contacto compró.
• Comparar, en el informe del Catálogo, el presupuesto de los negocios con el valor efectivamente liquidado de los ítems.

Consejos, límites y buenas prácticas

• Usa el registro de pedidos para historial; para cobrar de verdad, usa el módulo de Pagos.
• Estandariza títulos y estados para facilitar la lectura y los filtros.
• Al integrar vía webhook/API, envía un ID externo estable para no duplicar pedidos.
• Envía también un identificador estable para cada ítem integrado; una nueva entrega del mismo pedido no duplica sus líneas.
• Vincula el pedido al negocio correspondiente cuando tenga sentido, para conectar venta y oportunidad.
• Edita o elimina únicamente registros manuales. En uno importado, usa Corregir cliente y vínculos solo para asociaciones; corrige importe, estado, ítems, fechas o ID externo en la fuente y vuelve a sincronizar.

Solución de problemas

• No veo la sección de Pedidos: el módulo puede estar desactivado para la cuenta — habla con un administrador.
• Pedido duplicado: verifica que la integración esté enviando el mismo ID externo en lugar de crear uno nuevo.
• El pedido no cobró al cliente: es lo esperado — el registro es un log; el cobro se hace en Pagos.
• Cambió el nombre o precio del Catálogo: el ítem registrado conserva la foto de la venta original; es intencional para preservar el historial financiero.
• No puedo crear un pedido: revisa tu permiso de gestión de CRM y que el contacto exista.
• No puedo editar un pedido importado: es intencional. Los registros recibidos de Pagos, comercio, API o webhook protegen los hechos financieros frente a reentregas. Si solo el cliente u otra asociación está mal, usa Corregir el cliente y los vínculos de la venta en la fila del pedido.

Ver también

• CRM: pipelines, kanban y negocios (deals)
• Negocios: notas, adjuntos, checklists, ítems de línea y valor automático
• Visión general de Contactos y del CRM

Quitar pedidos de prueba o huérfanos

En Pedidos, los administradores pueden quitar registros creados por cobros o integraciones. Selecciona el tipo de corrección e indica un motivo. El pedido sale inmediatamente de la vista Operativos, pero su origen, responsable, motivo y posibles compensaciones permanecen en el historial de auditoría.

Un pedido manual nunca pagado y sin cobro vinculado puede eliminarse definitivamente. Los pedidos pagados o vinculados a una integración se anulan, no se borran: las comisiones abiertas, el stock y la puntuación de interacción se compensan de forma atómica. Una comisión ya cerrada bloquea la operación para evitar divergencias financieras.

Usa Situación del registro → Anulados para revisar lo retirado. Solo se puede restaurar cuando la anulación no generó compensaciones contables, de stock o interacción y la identidad externa sigue disponible.

Para eliminar el propio cobro, primero archívalo. Solo un cobro no liquidado puede eliminarse definitivamente; se exige un motivo y el pedido relacionado se anula y desvincula antes de borrar el cobro local. Ninguna de estas acciones cancela ni reembolsa dinero en la pasarela.