Документ после распознавания — это уже не просто PDF, фото или скан. Это набор данных: кто поставщик, какой номер и дата, какая сумма, есть ли НДС, какие строки внутри, какой исходный файл приложен и проверил ли это человек.
И вот эти данные могут быть нужны не только в 1С.
Логистике они нужны в TMS рядом с рейсом или заказом. Закупкам — в ERP рядом с заявкой. Ресторану — в системе учета продуктов. Производству — рядом с партией или поставкой сырья. Интернет-магазину — в складской системе рядом с поставкой.
Поэтому полезнее смотреть не на вопрос “как загрузить документ в 1С”, а шире: куда должны попасть данные после распознавания и проверки.
Что именно можно передавать через API
API нужен не для того, чтобы “перекинуть файл”. Файл тоже важен, но главная ценность — структурированные данные, которые другая система может использовать без ручного ввода.
Обычно после распознавания системе-получателю могут быть нужны:
| Блок данных | Что входит |
|---|---|
| Данные документа | тип, номер, дата, валюта, статус обработки |
| Контрагент | название, УНП или другой идентификатор, реквизиты |
| Суммы | сумма без НДС, НДС, итоговая сумма |
| Строки | наименование, количество, единица измерения, цена, сумма |
| Файл | ссылка на исходный документ или обработанный PDF |
| Проверка | кто проверил, когда проверил, какие поля исправлялись |
| Связь с процессом | номер заказа, рейса, заявки, поставки, партии или другой внешний ID |
В 1С эти данные становятся учетным документом. В TMS они могут лечь к перевозке. В ERP — к закупке. В ресторанной системе — к приходу продуктов. В складской системе — к поставке.
То есть API решает практический вопрос: не заставлять сотрудника второй раз читать тот же документ и переносить данные в другую систему руками.
Как выглядит рабочая схема
Самая простая схема обмена выглядит так:
- Документ попадает в 4invoice: файл, фото, скан или e-mail.
- 4invoice распознает счет, акт, транспортную накладную, ТТН или накладную.
- Ответственный сотрудник проверяет данные и исправляет спорные поля.
- После проверки внешняя система забирает результат через API или получает его по согласованному обмену.
- Внешняя система создает или обновляет свой объект: заказ, рейс, заявку, поставку, карточку закупки.
Ключевой момент — передавать дальше лучше не “сырой результат”, а данные после проверки. Особенно если документ влияет на оплату, склад, перевозку или себестоимость.
Почему не стоит передавать все сразу автоматически
В распознавании документов всегда есть нюансы. Фото может быть размытым. Поставщик может прислать нестандартную форму. В накладной может быть много строк. Контрагент может называться не так, как в вашей системе. В документе может не быть номера заказа или рейса.
Поэтому в API-сценарии полезно разделять статусы:
получен— документ загружен, но еще не разобран;распознан— данные извлечены, но не проверены;требует проверки— есть неуверенные поля или расхождения;проверен— человек подтвердил данные;передан— данные ушли во внешнюю систему;ошибка передачи— принимающая система не приняла документ.
Даже если названия статусов будут другими, логика важна. Внешняя система должна понимать, что она получает: черновик, проверенный документ или документ с ошибкой.
Что должна уметь принимающая система
Чтобы ERP, TMS, складская или ресторанная система могла использовать данные из распознанного документа, ей нужно уметь принять их.
На практике это означает несколько вещей.
Принять структуру данных
Система должна понимать поля: номер документа, дату, контрагента, сумму, НДС, строки, файл, статус. Если в ней нет нужных полей, нужно решить, куда эти данные будут записываться.
Найти связанный объект
Часто документ нужно не просто загрузить, а прикрепить к чему-то:
- к рейсу;
- к заказу;
- к заявке на закупку;
- к поставке;
- к партии;
- к карточке контрагента;
- к внутреннему проекту.
Связь можно искать по номеру заказа, номеру рейса, контрагенту, дате, сумме, внутреннему ID или другому правилу. Если правило ненадежное, лучше оставлять ручное подтверждение.
Вернуть ошибку, если что-то не принято
API-интеграция должна уметь не только принять успешный документ, но и честно вернуть ошибку: не найден заказ, не совпала сумма, неизвестный контрагент, нет обязательного поля, документ уже существует.
Без этого данные могут “теряться”: в одной системе документ проверен, а в другой так и не появился.
Пример: логистика и TMS
Перевозчик прислал счет, акт или транспортную накладную. В бухгалтерии нужно проверить сумму и реквизиты. В логистике этот же документ должен оказаться рядом с рейсом или заказом.
Через API можно передать в TMS:
- тип документа;
- номер и дату;
- перевозчика;
- сумму;
- валюту;
- ссылку на файл;
- номер рейса или заказа, если он найден;
- статус проверки.
Если номер рейса найден уверенно, TMS может прикрепить документ автоматически. Если вариантов несколько, система может показать их диспетчеру или бухгалтеру на выбор.
Польза здесь не в красивой интеграции ради интеграции. Польза в том, что сотрудник не ищет файл в почте, не переименовывает его вручную и не прикрепляет к рейсу второй раз.
Пример: ресторан, закупки и склад
Поставщик привез продукты и прислал накладную. Для бухгалтерии это первичный документ. Для ресторана это еще и данные о закупке: что купили, в каком количестве, по какой цене.
Через API или другой обмен можно передать:
- поставщика;
- дату поставки;
- строки накладной;
- количество;
- единицы измерения;
- цену;
- итоговую сумму;
- файл документа.
Дальше ресторанная или складская система может использовать эти данные для прихода товаров, сверки закупки или дальнейшей работы с себестоимостью.
Здесь особенно важно не обещать магию. Наименования продуктов у поставщика и в ресторанной системе могут отличаться. Поэтому сопоставление номенклатуры может требовать настройки или ручной проверки.
Пример: ERP и закупки
В ERP счет часто должен быть связан с заявкой, заказом поставщику, договором или бюджетом.
Если счет распознан, через API можно передать:
- поставщика;
- сумму;
- НДС;
- номер и дату счета;
- строки;
- ссылку на файл;
- предполагаемый номер заказа или заявки;
- статус “проверен” или “требует проверки”.
ERP может использовать эти данные для согласования, контроля лимитов, подготовки оплаты или сверки с заказом.
Если заказ не найден, документ не должен исчезать. Его нужно вернуть в очередь проверки с понятной причиной: “не найден заказ”, “несколько похожих заказов”, “сумма не совпадает”.
Что подготовить перед API-интеграцией
Чтобы интеграция была полезной, перед разработкой стоит ответить на конкретные вопросы.
1. Какие документы передаем
Не нужно начинать со всех документов сразу. Лучше выбрать поток, где больше всего ручной работы:
- счета перевозчиков;
- акты подрядчиков;
- транспортные накладные;
- накладные поставщиков;
- документы от иностранных поставщиков;
- регулярные закупки.
2. Какие поля обязательны
Для одной системы достаточно шапки документа. Для другой нужны строки. Для третьей нужен внешний ID заказа или рейса.
Полезно заранее разделить поля:
- обязательные;
- желательные;
- справочные;
- те, которые человек должен подтвердить.
3. В какой момент отдавать данные
Есть два варианта:
- отдавать сразу после распознавания, если внешней системе нужен черновик;
- отдавать только после проверки человеком, если данные влияют на учет, оплату, склад или операционный процесс.
Для большинства финансовых документов безопаснее начинать со второго варианта.
4. Как обрабатывать ошибки
Интеграция должна заранее отвечать на вопросы:
- что делать, если внешний заказ не найден;
- что делать, если документ уже есть;
- что делать, если обязательное поле пустое;
- кто видит ошибку;
- где документ повторно отправляется после исправления.
Если этот блок не продумать, API просто перенесет хаос из почты в технический обмен.
Где здесь место 4invoice
4invoice может закрывать первый важный участок: прием и распознавание первичных финансовых документов.
Документ можно загрузить файлом, фотографией или переслать по e-mail. Система извлекает данные из счетов, актов, транспортных накладных, ТТН и накладных, помогает проверить реквизиты, суммы и НДС.
Дальше возможны разные сценарии. Для многих компаний это передача проверенных данных в 1С. Для других — интеграция с ERP, TMS, складской, ресторанной или внутренней системой, если принимающая сторона готова забрать структурированные данные.
Важно честно: это не означает готовую коробочную интеграцию со всеми системами на рынке. У каждой системы свои поля, правила и ограничения. Но API-подход позволяет использовать распознанный документ не только в бухгалтерии, а в том процессе, где он реально нужен.
Когда API действительно нужен
API не нужен всем. Если документов мало, иногда достаточно загрузки в 1С или ручной проверки.
API стоит обсуждать, когда:
- документов много;
- одна и та же информация вводится в несколько систем;
- документы нужно прикреплять к заказам, рейсам или поставкам;
- есть внутренняя система, которая уже управляет процессом;
- команда готова описать поля, статусы и ошибки;
- есть разработчик или интегратор, который может настроить обмен.
Если этих условий нет, лучше сначала наладить базовый процесс: прием документов, распознавание, проверка, передача в основную учетную систему.
Что читать дальше
- Как ИИ помогает бухгалтеру с первичными документами — если нужно сначала понять базовый сценарий распознавания и проверки.
- Как загрузить документы в 1С из PDF, фото, Excel, Word и бумаги — если 1С остается главным направлением передачи.
- ИИ для бухгалтерии: где он реально помогает, а где нужен человек — если хочется посмотреть шире на ИИ в бухгалтерской работе.
Короткий вывод
Распознавание документа — это только первая часть задачи. Практическая ценность появляется, когда проверенные данные можно использовать дальше: в 1С, ERP, TMS, закупках, складе, ресторанном учете или внутренней системе.
API помогает связать эти части процесса. 4invoice распознает документ и готовит структурированные данные, а принимающая система использует их там, где бизнесу это нужно: у рейса, заказа, поставки, заявки или карточки закупки.
Так документ перестает быть файлом, который пересылают вручную. Он становится проверенным набором данных, который может двигаться между системами.