Pedidos, ejecución y aceptación
Esta página describe la cadena de pedido, plan de ejecución, entrega y aceptación. Las acciones dependen de permisos, cliente, entidad legal y del estado del flujo de trabajo.
Crear y confirmar un pedido
Abra /operations/orders/new o entre desde la ficha del cliente. Añada una o varias líneas al pedido, entre 1 y 40. Cada línea tiene su propia oferta de catálogo, cantidad, unidad y condiciones de precio congeladas; la última línea no se puede eliminar. No se permiten monedas mezcladas y el envío queda bloqueado. Si faltan directorio o condiciones, no use ceros ni cree el pedido a ciegas; el error de condiciones se muestra en la línea afectada y permite reintentarlo solo allí.
\nDespués de elegir el cliente y la primera oferta/precio, el portal sugiere un nombre como «oferta — cliente». Mientras no lo edites, cambiar la selección actualiza la sugerencia; tras editarla manualmente, el portal conserva tu texto. Un pedido puede quedar sin nombre y usará un texto neutro en la lista: no inventes datos para completar el formulario.
El ciclo es draft → submitted → confirmed → provisioned. Guarde el borrador, envíelo con una referencia y confírmelo con la versión actual. La confirmación convierte el pedido en compromiso; el aprovisionamiento crea el plan. Si una acción no se acepta, compruebe permisos y campos obligatorios, recargue el pedido y repita solo después.
Para una línea de servicio gestionado (managed_service), el paso separado Conectar servicio es el que crea o reutiliza el derecho del servicio. Confirmar el pedido o iniciar el plan no crea ese derecho por sí solo. Si la acción no está disponible o no aparece ningún derecho en Servicios y SLA, revise el estado de la línea y el acceso, vuelva a leer la ficha y repita solo con datos actuales.
En /operations/orders se pueden filtrar draft, submitted, confirmation_pending, confirmed, on_hold y completed. Las filas también pueden tener provisioned, fulfilled, cancelled o closed; esos estados se ven al abrir el pedido. Hay tabla/tarjetas, totales, paginación, reintento y estados vacíos.
Si tiene acceso a una fila, abra la ficha del pedido en /operations/orders/:orderId para revisar líneas, partes, estado y el siguiente paso disponible. La URL es direccionable y se puede compartir con colegas, pero el acceso sigue dependiendo de los permisos.
En un pedido confirmado, la ficha también muestra el progreso de cada línea del plan: planned, in_progress, handed_over, accepted o cancelled. Cuando la cantidad entregada alcanza la cantidad requerida, la línea aparece como entregada por completo aunque el estado del plan o del pedido principal todavía no se haya actualizado. Para actuar, abra /operations/fulfillment y vuelva a leer la línea actual; no deduzca la entrega solo del estado del pedido principal.
El registro comienza con todos los clientes que el usuario puede leer, carga hasta 25 filas y continúa con Mostrar más. Los filtros de estado/cliente y el selector tabla/tarjetas son locales; resultado vacío, vacío por filtro y error de carga son estados distintos.
Cuando las lecturas relacionadas funcionan, el pasaporte del pedido muestra Qué salió de este pedido con enlaces a las fichas de compromiso y recepción. El bloque puede faltar si el resultado está vacío o la lectura falla; su ausencia no demuestra que no exista ningún registro derivado.
Preparar la ejecución
En /operations/fulfillment revise el plan y sus líneas. planning o blocked pasa a ready; ready o partially_completed puede iniciarse. Cada transición requiere una confirmación o referencia no vacía y la versión actual. Un pedido confirmado por sí solo no significa que el plan esté listo; revise líneas, cantidad, unidad, responsable y entidad legal. Un paquete de trabajo ausente puede no estar creado o estar vinculado en la sección de paquetes de trabajo.
Iniciar el plan y entregar una línea concreta son pasos distintos. Iniciar pone el plan en curso, pero no entrega ninguna línea. La entrega solo está disponible cuando el plan está in_progress y la línea seleccionada aún tiene cantidad pendiente; compruebe el estado y el resto antes de actuar.
El registro de entregas incluye por defecto a todos los clientes; el filtro de cliente solo afecta a esta pantalla y no se guarda. El bloque de planes prometidos pero aún no entregados se carga únicamente después de elegir un cliente; quite el filtro para volver a todas las entregas. Un bloque de planes vacío sin cliente seleccionado no demuestra que no haya datos.
Cada entrega mostrada en la ficha del cliente enlaza ahora aquí con ese cliente ya aplicado en el filtro de la URL, y la fila abre una ficha de detalle de la entrega en /operations/fulfillment/deliveries/:deliveryId. Esa ficha sirve para consultar los detalles y el estado; las acciones de fila Abrir recepción, Devolver, Corregir, Informar de un problema y Cancelar siguen iniciándose en este registro. La fila usa el nombre visible humano de la entrega cuando existe y solo recurre al método de entrega para registros antiguos.
Al abrir la ruta de detalle puede aparecer primero un estado de carga; espera a que termine y no lo interpretes como falta de datos. Un error temporal ofrece Reintentar; reintentar vuelve a leer la ficha y no ejecuta ninguna acción. Si no tienes permiso, solicita acceso o vuelve al registro: eso no significa que la entrega no exista. Una ficha sin líneas puede ser un estado vacío válido: no ofrece acciones para iniciar y no es un error por sí misma.
Las entregas usan el registro compartido, con tabla/tarjetas y un menú de acciones por fila. Las acciones no disponibles siguen visibles con el motivo; después de una operación, vuelva a leer el registro: el mensaje de éxito no sustituye comprobar el estado resultante.
Una celda «Orden de trabajo» vacía también puede ser normal: si no se usa executionContainerPolicy=work_order, el trabajo se registra en la línea, pero esto no demuestra que se haya creado, asignado o completado una tarea. Si la política exige una, «Aún no creada» significa solo que el paquete todavía no se ha materializado; no es lo mismo que un error de acceso. En el portal actual, el ciclo de vida de una orden de trabajo y su paquete no ofrecen una vía para crear o enviar un componente de tarea ni demuestran que una persona ejecutora haya recibido o terminado el trabajo. Antes de la entrega o de revisar el cierre, compruebe el resultado real en el contexto acordado de tarea y responsable; si no está disponible, deténgase y consulte al responsable del portal, sin sortearlo mediante una llamada directa a la API.
Entregar una línea
La entrega solo está disponible con el plan in_progress y para cantidades aún no entregadas o aceptadas. Proporcione evidencia y método: un bien físico usa shipment; los demás tipos usan el método de servicio. Si el resultado es parcial, actualice plan e historial antes de reintentar para evitar duplicados. Una línea ya entregada, una versión obsoleta y un conflicto son resultados distintos. Cancelar exige un motivo.
El menú de la fila ofrece Corregir y Devolver cuando ya se ha transferido algo; ambos
requieren una explicación y solo funcionan para una entrega de una sola línea. La devolución
también exige la revisión actual y no está disponible después de decidir la aceptación; la
corrección queda registrada junto al original. Si no hay líneas o hay varias, el menú explica la
restricción. Estados como ready_for_handoff, received, accepted, returned y exception
describen el registro, no implican por sí solos un movimiento de almacén.
Si después de la entrega aparece un registro pero falta la confirmación, lea de nuevo el registro en vez de crear otra entrega. La cancelación exige motivo y una ficha actualizada, y una línea ya entregada no se puede cancelar.
Una entrega creada por error solo se puede retirar en estado planned, ready_for_handoff o exception, mientras no exista una línea transferida. Después de la transferencia la acción no aparece. El retiro exige un motivo y la versión actual de la ficha; si tiene éxito, el estado pasa a cancelled. La fecha del registro es la creación, no la fecha de transferencia; el estado indica si la transferencia ocurrió.
Si la versión actual muestra Report a problem (una interfaz ya localizada puede mostrar Notificar un problema), registra un incidente y no actúa sobre la mercancía. Puede estar disponible en planned, ready_for_handoff, partially_handed_over y handed_over; describe lo ocurrido. La entrega queda marcada como problemática, pero no inicia devolución, recepción ni movimiento de almacén. Si cambió el estado o la versión de la ficha, recarga el registro y vuelve a comprobarlo.
En la ficha de recepción, el título del pedido de origen es ahora un enlace a /operations/orders/:orderId cuando se puede abrir. Si el título no está disponible o aún carga, el portal usa una etiqueta neutra y no muestra un ID técnico.
Revisar la aceptación
/operations/acceptance y la ficha de aceptación muestran pedido, cantidades aceptadas y rechazadas, estado, aviso de retrabajo, fechas, documentos e historial. Para abrir una ficha concreta directamente, use /operations/acceptance/:acceptanceCaseId. La superficie puede ser de solo lectura; aceptar, retrabajar o rechazar requiere permisos separados y separación de funciones. No prometa un control que no aparece.
En la lista común, cada fila de aceptación toma el título del pedido de origen; mientras no se
cargue, usa el fallback neutro Aceptación. Los estados aparecen como draft (borrador),
collecting_evidence (recopilando pruebas), ready_for_submission (lista para enviar),
submitted (enviada al cliente), pending (pendiente de decisión), under_review (en revisión),
partially_accepted (aceptada parcialmente), accepted, rejected y cancelled (retirada).
En ready_for_submission, el portal muestra Enviar al cliente; el envío inicia un flujo de
aprobación separado y puede requerir la confirmación de una segunda persona por separación de funciones.
Abrir aceptación corresponde a una línea de entrega concreta con estado handed_over, no
solo al estado de la entrega: también puede aparecer si la entrega está en exception, siempre
que esa línea ya transferida aún necesite aceptación. No se ofrece para una entrega devuelta o cancelada.
En la ficha de aceptación, elija primero Adjuntar prueba: desde draft esto pasa el caso a collecting_evidence. El personal solo puede retirar el caso desde draft, con un motivo
no vacío y la revisión actual. Listo para enviar aparece únicamente desde collecting_evidence
y exige una marca de evidencia inmutable y no vacía. En ready_for_submission, Enviar al cliente crea o reutiliza la solicitud de aprobación; la referencia técnica de decisión no se muestra al usuario. La decisión del cliente (decide) es un camino
separado de la otra parte, no una acción del personal. Aceptar, retrabajar y rechazar requieren la
capacidad correspondiente y separación de funciones.
Si el cliente confirmó el resultado fuera del portal, registre evidencia manual solo a partir de una confirmación externa real: indique quién confirmó, fundamento, momento y cantidad aceptada o rechazada. Primero se registra el testimonio y después se aplica al caso mediante una confirmación separada. Con separación de funciones, quien creó el caso, la entrega o la línea no puede registrarlo, y quien lo registró no puede aplicarlo: son dos pasos siguientes distintos. El portal no puede transferir el testimonio registrado a otra persona y, al salir de la página, no puede reabrirse mediante su código técnico. No copie ese código, no eluda la regla con una petición directa ni registre antes de coordinar a la segunda persona.
Tras una decisión accepted o partially_accepted, la ficha de aceptación ofrece una acción para asegurar el cargo y un enlace a Cargos (ruta /operations/billing?view=charges). No se introduce manualmente el importe: el servidor lo deriva de la cantidad aceptada, las condiciones y la política congeladas, el precio unitario y la precisión permitida. La repetición es idempotente: la ficha distingue “cargo creado” de “cargo ya existente” y no duplica el registro. La acción requiere la capacidad correspondiente y separación de funciones; un disparador de facturación desactivado, precio/condiciones/precisión no válidos, estado u origen de aceptación no válidos, registro inexistente y conflicto de versión son errores distintos (ante un conflicto, vuelva a leer la ficha). Muestre el importe en la moneda del locale y de la entidad legal seleccionados; use solo datos sintéticos, sin facturas, datos bancarios ni datos reales del cliente.
Evidencia, dinero y privacidad
Use datos sintéticos. Para importes compruebe que la moneda corresponde al idioma y a la entidad legal seleccionados. La confirmación debe explicar qué ocurrió, quién responde y a qué versión del pedido pertenece. No muestre contratos, facturas, datos bancarios, tokens ni datos reales. Tras un error, revise estado e historial y repita solo con la versión actual.
Páginas relacionadas