Конец августа 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 августа.
По моему опыту, у движков автоматизации вход собран из тех же служебных полей записи о событии. Движок 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 года).
Файл прямо из сканера и тот же счёт после мессенджера, пересохранения и пересылки – вход разного качества; так это оцениваю я. Значит, путь документа до модели становится частью системы: как принимать файл от контрагента, куда его складывать, что делать с фотографией счёта, снятой в машине на телефон.
Что я закладываю в конвейер до первой ошибки
Проверку я ставлю штатным шагом: сомнительные случаи уходят человеку, молча они не проходят. Порог и правило отбора решаю под конкретный поток, универсального числа не назову.
Второе, чего я хочу от такого конвейера, – журнал: видно, какой документ когда обработан и куда записан. Без журнала ошибку не разобрать: документ прошёл, поля записались, а откуда в карточке взялась чужая сумма, узнать негде.
И начинать я советую с одного типа документов: новый класс ошибок лучше смотреть на узком потоке, где вы знаете каждый документ в лицо.
А если схема у потока уже есть
Тогда всё, что выше, лишнее. До всякой модели я предлагаю поискать у потока готовую схему. Там, где для нужного действия есть типизированное событие или метод API, поля отдаются по контракту. Распознавание документа в таком месте – самый дорогой способ получить то, что и так приходит. К нему прилагаются рекомендации вендора по качеству входа, ошибки модели и работа человека на проверке.
Работающего потока за этими рассуждениями я показать не могу: на 4 сентября 2026 года внедрений таких конвейеров у клиентов нет, проекты на согласовании.
Четыре адреса можно не брать на веру, у каждого в тексте стоит своя дата: страница Vision у Anthropic, структура ответа в справочнике Яндекс 360 API, адрес отсутствующей страницы про подписку в документации Яндекс 360 API и страница документации n8n. Ссылок на остальное у меня нет: это собственная логика, проверить её можно только на живом потоке.
Автор: zhogov1985
