## 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

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, **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.
4. 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.
5. Crea un pedido manual indicando **contacto existente**, **título**, **valor**, **moneda** y **estado**.
6. Cuando haya productos, consulta el nombre, cantidad, precio unitario y descuento; conservan la fotografía
   financiera de la venta.
7. 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.
8. 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.
9. 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

- [CRM: pipelines, kanban y negocios (deals)](/hc/ajuda/articles/contacts-crm-crm-pipelines-kanban-negocios-es)
- [Negocios: notas, adjuntos, checklists, ítems de línea y valor automático](/hc/ajuda/articles/contacts-crm-crm-notas-anexos-checklists-line-items-valor-es)
- [Visión general de Contactos y del CRM](/hc/ajuda/articles/contacts-crm-overview-es)

### 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.