Покупатель прислал заказ, через час изменил количество, затем переслал тот же файл другому менеджеру. В почтовом ящике появились три сообщения, но заказ остался один. Система, которая на каждое письмо создает новый документ в 1С, ускорит ввод данных и одновременно добавит ошибки, которые придется разбирать отделу продаж и складу.
Автоматизация обработки заказов должна сохранять их состояние на протяжении переписки. Что заказано сейчас, какие условия еще уточняются, какую редакцию подтвердили и что уже записано в учетной системе. Разберем такой процесс на примере B2B-заказа из почты. Это проектный пример, а не описание опубликованного внедрения Nyoka в конкретной конфигурации 1С.
Единица работы — заказ, который меняется в переписке
Письмо служит источником события: появился заказ, пришло уточнение, изменились условия, получена отмена. Событие привязывают к существующему заказу или создают новый после проверки. Тема письма для этой связи ненадежна: ее меняют, пересылают и повторяют. Нужны признаки из самой переписки и учетной системы, а при неоднозначности — решение менеджера.
Для заказа хранится внутренняя карточка: покупатель, исходные сообщения, вложения, текущая редакция, незакрытые вопросы, ответственный и связь с документом в 1С. Содержимое карточки меняется по определенным правилам. Благодаря этому программа отличает поступление нового файла от разрешения перезаписать уже согласованные условия и может показать историю изменений.
Определите границу результата заранее. Для первого этапа им может быть проверенный черновик заказа в 1С, который менеджер принимает перед дальнейшими действиями. Резервирование товара, выставление счета и передача на склад — отдельные операции. Их доступность зависит от конфигурации и правил компании; создание черновика не должно молча запускать весь последующий процесс.
Простую связку чтения письма и записи проверенных полей мы уже разбирали в статье об ИИ, RPA и скриптах. Здесь основной вопрос другой: как обработать изменения одного заказа, когда сообщения приходят повторно, условия расходятся, а связь с учетной системой прерывается в середине операции.
Разберите содержание письма и сохраните спорные места
Большая языковая модель, или LLM, извлекает из письма вид обращения, позиции, количества и сроки. Вложения проходят отдельную обработку: текстовый файл, таблица и скан требуют разных способов чтения. Результат извлечения сохраняется вместе с исходным местом, чтобы менеджер мог проверить нужную строку, не просматривая всю цепочку сообщений.
Сначала отделяют новый запрос от цитаты предыдущего письма. В длинной переписке одинаковые строки могут повторяться несколько раз; подпись и история разговора не означают новую заявку. Если модель приняла старое количество из цитаты за действующее, корректная интеграция запишет в 1С неверное значение. Поэтому разбор сообщений проверяют на реальных цепочках, включая пересылки и вложенные ответы.
Покупателя связывают с карточкой контрагента по установленным идентификаторам и подтвержденным контактам. Отправитель может представлять несколько организаций, а название в подписи отличаться от наименования в учете. Совпадения домена недостаточно для автоматического выбора договора и реквизитов. Неоднозначную связь сохраняют как вопрос менеджеру, а не выбирают первую подходящую запись.
Для товарных строк нужны проверка по номенклатуре и явные единицы измерения. Если клиент написал количество без указания упаковки, программа не должна достраивать его по предыдущей покупке. Она может показать прошлый вариант как контекст для уточнения. Пока обязательное поле не подтверждено, соответствующая часть заказа остается черновиком и не получает право на дальнейшее исполнение.
В нашем проекте обработки дипломов извлечение данных также дополнялось нормализацией и проверкой спорного. Разные формы документов потребовали сочетания нескольких инструментов распознавания. Этот опыт относится к обработке входных материалов; он не подтверждает внедрение заказов в 1С. Для нового потока качество нужно проверять отдельно на письмах и вложениях компании.
Правка клиента меняет определенную редакцию
Фраза «оставьте половину» требует контекста: половину какой позиции и от какого количества. Система должна установить, к какой редакции относится сообщение. Если после первоначального заказа уже была другая правка, простое применение последнего письма к текущим полям может дать неправильный результат. При неясной ссылке нужен вопрос с перечислением конкретных вариантов.
Изменение показывают как разницу между редакциями: было, стало, источник и затронутые действия. Полезно разделять исправление ошибки извлечения и новое пожелание клиента. В первом случае менеджер восстанавливает содержание исходного заказа, во втором — изменяются договоренности. Эти события по-разному влияют на согласование и на уже начатую обработку в учетной системе.
Учебный пример: клиент заказал 20 коробок, затем попросил заменить количество на 12. Пока заказ только в черновике, можно подготовить новую редакцию на 12 коробок. Если предыдущий заказ уже передан в исполнение, требуется предусмотренная компанией процедура изменения. Повторная загрузка последнего письма не должна создать еще один заказ на 12 коробок.
Подтверждение связывают с точной редакцией. Менеджер видит состав заказа, организацию покупателя, количество и существенные условия. Если в момент подтверждения поступила новая правка, система сообщает об изменении и показывает актуальную версию заново. Иначе человек одобрит одну карточку, а программа отправит в 1С другую, уже измененную в фоне.
Одновременная работа нескольких менеджеров требует такого же контроля. Один проверяет реквизиты, другой меняет срок. Перед сохранением система проверяет, не изменился ли заказ после открытия карточки. Несовпадение версий нельзя разрешать незаметной перезаписью всего документа. Специалисту показывают конфликт и дают сохранить согласованное изменение без потери чужой правки.
Отмена — отдельное событие с собственными условиями. Нужно установить, отменяется ли весь заказ, отдельная позиция или только последняя просьба об изменении. После записи в 1С возможность отмены зависит от фактического статуса документа и связанных операций. Агент получает актуальное состояние и готовит допустимое действие, а неоднозначную отмену передает ответственному.
Повтор письма и повтор операции — разные причины дублей
Почтовая интеграция может повторно доставить одно сообщение после сбоя. Клиент может сам отправить заказ еще раз, а менеджер — переслать его в общий ящик. Первый случай обычно выявляется по идентификатору события. Второй требует сопоставления с существующими заказами: формально сообщение новое, хотя деловой смысл мог остаться прежним.
Для каждого события сохраняют отметку обработки и результат. Повторная доставка должна возвращать уже известный исход, а не заново проходить все действия. Для операции записи нужен отдельный постоянный идентификатор, связанный с заказом и его редакцией. Так программа отличает повтор технического вызова от намеренного создания следующего заказа тем же покупателем.
Такое поведение называют идемпотентностью: повтор одного действия не создает дополнительного результата. Обеспечить его одной фразой в инструкции модели нельзя. Нужны хранилище операций и проверка на стороне интеграции, а где возможно — поддержка идентификатора операции в принимающей системе. Конкретный способ зависит от доступного интерфейса и возможностей конфигурации 1С.
Одинаковые письма могут относиться к разным заказам. Покупатель может регулярно заказывать один и тот же товар в том же количестве. Если программа сравнит только вложения, она потеряет законный повторный заказ. В спорной ситуации показывают найденное совпадение и задают вопрос о намерении клиента. Решение связывают с конкретным событием, а не навсегда запрещают одинаковые заказы.
Проверку дублей проводят до создания документа и после восстановления незавершенной операции. Иначе система правильно отсеет повторные письма, но создаст два документа при повторе собственного вызова. В журнале нужно видеть обе связи: какое сообщение изменило заказ и какая операция записала эту редакцию в учетную систему.
Проверьте и одновременную обработку. Два обработчика могут оба увидеть, что документ еще не создан, и начать запись. Право выполнить одну операцию должно закрепляться за одним исполнителем средствами интеграции. Последовательный тест с повторным письмом такой дефект не обнаружит; в приемке нужен одновременный запуск для того же события и той же редакции заказа.
Тайм-аут не сообщает, сохранился ли заказ
Интеграция отправила запрос, но не получила ответ вовремя. Возможны два исхода: 1С не обработала запрос или сохранила документ, а ответ потерялся. Немедленно повторить создание — значит допустить дубль. Просто отметить ошибку и забыть операцию — значит оставить созданный документ без связи с карточкой обработки.
У операции нужен статус с неопределенным исходом. В этом состоянии система сначала проверяет, появился ли документ с соответствующим идентификатором. Если исход подтвержден, сохраняет связь и продолжает с нужного шага. Если проверить результат нельзя, направляет операцию ответственному. Пользователь не должен видеть сообщение об успешной записи, пока успех не подтвержден учетной системой.
После технического восстановления нельзя повторять всю цепочку целиком. Документ мог уже сохраниться, а уведомление менеджеру — не отправиться. Повторить нужно незавершенный шаг. История выполнения должна храниться отдельно от диалога с моделью, иначе сокращение контекста разговора или перезапуск сервиса уничтожит сведения о том, что уже произошло.
За время ожидания покупатель мог изменить или отменить заказ. Перед продолжением программа проверяет, остается ли отложенная операция актуальной для текущей редакции. Успешное восстановление связи не дает разрешения записать устаревшие условия. Так техническая очередь сохраняет связь с деловым состоянием заказа, а не исполняет все накопившиеся команды независимо от новых сообщений.
Для ошибок, исход которых известен, задают разные маршруты. Недоступность сервиса допускает отложенный повтор. Неверный код товара требует исправления данных. Отсутствие права на запись требует действий администратора. Универсальное повторение любого неудачного запроса только увеличивает очередь и скрывает проблему, которую программа сама устранить не может.
Если выполнить все шаги как одну операцию невозможно, заранее определяют порядок восстановления. Например, черновик создан, но вложение не прикрепилось: статус должен показывать неполный комплект и препятствовать дальнейшей обработке, если файл обязателен. Программа не обещает автоматическую отмену там, где учетная система ее не поддерживает; вместо этого нужен понятный маршрут исправления.
Агенту доступны только определенные действия с заказом
Список инструментов делают предметным: найти контрагента, получить состояние заказа, подготовить черновик, сохранить подтвержденную редакцию. Общий доступ к произвольным запросам или всему экрану учетной системы усложняет контроль. Чем точнее описана операция, тем проще проверить входные данные и объяснить, что именно агент способен изменить.
В проекте отчетов по вопросам на русском модель готовит запрос к базе, а выполнение проходит проверки и ограничено чтением. Для заказов нужны дополнительные правила, поскольку запись меняет рабочий процесс. Сам факт успешного чтения корпоративной базы не дает основания открыть те же широкие права для создания и изменения документов.
Письмо клиента содержит данные, а не полномочия. Просьба «сразу оформите с максимальной скидкой» не должна менять правила согласования цены. Указание внутри вложения не может разрешить выгрузку чужих заказов. Права и ограничения проверяются программно при каждом действии, даже если модель предложила его выполнить и уверенно объяснила причину.
Сохранение документа и отправка внешнего ответа тоже разделяются. В письме покупателю не должно появиться обещание поставки, которое никто не подтвердил. Для каждого статуса определяют допустимый смысл ответа: запрос получен, требуется уточнение, черновик подготовлен или условия согласованы. Текст формируется по фактическому состоянию, а не по желаемому результату обработки.
Менеджер должен получать вопрос вместе с заказом
Очередь исключений нужна как рабочее место, а не как журнал ошибок для разработчика. В карточке видны покупатель, текущая редакция, конкретная причина остановки, исходный фрагмент и уже выполненные действия. Специалист должен понимать, что произойдет после его решения: обновится черновик, продолжится запись или уйдет запрос уточнения.
Не требуйте повторно проверять весь заказ из-за одного неизвестного поля. Если все позиции подтверждены, а вопрос только в адресе доставки, интерфейс выделяет адрес и связанные условия. При этом изменение критичного поля может затронуть другие проверки. Такие зависимости описывают заранее, чтобы локальная правка не оставила прежнее согласование там, где оно уже потеряло смысл.
У незавершенного заказа должен быть владелец и срок следующего действия по правилам компании. После передачи менеджеру агент не продолжает менять карточку без учета этого состояния. Новые сообщения добавляются в историю и показываются ответственному. Иначе человек и программа начнут по очереди перезаписывать данные, каждый раз считая свою редакцию последней.
Исправления менеджеров сохраняют по причинам: неверно разобран текст, отсутствует справочник, не учтено правило, поступило новое пожелание клиента. Это разные задачи для доработки. Общая доля ручных вмешательств полезна для оценки нагрузки, но не объясняет, что именно улучшать — модель, интеграцию или сам порядок согласования.
Пилот проходит через правки, повторы и отказы
Для проверки соберите завершенные цепочки переписки, а не отдельные красивые письма. В набор должны попасть новые заказы, уточнения, пересылки, одинаковые повторные покупки, отмены и изменения уже созданного документа. Для каждой цепочки заранее определите ожидаемые редакции и допустимые действия. Итог оценивают по состоянию заказа и учетной системы, а не только по извлеченным полям.
- Отправьте одно событие повторно: новый документ появиться не должен.
- Имитируйте потерю ответа после записи: система должна установить исход операции.
- Измените заказ во время подтверждения: устаревшая редакция не должна уйти в учет.
- Пришлите отмену после начала исполнения: нужен маршрут, соответствующий реальному статусу.
- Перезапустите обработку посередине: выполненные шаги должны сохраниться в истории.
Измеряйте время от получения запроса до проверенного результата, число ручных исправлений, дубли документов и заказы, оставшиеся без ответственного. Отдельно учитывайте долю потока, которую система вообще берет в работу. Успех на простых письмах мало полезен, если основная часть нагрузки приходится на переписку с изменениями, а ее целиком оставили менеджерам.
Сравнение с ручной работой проводят на сопоставимых заказах. Включают проверку машинного результата, общение с клиентом и устранение ошибок записи. При расчете эффекта учитывают расходы после запуска: обработку файлов, вызовы модели, сопровождение интеграции и разбор исключений. Время на генерацию ответа само по себе не определяет стоимость обработанного заказа.
Начать можно с одного почтового потока и создания черновика в одной учетной базе. От компании нужны руководитель обработки заказов, менеджер с реальной перепиской и специалист по 1С. Вместе они определяют, какие события различать и какие записи разрешены. Затем расширяют охват: дополнительные покупатели, форматы вложений и операции, для которых уже проверен порядок восстановления.
Для диагностики агента обработки заказов подготовьте обезличенную цепочку с правками и соответствующие ей документы в учете. На разборе мы составим схему состояний и перечень операций, которые потребуют интеграции. Это позволит оценить прототип и назвать данные, доступы и решения со стороны компании, без которых автоматическое создание заказов пока не стоит запускать.