Загрузка заказов из почты в 1С: где нейросеть ошибается и как это поймать

Клиент пишет: “Добрый день, как в прошлый раз, только кабеля побольше, 3 бухты, и хомуты 200”. Менеджер знает, что “как в прошлый раз” это позавчерашний заказ, что кабель у этого клиента всегда одной марки, а хомуты идут пачками по 100. Нейросеть ничего из этого не знает. Она прочитает текст, вернёт аккуратный список из двух строк и не пометит ни одну из них как сомнительную.

В этом главный риск автоматической загрузки заказов из почты в 1С. Модель редко ломается громко. Гораздо чаще она выдаёт правдоподобный результат, который выглядит как нормальный заказ. Поэтому ниже маршрут разобран по классам ошибок: как каждая проявится в документе и какая проверка её ловит.

Как выглядит маршрут

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

Модель в этой схеме только читает текст. Искать номенклатуру, пересчитывать единицы и создавать документ должен код 1С, потому что его поведение можно проверить и повторить, а поведение модели на новом письме заранее не известно.

Позиция не найдена

Самый безобидный класс. Клиент написал товар, которого нет в справочнике, или назвал его так, что ни артикул, ни наименование не совпали. В черновике это строка с пустой номенклатурой и исходным текстом клиента рядом.

Ловится тривиально: пустая ссылка на номенклатуру. Правило одно: такая строка не выбрасывается и не заменяется. Если из заказа на пять позиций тихо пропала одна, клиент узнает об этом при отгрузке.

Найдена не та позиция

Самый опасный класс, и механизм у него тот же, что с выдуманными реквизитами конфигурации. Модель не умеет честно сказать “не знаю”. Если попросить её выбрать товар из списка, она выберет самый похожий, даже когда правильного в списке нет. “Кабель ВВГ 3х2,5” станет “ВВГ 3х1,5”, потому что строки отличаются одним символом.

В документе такая ошибка не видна вообще: номенклатура заполнена, цена подтянулась, сумма посчиталась. Отличить её можно только сравнением с письмом.

Отсюда правило, которое мы бы ставили первым: модель не выбирает номенклатуру, она возвращает текст клиента, а сопоставление делает код по точным ключам. Артикул, штрихкод, код товара у этого клиента. Если по ключу нашлась ровно одна позиция, строка заполняется. Если ноль или несколько, строка уходит менеджеру с кандидатами на выбор.

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

// Иллюстрация: позиция из письма сопоставляется только точным совпадением.
// Ноль или несколько кандидатов - строка уходит менеджеру, а не "самому похожему".
Функция НайтиПозициюПоАртикулу(Артикул)

    Запрос = Новый Запрос;
    Запрос.Текст =
    "ВЫБРАТЬ ПЕРВЫЕ 2
    |    Номенклатура.Ссылка КАК Ссылка
    |ИЗ
    |    Справочник.Номенклатура КАК Номенклатура
    |ГДЕ
    |    Номенклатура.Артикул = &Артикул
    |    И НЕ Номенклатура.ПометкаУдаления";
    Запрос.УстановитьПараметр("Артикул", СокрЛП(Артикул));

    Выгрузка = Запрос.Выполнить().Выгрузить();
    Если Выгрузка.Количество() = 1 Тогда
        Возврат Выгрузка[0].Ссылка;
    КонецЕсли;

    Возврат Неопределено;

КонецФункции

ПЕРВЫЕ 2 здесь не для скорости: второй строки достаточно, чтобы понять, что совпадение не единственное. Когда артикула в письме нет и клиент пишет словами, нечёткий поиск допустим, но его результат идёт в черновик пометкой “проверить”, без права подставиться молча.

Количество и единица

“3 бухты” кабеля, “200” хомутов при упаковке по 100, “2 палеты”. Модель охотно пересчитывает сама: бухта станет сотней метров, потому что так бывает чаще всего. У вашего поставщика бухта может быть другой длины.

В документе ошибка выглядит как нормальное число в колонке количества. Проверка: модель возвращает количество и единицу ровно так, как написал клиент, отдельными полями. Пересчёт в единицу хранения делает 1С по своим упаковкам и коэффициентам. Если единица из письма не нашлась среди упаковок товара, строка идёт менеджеру. Туда же отдельные мелочи: “1,5” и “1.5”, “1 000” с пробелом, “полторы”, “десяток”.

Повторное письмо

Дублей два вида, и ловятся они по-разному.

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

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

Команда внутри письма

Письмо это входящий документ от внешнего человека. В нём может оказаться текст, который читается как указание: “цену ставьте как в прошлом месяце”, “предыдущий заказ отмените”, “скидка 30% согласована с руководителем”. Бывает и намеренная подстава, когда текст адресован именно модели.

Защита строится так, чтобы такой текст ничего не мог сделать:

• модель возвращает только поля заранее заданной структуры, в ней нет полей “цена”, “скидка” и “отменить заказ”;
• цены и скидки берутся из 1С по условиям клиента, а из письма никогда;
• пользователь, от имени которого работает загрузка, имеет право только создавать черновики заказов: проводить, менять чужие документы и отправлять ответы ему нечем;
• фразы с распоряжениями не исполняются, а выносятся в комментарий черновика для менеджера.

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

Вложение вместо текста

Часть клиентов шлёт заказ таблицей Excel или PDF, а в теле письма одно слово “заказ”. Это другой маршрут, и смешивать его с текстовым не стоит.

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

Почему сначала черновик

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

Название документа зависит от конфигурации: заказ клиента в УТ 11 и ERP, заказ покупателя в конфигурациях линейки УТ 10.3. Для маршрута это неважно, черновик создаётся одинаково: записан, не проведён, с исходным письмом и пометками по спорным строкам.

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

Как собрать контрольную выборку писем

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

• Письма берутся из настоящего ящика подряд за период. Подобранные “показательные” примеры проходят всегда.
• В выборке есть каждый класс из этой статьи: товар, которого нет в справочнике, похожие позиции, нестандартные единицы, повторное письмо, распоряжение в тексте, вложение. Если какого-то класса в ящике не нашлось, это тоже результат.
• Эталон заполняет менеджер руками: какой должен получиться заказ по каждому письму, позиция, количество, единица. Без эталона “распозналось хорошо” остаётся мнением.
• Считается по строкам и по полям. Письмо на двенадцать позиций с одной подменённой строкой по письмам выглядит “почти успехом”, хотя клиент получит не тот товар.
• Отдельно считается тихая ошибка: строка заполнена уверенно и неверно. Пустая строка, ушедшая менеджеру, стоит минуты его времени. Тихая подмена стоит отгрузки не того товара.

Письма содержат ФИО, телефоны, адреса доставки. Если на выборке проверяют внешнюю облачную модель, решение принимает владелец данных, а часть значений можно заменить маркерами до отправки. Как это делается с возвратом настоящих значений в ответ, разобрано в статье про обезличивание данных 1С для нейросети.

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