Приглашаем к тестированию LadVen OSЗапросить демо
Перейти к основному содержимому

Заказ, исполнение и приёмка

Эта страница описывает сквозной процесс Operations: коммерческий заказ, план исполнения, передачу позиций и приёмку. Названия и доступность действий зависят от прав, клиента, юридического лица и состояния рабочего процесса.

1. Создать и подтвердить заказ

Концептуальная схема процесса; это не интерфейсный скриншот и не доказательство состояния.

Откройте /operations/orders/new или перейдите из карточки клиента. Добавьте одну или несколько строк заказа — от 1 до 40. У каждой строки свои предложение каталога, количество, единица и замороженные условия цены; последнюю строку удалить нельзя. Смешивать валюты в одном заказе нельзя: это блокирует отправку. Если справочник или условия недоступны, не подменяйте их нулём и не создавайте заказ вслепую; ошибка условий относится к конкретной строке и предлагает повторить проверку только для неё.

После выбора клиента и первой позиции/цены портал предлагает название «предложение — клиент». Пока вы его не редактировали, оно обновляется при смене выбора; после ручной правки портал сохраняет ваш текст. В заказе название можно оставить пустым: в списке будет нейтральный fallback, поэтому не сочиняйте данные ради формы.

Жизненный цикл заказа:

draft → submitted → confirmed → provisioned

Сначала сохраните черновик и отправьте его на подтверждение. Для переходов нужны основание или ссылка и актуальная версия записи. Подтверждение превращает заказ в обязательство; затем его можно передать в план исполнения. Если действие не принимается, проверьте права и обязательные поля, обновите карточку и только потом повторяйте его.

Для строки управляемой услуги (managed_service) действует отдельный шаг Подключить услугу. Право на услугу создаётся или переиспользуется только после этой команды: ни подтверждение заказа, ни запуск плана сами по себе его не создают. Если кнопка недоступна или в разделе Услуги и SLA нет права, проверьте состояние строки и доступ, перечитайте карточку и только потом повторяйте действие.

В списке /operations/orders можно фильтровать клиента и статусы draft, submitted, confirmation_pending, confirmed, on_hold, completed. Строки могут иметь статусы provisioned, fulfilled, cancelled или closed; эти состояния доступны при просмотре заказа. Список поддерживает таблицу и карточки, общий счётчик и постраничную загрузку.

Если строка доступна вам, откройте паспорт заказа по адресу /operations/orders/:orderId: там собраны позиции, стороны, статус и следующий доступный шаг. Ссылка адресная и подходит для передачи коллегам, но доступ по-прежнему зависит от прав.

В подтверждённом заказе ниже отображается прогресс каждой позиции плана: planned, in_progress, handed_over, accepted или cancelled. Если фактически передано всё требуемое количество, строка помечается «Передано полностью», даже если общий статус плана ещё не обновился. Для действия переходите в /operations/fulfillment и перечитывайте актуальную строку; не выводите факт передачи только из общего статуса заказа.

Реестр по умолчанию охватывает всех доступных клиентов, загружает до 25 строк и продолжает список кнопкой Показать ещё. Фильтры и переключатель «таблица/карточки» локальны для экрана; отсутствие строки, ошибка загрузки и отфильтрованный пустой результат — разные состояния.

Если связанные чтения доступны, паспорт заказа показывает блок Что выросло из заказа: ссылки на созданные обязательства и дела приёмки ведут в их карточки. Блок может отсутствовать при пустом результате или ошибке чтения; отсутствие блока не доказывает, что производных записей нет.

2. Подготовить исполнение

Концептуальная схема процесса; это не интерфейсный скриншот и не доказательство состояния.

В /operations/fulfillment проверьте план и его позиции. Планы в состоянии planning или blocked можно перевести в ready, а ready или partially_completed — запустить. Для каждого перехода нужны непустое подтверждение или ссылка и актуальная версия.

Запустить план и передать отдельную позицию — разные шаги. Запуск переводит план в рабочее состояние, но не передаёт ни одной позиции. Передача доступна только для плана in_progress, пока по выбранной строке остаётся непереданное количество; проверяйте статус строки и остаток перед действием.

Реестр передач по умолчанию охватывает всех клиентов; фильтр клиента локален для текущего экрана и не сохраняется. Блок планов «обещано, но ещё не передано» загружается только после выбора клиента; снимите фильтр, чтобы вернуться ко всем передачам. Пустой блок планов без выбранного клиента не означает отсутствие данных.

