Registro de pedidos (Orders Registry) en el CRM

Abrir en

Ver como Markdown

Abrir en ChatGPT Abrir en Claude

Conversa Labs

Última actualización el 7 de sep de 2026

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. Cambiar el estado de un pedido manual no llama a la pasarela; aun así, un estado financiero alimenta comisiones, inventario, objetivos y automatizaciones internas, por lo que exige autorización y auditoría.

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.

Cómo editar y cambiar el estado

Un pedido manual todavía no financiero puede corregir título, importe, moneda, fecha y estado por quien gestiona el CRM.
Entrar en parcialmente pagado, pagado o reembolsado exige permiso de gestión de ventas y una justificación. Se conservan el antes, el después, el responsable y el motivo.
Después de producir efectos financieros, importe, moneda, ítems y negocio no se reescriben en el lugar. Usa la corrección de vínculos o la anulación gobernada para preservar comisiones, inventario y objetivos.
Un pedido de Pagos u otra integración es una proyección sincronizada. Abre sus detalles y usa Gestionar en Cobros para localizar el cobro de origen; los pagos confirmed y paid se proyectan como pedido pagado. Corrige los hechos en el origen y sincroniza, en vez de editar el log.
Antes de anular un pedido financiero o integrado, la pantalla muestra las compensaciones y los bloqueos. Comisiones cerradas, reservas confirmadas, recompensas concedidas o distribución entregada bloquean la operación para evitar divergencias.

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

Confirma con un administrador que el Registro de pedidos esté habilitado.
En el menú lateral, abre Pedidos. La página reúne los pedidos que puedes consultar, incluidos los vinculados a contactos y negocios existentes.
Usa la búsqueda, período, origen, gateway, estado, vendedor 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. El filtro de vendedor está disponible para quien gestiona el equipo y usa la asignación canónica de la venta.
Haz clic en el título de cualquier pedido para abrir el detalle. La dirección identifica ese pedido y se puede recargar o compartir; el contacto, organización, negocio y cobros vinculados aparecen como atajos según tus permisos.
Crea un pedido manual indicando contacto existente, título, valor, moneda y estado.
Cuando haya productos, consulta el nombre, cantidad, precio unitario y descuento; conservan la fotografía financiera de la venta.
Opcionalmente, indica la fecha del pedido y vincula el pedido a un negocio. Al marcarlo como pagado, la fecha de pago se registra mediante el flujo controlado.
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.
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, parcialmente reembolsado, en mora, reembolsado, cancelado y fallido. Un reembolso parcial conserva como ingreso reconocido únicamente el saldo no devuelto.
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.
Pedido integrado vs manual: en pedidos creados por Pagos o por una integración, el importe y el estado siguen la fuente y no se sobrescriben en el registro. Abre el cobro vinculado para cancelar, reembolsar o conciliar. Los pedidos manuales se pueden editar desde el detalle.

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.
Al enviar partially_refunded, envía también amount_refunded, mayor que cero y menor que el total.
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. Para cancelar, reembolsar o corregir la liquidación, abre los detalles y selecciona Gestionar en Cobros.
No puedo cambiar el estado de un pedido pagado/integrado: gestiona la operación en el cobro vinculado o en su gateway de origen desde el atajo del detalle. El webhook sincroniza el resultado sin convertir el registro en una segunda fuente de verdad.

Ver también

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.