В оптике изменился рецепт после заказа линз: как вести заказ

Если после заказа линз изменились исходные данные, не перезаписывайте прежний рецепт в уже отправленном заказе. Сохраните новую подтверждённую версию и установите, какие связанные действия уже выполнены поставщиком и мастерской. Затем согласуйте дальнейший вариант и передайте каждому исполнителю актуальные данные. Решение о самом рецепте принимает специалист, а система учитывает версии и исполнение.

Новая запись рецепта не меняет уже отправленную заявку

Учебный заказ О-01 был оформлен по версии Р-1. Позже появился подтверждённый запрос использовать Р-2. Если продавец просто изменил карточку, поставщик может продолжить работу по Р-1, а сотрудник на выдаче увидит только новые данные. Формально интерфейс выглядит актуальным, но происхождение изготовленного результата больше не объясняется.

Зафиксируйте, откуда получена новая версия, кто подтвердил её применение и какие документы она заменяет в дальнейшем процессе. Не смешивайте медицинское содержание и организационное решение по заказу. В этой статье не оцениваются параметры рецепта, пригодность линз и правильность назначения.

У отправленной версии должен оставаться снимок

Сохраняйте состав данных, с которым заявка ушла поставщику или мастерской, вместе с идентификатором внешнего обращения. Живая ссылка на изменяемую карточку не доказывает, что именно видел исполнитель раньше. Если требуется исправление, оно должно быть связано с прежней отправкой, а не стирать её.

В CRM для оптики полезны отдельные связи между рецептом, клиентским заказом, заявками на линзы и работой мастерской. Это предлагаемая модель. Не следует обещать, что обновление одной карточки автоматически исправит каждую внешнюю систему.

Перед изменением проверьте стадию каждой связанной позиции

В документации ИТигрис заявка на отсутствующую линзу отделена от конкретного поступившего товара. Изменение заявки в оформленном заказе рассматривается отдельно от замены уже добавленной линзы и ограничено этапом обработки. Это свойства конкретной системы, а не универсальное право редактировать любой заказ до выдачи.

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

Матрица запроса Р-2 при существующем заказе Р-1

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

Сообщение об изменении и его принятие — разные факты

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

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

Последствия по срокам и расчёту согласуются отдельно

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

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

Мастерская должна получить понятное актуальное задание

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

В автоматизации документов свяжите принятую версию с формируемыми документами. Их содержание должно соответствовать тому состоянию, которое они подтверждают. Перепечатанный документ с Р-2 не превращает ранее выполненную по Р-1 работу в результат новой версии.

Что увидит сотрудник перед выдачей

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

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

Приёмка на вымышленном заказе без медицинских данных

1. Создайте заказ с условными версиями Р-1 и Р-2 без реальных параметров рецепта. Сохраните, какую версию приняли для первой отправки.
2. Проверьте изменение до отправки и после внешнего принятия. Ожидание ответа должно отличаться от подтверждённой корректировки.
3. Разведите стадии двух связанных позиций. Одна готовая часть не должна автоматически подтверждать вторую.
4. Получите учебный отказ в изменении и выберите предусмотренный дальнейший вариант. Исходная история не должна быть переписана.
5. Передайте актуальное задание мастерской и проверьте его принятие. Повтор внешнего ответа не создаёт нового исполнения.
6. Перед выдачей сопоставьте принятое основание и фактический результат. Все открытые вопросы должны быть видны ответственному.

Такой учёт нужен для ответа на конкретный вопрос: по какой версии выполнена каждая часть заказа. Он не выбирает рецепт за специалиста и не устанавливает универсальные условия возврата. Сохранённые версии и реальные подтверждения позволяют разбирать изменение без догадок по сегодняшнему виду карточки.