Referencia generada desde el metamodelo
Este borrador describe evidencia técnica del ERP. Las frases que indican evidencia insuficiente no deben interpretarse como reglas confirmadas.
Manual funcional de Cobro de Pedido
Introduccion
Cobro de Pedido es una entidad ubicada en la categoría Cobros del módulo Ventas. Su propósito funcional es registrar y gestionar el cobro asociado a un Pedido, contemplando un circuito con estados de Creado, Aprobado y Anulado.
Se encontró evidencia de relaciones con entidades de medios de cobro y registración (por ejemplo, Caja, Banco, Cuenta bancaria, Recibo/Cobro), además del Pedido al que impacta.
Nota: No se encontró evidencia suficiente sobre pantallas, permisos, validaciones de importes/monedas, ni sobre el detalle de los campos (monto, fecha, medio de pago, etc.). Este documento es un borrador funcional basado únicamente en la evidencia provista.
Mapa de estados (vision funcional)
| Estado | Tipo | Objetivo funcional | Editable por usuario |
|---|---|---|---|
| Creado | Inicial | Registrar el cobro en estado preliminar y permitir que el sistema complete datos iniciales. | No se encontró evidencia suficiente. |
| Aprobado | Operativo | Confirmar el cobro. Se evidencia una acción automática: ** Reserva Pedido ** al aprobar. | No se encontró evidencia suficiente. |
| Anulado | Excepción | Dejar sin efecto el cobro. Se evidencia un evento al anular (acciones internas del sistema). | No se encontró evidencia suficiente. |
Que completa el sistema automaticamente
- Completa datos iniciales al estar en estado Creado.
- Autoaprobación si corresponde (no se encontró evidencia suficiente sobre las condiciones que disparan esta autoaprobación).
- Reserva Pedido al pasar/estar en estado Aprobado (no se encontró evidencia suficiente sobre el alcance exacto de la reserva ).
- Evento al anular al pasar/estar en estado Anulado (no se encontró evidencia suficiente sobre qué actualiza o revierte).
Reglas funcionales clave
- El registro debe estar asociado obligatoriamente a un Pedido mediante el campo Pedido (PEDI_ID_PEDI).
- El circuito contempla los estados: Creado ’ Aprobado y la posibilidad de Anulado (no se encontró evidencia suficiente sobre transiciones permitidas, reversión de aprobado, o restricciones por permisos).
- Existen relaciones funcionales con:
- PEDIDO (vínculo principal).
- CAJA, BANCO, CUENTA_BANCARIA (potenciales destinos/orígenes del cobro).
- COBRO y/o RECIBO (registración/comprobante; la evidencia lista Cobro como entidad relacionada y Recibo como integración).
- CONCEPTO_DE_COBRO_EL (concepto de cobro electrónico).
- CONCEPTO_RETENCION (retenciones).
- No se encontró evidencia suficiente para reglas de: cálculo de retenciones, conciliación bancaria, control de saldo del pedido, numeración de recibos, manejo de múltiples medios de pago, ni validaciones contables/fiscales.
Campos funcionales mas consultados
| Campo | Significado funcional |
|---|---|
| PEDI_ID_PEDI | Pedido asociado al cobro (obligatorio). La referencia funcional se apoya en el identificador/atributo NUMERO del Pedido. |
Preguntas frecuentes (FAQ)
- ¿Para qué se utiliza Cobro de Pedido ?
- Registrar un cobro vinculado a un Pedido dentro del módulo Ventas, y gestionarlo a través de un circuito de estados (Creado / Aprobado / Anulado).
- No se encontró evidencia suficiente sobre si el objetivo incluye emisión de recibo, asiento contable o conciliación automática.
- ¿Qué información mínima necesito para crear un Cobro de Pedido?
- Seleccionar el Pedido (PEDI_ID_PEDI), ya que es obligatorio.
- No se encontró evidencia suficiente sobre otros campos obligatorios (importe, fecha, medio de pago, moneda, etc.).
- ¿Qué ocurre cuando se aprueba un Cobro de Pedido?
- El sistema ejecuta una acción identificada como ** Reserva Pedido **.
- No se encontró evidencia suficiente sobre si esta reserva impacta stock, saldo, estado del pedido o disponibilidad de crédito.
- ¿Qué ocurre cuando se anula?
- El sistema dispara un ** Evento al anular **.
- No se encontró evidencia suficiente sobre si revierte movimientos en Caja/Banco, retenciones o relaciones con Recibo/Cobro.
- ¿El sistema puede aprobar automáticamente el cobro?
- Sí, existe una acción de ** Autoaprobación si corresponde **.
- No se encontró evidencia suficiente sobre las condiciones (por ejemplo, tipo de medio de pago, configuración por caja/banco, permisos, importes, etc.).
Integraciones funcionales relevantes
- Pedido (PEDIDO): entidad principal vinculada por PEDI_ID_PEDI.
- Caja (CAJA): posible registración del ingreso por caja (campo: CAJA_ID_CAJA).
- Banco (BANCO): posible registración/afectación bancaria (campos: BANC_ID_BACK, BANC_ID_BANC).
- Cuenta bancaria (CUENTA_BANCARIA): cuenta asociada (campo: CUDE_ID_CUDE).
- Cobro (COBRO): relación directa (campo: COBR_ID_COBR).
- Recibo: listado como integración relevante (no se encontró evidencia suficiente del/los campos de vínculo).
- Concepto de cobro electrónico (CONCEPTO_DE_COBRO_EL): concepto asociado (campo: CDCE_ID_CDCE).
- Concepto Retención (CONCEPTO_RETENCION): retenciones asociadas (campo: CORE_ID_CORE).