Автоввод первички в 1С: OCR, проверка дублей и готовый документ

Проблема ручного ввода первички

Каждый входящий документ — счёт, накладная, акт, счёт-фактура — приходит в удобном для отправителя виде: сканом, фотографией с телефона, PDF во вложении или прямо в теле письма. А в учёте он должен превратиться в структурированную запись: контрагент из справочника, номер, дата, суммы, ставка и сумма НДС, строки номенклатуры. Между этими двумя точками стоит человек, который вручную перепечатывает цифры.

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

• опечатки в суммах и номерах — особенно на длинных числах и в конце рабочего дня;
• дубли: один и тот же счёт заносят дважды, потому что он пришёл и на почту, и в мессенджер;
• новый контрагент заводится с нуля вместо выбора существующего — справочник разрастается двойниками;
• номенклатура подбирается на глаз, из-за чего страдают остатки и себестоимость;
• оригинал документа теряется или лежит отдельно от проводки, и при проверке его не найти.

Чем больше поток документов, тем дороже обходится каждая из этих мелочей. Бухгалтер тратит время не на контроль и аналитику, а на механическое перепечатывание того, что уже есть в электронном виде. Логичный следующий шаг — снять с человека ввод и оставить ему проверку.

Как выглядит сквозной автоввод: этапы

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

1. Приём документа. Источником может быть скан, фото, PDF или письмо. Документ попадает в пайплайн из почтового ящика, папки, мессенджера или загрузки.
2. Извлечение реквизитов. OCR и LLM вытаскивают контрагента, номер, дату, суммы, НДС и номенклатуру в структурированный вид.
3. Сопоставление с базой. Контрагент и позиции номенклатуры сверяются со справочниками 1С, а не заводятся вслепую.
4. Проверка дублей. Система смотрит, нет ли уже такого документа, прежде чем создавать новый.
5. Создание документа в 1С. Объект создаётся через API, к нему прикладывается оригинал.
6. Проверка бухгалтером. Человек смотрит на подготовленный документ и принимает решение о проведении.

Ключевой принцип: автоматизация доводит документ до состояния «почти готов», но финальное проведение всегда остаётся за человеком. Оригинал при этом прикладывается к записи, поэтому при любой проверке видно, откуда взялись цифры.

Извлечение данных: OCR и LLM

Извлечение реквизитов держится на двух технологиях, и они решают разные задачи. OCR (оптическое распознавание) переводит изображение в текст: из скана или фотографии получается набор символов. Но текст сам по себе ещё не данные — в нём нужно понять, где номер счёта, где дата, а где итоговая сумма с НДС.

Здесь подключается LLM. Языковая модель разбирает распознанный текст по смыслу и раскладывает его в структуру: контрагент, номер, дата, суммы, ставка и сумма НДС, строки номенклатуры. Это работает даже тогда, когда документы приходят в разных формах — у каждого поставщика свой шаблон счёта, свои названия полей и свой порядок строк. Ocr первички в 1с без смыслового слоя быстро упирается в это разнообразие форматов.

Такая связка особенно важна для распознавание счетов 1с в живом потоке, где рядом лежат аккуратный PDF из учётной системы поставщика и мятая фотография накладной с телефона. OCR вытягивает символы, LLM понимает их роль. На выходе — структурированный набор данных, готовый к следующему шагу: сопоставлению со справочниками.

Про выбор между готовым распознаванием и собственной связкой OCR и LLM мы подробно писали в материале распознавание документов в 1С: готовое решение против кастомного.

Сопоставление контрагентов и номенклатуры, проверка дублей

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

Сопоставление контрагентов

Извлечённый контрагент сверяется со справочником. Задача — найти существующую запись, а не завести новую копию. Совпадение ищут по реквизитам, чтобы «ООО Ромашка» из счёта уверенно легло на уже заведённого контрагента, а не породило двойника. Если однозначного совпадения нет, документ уходит человеку на решение.

Сопоставление номенклатуры

Строки из документа сопоставляются с позициями номенклатуры в базе. Это самый чувствительный к правилам этап: у одного и того же товара в счёте поставщика и в вашей базе названия могут различаться. Здесь и проявляется автозаполнение документов 1с — система подставляет позиции по вашим правилам сопоставления, а спорные строки отправляет на проверку.

Проверка дублей

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

Общее правило для всех трёх шагов: спорные случаи не проводятся автоматически. Человек остаётся в контуре и решает там, где у системы нет уверенности.

Занесение в 1С через API (OData или HTTP-сервис)

Когда данные извлечены, сопоставлены и проверены на дубли, документ нужно физически создать в 1С. Для этого есть два штатных пути.

OData

OData — стандартный REST-интерфейс 1С. Через него внешняя система обращается к объектам базы по HTTP. Создание документа — это POST-запрос с подготовленными данными: система передаёт контрагента, суммы, строки номенклатуры, и в базе появляется новый объект. OData хорош тем, что это готовый интерфейс, который не требует писать серверный код на стороне 1С.

HTTP-сервис

Второй путь — собственный HTTP-сервис внутри 1С. Здесь логику приёма и обработки данных описывают на стороне конфигурации. Это гибче: можно заложить свои проверки, форматирование и бизнес-правила прямо в сервис. Цена гибкости — этот сервис нужно разработать и поддерживать.

Создание и проведение — разные шаги

Важный момент: создание объекта и его проведение — это не одно и то же. Через POST документ создаётся, но остаётся непроведённым. Проведение выполняется отдельным шагом или отдельной логикой — и именно здесь в поток встроена проверка бухгалтером. Документ ждёт человека в статусе черновика, к нему приложен оригинал, и только после подтверждения он проводится. Так автоматизация доводит работу до последнего шага, но не берёт на себя ответственность за проводку.

Один из удобных каналов приёма документов — Telegram: сотрудник пересылает фото счёта боту, и оно уходит в тот же пайплайн. Подробности в статье про Telegram-бота для загрузки документов в 1С.

Родное 1С:РПД vs кастомный поток

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

1С:РПД — родное распознавание

1С:РПД — это облачный сервис самой 1С. Он распознаёт типовые документы: счета, ТОРГ-12, акты, счета-фактуры, УПД, чеки. Умеет автоматически сопоставлять контрагентов и номенклатуру, заявленная точность — до 98%. Оплата идёт по страницам, ориентировочно 20–35 ₸ за страницу. Сильная сторона — это работает из коробки внутри 1С и отлично подходит для типовых документов.

Кастомный поток на n8n или Make

Кастомная связка (n8n или Make плюс OCR и LLM) выигрывает там, где родному сервису тесно:

• Источники. Документы можно принимать из мессенджеров и почты, а не только загружать в 1С.
• Свои правила. Логику сопоставления и проверки дублей вы задаёте под себя.
• Экономика на объёме. Нет пер-страничной платы, что заметно на больших потоках.
• Единый пайплайн. Один поток может обслуживать несколько систем, а не только 1С.

Компромисс честный: кастомный поток нужно настроить и поддерживать. Это не сервис по подписке, а решение, которое живёт и развивается вместе с вашими процессами.

Как выбрать

Если документы типовые, приходят внутри 1С и объём умеренный — родное 1С:РПД закроет задачу быстро и без разработки. Если источники разнородные (мессенджеры, почта), нужны свои правила или объём делает пер-страничную оплату дорогой — кастомный поток даёт гибкость и предсказуемую экономику. Нередко разумен и гибридный вариант: типовое отдать 1С:РПД, а нестандартные каналы вести через кастомный пайплайн.