В карточке клиента каждая передача ведёт в этот реестр уже с фильтром клиента в адресе, а строка открывает отдельную карточку доставки по маршруту /operations/fulfillment/deliveries/:deliveryId. Это карточка просмотра сведений и состояния, а действия строки — Приёмка, Возврат, Исправить, Проблема и Отменить — по-прежнему запускаются из реестра. Заголовок строки использует название поставки, если оно есть, а способ поставки остаётся запасным вариантом для старых записей.

При открытии карточка может сначала показывать загрузку: дождитесь завершения и не делайте вывод об отсутствии данных. Временная ошибка предлагает Повторить; повторно перечитывается карточка, но действие не выполняется. При отказе в доступе запросите его или вернитесь в реестр — это не означает, что доставка отсутствует. Карточка без строк может быть корректным пустым состоянием: она не запускает действия и не является ошибкой.

Поставки отображаются в общем реестре с таблицей/карточками и меню действий строки. Недоступные действия остаются видимыми с объяснением причины; после операции реестр перечитывается, а сообщение об успехе не заменяет проверку фактического статуса.

Не считайте план готовым только потому, что заказ подтверждён. Проверьте позиции, количество, единицу, ответственного и юридическое лицо. Отсутствующий рабочий пакет может быть ещё не материализован или уже связан с разделом нарядов; это разные состояния и ни одно само по себе не подтверждает назначение задачи исполнителю.

Пустая ячейка «Наряд» также может быть нормальной: если профиль исполнения не использует executionContainerPolicy=work_order, работа учитывается на позиции, но это не доказывает создание, назначение или выполнение задачи. Если политика требует наряд, «Ещё не создан» означает только, что пакет ещё не материализован; это не то же самое, что ошибка доступа. В текущем портале жизненный цикл наряда и его пакет не дают пути создания или отправки task-компонента и не подтверждают, что исполнитель получил или завершил работу. Перед передачей или проверкой завершения сверяйте фактический результат в согласованном контексте задач и исполнителя; если он недоступен, остановитесь и уточните у владельца портала, не обходя это прямым API-вызовом.

3. Передать позицию

Концептуальная схема процесса; это не интерфейсный скриншот и не доказательство состояния.

Передача возможна только для плана in_progress и только в пределах ещё не переданного или не принятого количества. Для каждой передачи укажите доказательство и способ:

  • физический товар передаётся как shipment;
  • для остальных типов используется способ услуги.

Передача может создать доставку без полного результата. Если результат неполный, сначала обновите план и историю — не повторяйте действие вслепую, чтобы не получить дубликат. Отмена доставки требует непустой причины; уже переданная позиция и устаревшие данные обрабатываются отдельно.

В меню строки доступны Исправить и Возврат, когда поставка уже передана; оба действия требуют обязательного описания причины и работают только для поставки из одной строки. Возврат дополнительно требует текущую версию поставки и недоступен после решения по приёмке; исправление сохраняется рядом с исходной записью. Если строк нет или строк несколько, меню объясняет ограничение. Статусы реестра могут показывать ready_for_handoff, received, accepted, returned и exception («Проблема»), поэтому не трактуйте сырые коды как отдельные складские операции.

Если после передачи появилась запись доставки, но подтверждение ещё не отображается, сначала перечитайте реестр, а не создавайте вторую доставку. При отмене причина обязательна; обновите карточку перед повтором. Уже переданную позицию отменять нельзя.

Созданную по ошибке доставку можно отозвать только в состояниях planned, ready_for_handoff или exception, пока по ней не записана переданная строка. После передачи действие не предлагается. Отзыв требует причины и актуальной версии карточки; успешный результат получает статус cancelled. Дата в реестре — время создания доставки, а факт передачи определяется статусом.

Если в текущей версии доступна кнопка Отметить проблему, это отдельная фиксация инцидента, а не действие над товаром. В неполностью локализованном интерфейсе исходная подпись может оставаться Report a problem; смысл действия от этого не меняется. Кнопка может быть доступна для planned, ready_for_handoff, partially_handed_over и handed_over; укажите, что произошло. Поставка получает состояние проблемы, но возврат, приёмка и движение по складу не запускаются. При смене состояния или версии карточки обновите реестр и повторите проверку.

