В событии про письмо нет ни суммы, ни контрагента. Чем платят за то, чтобы эти поля появились

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

Двадцать два поля. Столько их в структуре ответа AuditLogService_Mail у почтового аудит-лога Яндекс 360 (https://yandex.ru/dev/api360/doc/ru/ref/AuditLogService/AuditLogService_Mail, сверено 10 сентября 2026 года). Я искал в этом списке сумму, контрагента и номер договора. Не нашёл ни одного.

Просьбу и этот список свёл вместе я сам: про состав полей события директор по ИТ ничего не говорил.

Я Александр Жогов, основатель ИТ-компании “+Альянс”. Дальше – про шаг, который создаёт недостающие поля, и про его цену.

Что в этих полях всё-таки есть

Содержательными в этих 22 полях я считаю пять: subject, то есть тему письма, и адреса участников from, to, cc, bcc. Остальные семнадцать служебные, их полный перечень я вынес на схему. В справочнике Яндекс 360 API у метода AuditLogService_Mail требуемое право указано так: ya360_security:audit_log_mail (сверено 20 августа 2026 года).

У части служебных полей справочник Яндекс 360 API приводит и значения — их состав я пересверял 10 сентября 2026 года. Источник события source принимает server, imap, pop3 или native. Дата и время события date идут по UTC, формат ISO 8601. У типа папки folderType двенадцать значений, среди них inbox, sent, spam и trash. Метки labels показаны примерами: seen, attached, undo, delayed. Отдельные поля отведены под идентификаторы — uniqId у события, mid у письма, msgId под заголовок Message-ID, requestId у запроса. requestId идёт с оговоркой справочника Яндекс 360 API: значение может быть неуникальным.

Сумма, контрагент, номер договора. Ничего этого среди 22 полей нет. Содержимого тоже: ни текста письма, ни сведений о вложениях структура ответа не описывает (справочник Яндекс 360 API, сверено 10 сентября 2026 года).

Само событие о получении письма в справочнике Яндекс 360 API есть — message_receive, одно из двенадцати значений eventType. Запись о нём сообщает адреса сторон и строку темы, а дела по существу не касается.

Слева – 22 поля структуры ответа AuditLogService_Mail: пять о теме и участниках, остальные семнадцать. Справа – то, чего в структуре ответа нет. Справочник Яндекс 360 API, сверено 10.09.2026.

Подписки на событие о письме документация Яндекс 360 API не предлагает

Страницы concepts/webhooks в документации Яндекс 360 API нет, прямой адрес https://yandex.ru/dev/api360/doc/ru/concepts/webhooks отдаёт 404. Я проверял его 10 сентября 2026 года, в четвёртый раз с 20 августа.

По моему опыту ^[1], у движков автоматизации вход собран из тех же служебных полей записи о событии. Движок n8n я беру потому, что документация у него открытая. Когда готовая нода не покрывает нужную операцию, документация n8n предлагает обойти это универсальным HTTP-запросом: “You can work around this by making a custom API call using the HTTP Request node” (https://docs.n8n.io/integrations/, сверено 6 сентября 2026 года). Дальше идёт вызов API. Состав полей в таком вызове, как я понимаю, задаёт тот, кто пишет запрос.

Откуда берутся сумма и контрагент?

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

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

Ошибки распознавания перечислил сам производитель модели

Ограничения своей модели Anthropic перечисляет в разделе Limitations страницы Vision. На картинке низкого качества, повёрнутой или совсем мелкой, меньше 200 пикселей, модель может ошибиться или что-то выдумать: “Claude might hallucinate or make mistakes when interpreting low-quality, rotated, or very small images under 200 pixels” (https://platform.claude.com/docs/en/build-with-claude/vision, куда 6 сентября 2026 года вёл редирект с docs.claude.com). В том же разделе Limitations Anthropic оговаривает, что число объектов на картинке модель может назвать приблизительно и “might not always be precisely accurate, especially with large numbers of small objects”.

Сразу после списка ограничений на странице Vision идёт отдельный абзац: “Always carefully review and verify Claude’s image interpretations, especially for high-stakes use cases. Do not use Claude for tasks requiring perfect precision or sensitive image analysis without human oversight”. Производитель модели просит просматривать и проверять её интерпретации, а в задачах, где нужна безупречная точность, не работать без человеческого контроля.

Счёт на оплату и табличную часть накладной я отношу к таким задачам – это моя оценка. Anthropic в процитированном пункте Limitations говорит про число объектов; ни счетов на оплату, ни строк таблицы в этом пункте нет.

Скан до модели ещё доехать должен

Что подавать на вход, документация Anthropic разбирает на той же странице Vision, в разделе Image quality guidance. Изображение там просят держать чётким (“Ensure images are clear and not too blurry or pixelated”), а важный текст на картинке – читаемым и не слишком мелким (“If the image contains important text, make sure it’s legible and not too small”). Есть пункт и про сжатие, с оговоркой про несколько проходов подряд: “… this can introduce artifacts that are detrimental to model performance, especially when multiple compression passes are applied. For example, heavy JPEG compression can make text difficult to read” (https://platform.claude.com/docs/en/build-with-claude/vision, сверено 6 сентября 2026 года).

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

Что я закладываю в конвейер до первой ошибки

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

Второе, чего я хочу от такого конвейера, – журнал: видно, какой документ когда обработан и куда записан. Без журнала ошибку ^[2] не разобрать: документ прошёл, поля записались, а откуда в карточке взялась чужая сумма, узнать негде.

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

А если схема у потока уже есть

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

Работающего потока за этими рассуждениями я показать не могу: на 4 сентября 2026 года внедрений таких конвейеров у клиентов нет, проекты на согласовании.

Четыре адреса можно не брать на веру, у каждого в тексте стоит своя дата: страница Vision у Anthropic, структура ответа в справочнике Яндекс 360 API, адрес отсутствующей страницы про подписку в документации Яндекс 360 API и страница документации n8n. Ссылок на остальное у меня нет: это собственная логика ^[3], проверить её можно только на живом потоке.