В карточке приёмки название исходного заказа теперь является ссылкой на /operations/orders/:orderId, если заказ разрешено открыть. При недоступном или ещё не загруженном названии портал использует нейтральную подпись и не показывает технический ID.

4. Проверить приёмку

Концептуальная схема процесса; это не интерфейсный скриншот и не доказательство состояния.

Раздел /operations/acceptance и карточка приёмки показывают исходный заказ, принятые и отклонённые количества, статус, даты, предупреждение о необходимости доработки, связанные документы и историю. Для прямого открытия карточки используйте /operations/acceptance/:acceptanceCaseId.

В общем списке строка приёмки получает название исходного заказа; если название заказа ещё не загрузилось, используется нейтральное «Приёмка». Статусы показываются как draft (черновик), collecting_evidence (собираем подтверждение), ready_for_submission (готово к отправке), submitted (отправлено клиенту), pending (ожидает решения), under_review (на рассмотрении), partially_accepted (принято частично), accepted (принято), rejected (отклонено) и cancelled (отозвано). В состоянии ready_for_submission портал показывает кнопку Отправить клиенту; отправка запускает отдельный поток согласования и может ожидать подтверждения второго сотрудника по правилам разделения обязанностей.

Кнопка Открыть приёмку относится к конкретной строке поставки со статусом handed_over, а не только к статусу всей поставки: даже у поставки со статусом exception она может быть доступна, если переданная строка ещё требует приёмки. Для возвращённой или отменённой поставки она не предлагается.

В карточке дела сначала нажмите Приложить доказательство: из draft это переводит дело в collecting_evidence. Исполнитель может отозвать его только из draft: укажите непустую причину и передайте актуальную ревизию. Кнопка Готово к отправке появляется только из collecting_evidence и требует непустой неизменяемой отметки доказательства. В состоянии ready_for_submission доступна кнопка Отправить клиенту. Она создаёт или использует запрос согласования и может потребовать подтверждение второго сотрудника; техническую ссылку решения в пользовательском тексте не показывают. Решение клиента (decide) — отдельный путь другой стороны и не является действием сотрудника. Кнопки принять, отправить на доработку или отклонить появляются лишь при наличии соответствующей capability и разделения обязанностей. Если кнопка недоступна из-за права или разделения обязанностей, зафиксируйте следующий шаг в задаче или документе.

Если клиент подтвердил результат вне кабинета, это можно зафиксировать как ручное свидетельство только по реальному внешнему подтверждению: укажите, кто подтвердил, основание, время и принятый/непринятый объём. Сначала свидетельство записывается, затем отдельным подтверждением применяется к делу. При разделении обязанностей создатель дела, поставки или позиции не записывает свидетельство, а записавший не применяет его; это два разных следующих шага. Портал не передаёт записанное свидетельство коллеге и после ухода со страницы его нельзя повторно открыть по техническому коду. Не копируйте этот код, не обходите правило прямым запросом и согласуйте второго сотрудника до записи.

После решения accepted или partially_accepted карточка приёмки предлагает одним действием обеспечить начисление и ссылку Начисления (маршрут /operations/billing?view=charges). Сумму вручную не вводят: сервер выводит её из принятого количества, замороженных условий и политики, цены единицы и допустимой точности. Повтор идемпотентен: карточка различает «начисление создано» и «начисление уже существовало», не создавая дубль. Действие требует нужной capability и разделения обязанностей; отдельно обрабатываются выключенный billing-триггер, неверные цена/условия/точность, недопустимые состояние или источник приёмки, отсутствие записи и конфликт версии (при конфликте перечитайте карточку). Сумма показывается в валюте выбранной локали и юридического лица; используйте только синтетические примеры, без реальных счетов, банковских или клиентских данных.

Доказательства, деньги и приватность

Концептуальная схема процесса; это не интерфейсный скриншот и не доказательство состояния.

  • Используйте синтетических клиентов, предложения, юридические лица и суммы.
  • Для материалов с суммами проверяйте, что валюта соответствует выбранному языку и юридическому лицу; не переносите валюту между локалями.
  • Подтверждение передачи или приёмки должно объяснять, что именно произошло, кто отвечает и к какой версии заказа относится.
  • Не показывайте реальные договоры, счета, банковские реквизиты, токены и данные клиентов.
  • После ошибки или повторного действия сначала проверьте историю и состояние заказа, затем повторяйте действие с актуальной версией.

Связанные страницы

Концептуальная схема процесса; это не интерфейсный скриншот и не доказательство состояния.