Распознавание первички: почему в 1С должны попадать черновики, а не проведённые документы

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

Почему распознанную первичку нельзя проводить автоматически

Когда владелец бизнеса говорит мне «хочу, чтобы сканы сами превращались в документы в 1С», я сразу уточняю одно слово: в какие именно документы. Если в черновики — это нормальная инженерная задача, и мы решаем её в рамках ИТ-аутсорсинга для бухгалтерии без драмы. Если в проведённые — я останавливаю разговор и объясняю, почему автоматизация без человека в конце цепочки для учёта не цель, а риск. Пятнадцать лет в проектах с 1С научили меня простому: экономить надо на вводе, а не на решении.

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

У этого подхода есть и юридическая логика, хотя я не юрист и формулировки вам стоит проверить в своей ситуации. Закон о бухгалтерском учёте (402-ФЗ) в статье 9 требует оформлять каждый факт хозяйственной жизни первичным документом, а в статье 10 — своевременно регистрировать данные первичных документов в регистрах учёта; исправления в регистре не допускаются без санкции лиц, ответственных за его ведение, и должны содержать дату и подпись. Отсюда мой практический вывод: за то, что попало в регистр, отвечает конкретный человек. Программа, которая распознала бумагу и сама провела документ, ответственности не несёт — её несёт тот, кто эту программу включил. Мне, как разработчику, такой расклад не нравится: я хочу, чтобы бухгалтер видел, что регистрирует.

Чем грозит автопроведение: закрытые периоды, НДС и вопрос «кто это провёл»

Начну с самого приземлённого. Ошибка чтения в черновике стоит одной минуты: бухгалтер увидел, поправил, нажал дальше. Та же ошибка в проведённом документе уже сидит в остатках, в себестоимости, в акте сверки с контрагентом. Найти её придётся позже и, как правило, в самый неудобный момент — на сверке или при закрытии месяца. Наши детерминированные проверки ловят многое: контрольные суммы ИНН, арифметику НДС, расхождение «количество × цена ≠ сумма». Но арифметически безупречная ерунда им недоступна: документ, у которого все цифры сходятся, а читаться он должен был иначе, проверки пропустят. Именно для таких случаев нужен человек.

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

Закрытые периоды — отдельная история. В 1С есть дата запрета изменения данных: в закрытом периоде программа не даёт ни изменять, ни проводить, ни удалять документы, и при попытке выдаёт сообщение об этом. Если запрета нет, автопроведение с датой из закрытого периода тихо поменяет цифры, по которым уже сдана отчётность. Если запрет есть, робот упрётся в него, а вам придётся снимать запрет ради исправления, и это плохая привычка. Черновик в такой ситуации просто ждёт, пока человек решит, что с ним делать. И последнее: при вопросах инспектора или аудитора ответ «документ провёл алгоритм» — худший из возможных.

Чтобы это не звучало абстрактно, вот модельный расчёт. Возьмём условный пример: бухгалтерская консультация «Финотчёт», 35 рабочих мест. Все цифры ниже — допущения, подставьте свои. Пусть в месяц приходит 700 входящих документов, а в 3 % из них ошибка чтения доходит до учёта — это 21 документ. Исправление проведённого документа в открытом периоде (найти, отменить проведение, поправить, перепровести, проверить зависимые документы) допустим, занимает 30 минут: получается около 10,5 часа в месяц. Замечание в карточке черновика разбирается за 3 минуты: около часа. Разница — порядка 9,5 часа, и это без закрытых периодов и НДС, которые в часах не измеряются. Как перевести такую арифметику в окупаемость, я разбираю отдельно, там можно посчитать окупаемость на своих цифрах.

Как устроено «система готовит — бухгалтер решает» в нашем модуле

Я не строю защиту на доверии к модели. Вместо этого в модуле несколько независимых замков, и каждый закрывает свой класс проблем. Первое: система пишет в 1С только непроведённые черновики. Второе: команда проведения из конвейера запрещена всегда — независимо от роли пользователя и от того, насколько система уверена в распознавании. Третье: запись происходит только после явного «Применить» оператора, и каждое решение подписывается его учётной записью. Четвёртое: по умолчанию работает dry-run. Пятое: запись разрешается при подтверждённой резервной копии и только в разрешённые поля. Шестое: для ввода и для анализа заведены разные роли.

Собрал всё в таблицу, чтобы было видно, от чего защищает каждый замок. | Замок | Что делает | От чего защищает | |---|---|---| | Только черновики | Создаются непроведённые документы | От движений по регистрам без решения человека | | Запрет проведения | Команда проведения из конвейера недоступна всегда | От «повышения доверия» по уверенности или роли | | «Применить» | Запись только после явного действия оператора, с его учётной записью | От анонимных изменений в базе | | Dry-run | Система показывает, что было бы создано | От неожиданностей в пилоте | | Резервная копия | Запись разрешается только при подтверждённой копии | От необратимых последствий ошибки | | Белый список полей и роли | Запись только в разрешённые поля, ввод и анализ разделены | От лишних прав и случайных правок |

Особенно я ценю dry-run. Пока запись не включена явно, система ничего не создаёт в вашей 1С, а показывает, что БЫЛО БЫ создано: карточки, замечания, сопоставление. Поэтому пилот на реальной пачке — это не эксперимент над вашей базой, а безопасная репетиция. Подробнее о том, что в этом режиме измерять, я написал в отдельной статье про пилот в режиме dry-run.

Почему запрет на проведение «всегда», а не «пока уверенность ниже порога»? Потому что уверенность распознавания — не то же самое, что правильность решения. Цифру со страницы продукта я привожу честно и с оговоркой: в сквозном тесте на смешанной пачке 67 из 67 типов документов определены верно, и ни один документ не проведён без человека. Первое число говорит про определение типа, а не про каждую сумму в каждой строке. Общее устройство OCR-конвейера, от подготовки скана до документа в учёте, я описывал в статье про OCR-распознавание первички для бухгалтерии, здесь я говорю только о границе ответственности.

Как выглядит работа бухгалтера: карточка, замечания, дубли и кнопка «Применить»

Пачка — до 500 файлов: PDF, сканы, фото, многостраничные PDF режутся сами. Каждый документ проходит десять стадий, и последняя называется «готов к решению»: карточка лежит и ждёт оператора. В карточке видно определённый тип (если система сомневается, она показывает второй вариант, например «возможно также: УПД»), реквизиты, строки, замечания проверок и результат сопоставления с 1С. Бухгалтер сверяет карточку со сканом и либо нажимает «Применить», либо оставляет документ в очереди. После «Применить» в базе появляется непроведённый черновик; в dry-run вместо этого показывается, что было бы создано.

Замечания — самая полезная часть карточки. Система пишет их по-человечески: «Строка 2: 1.0 × 5 839,48 ≠ 7 124,26 (расхождение 1 284,78)» или «Сумма строк 2 192,61 против итога 2 159,57: расхождение 33,04 ₽». Бухгалтер может не править поля вручную, а ответить комментарием: например, «причина неверна, в графе «Всего к оплате» написано 36 620,00». Система снимет замечание и подставит названное значение. Что именно и как мы проверяем по реквизитам, я разобрал в отдельной статье про проверки ИНН, КПП и НДС, а здесь важен принцип: замечание не блокирует человека, оно указывает, куда смотреть.

Отдельно о дублях. Система ищет их по связке «поставщик + номер + дата + сумма» и внутри пачки, и против уже заведённого в 1С. Для черновиков это особенно удобно: дубль-черновик удаляется одним действием, а вот проведённый дубль — это удвоенные расходы и потенциально удвоенный вычет. Мой порядок действий такой: если карточка помечена как дубль, я не нажимаю «Применить», а открываю уже существующий документ в 1С и сравниваю. Если это действительно новый документ (скажем, исправленный УПД), решение принимаю я, а не алгоритм.

После «Применить» работа не заканчивается, и это тоже сознательное решение. Бухгалтер открывает черновик в 1С, смотрит на дату документа в сравнении с датой запрета изменения данных, проверяет заполнение по правилам своей конфигурации и проводит документ сам, под своей учётной записью. Документы, которые по типу не заводятся автоматически (счёт на оплату, платёжное поручение, ТТН, кассовые документы, чеки), уходят в очередь оператора; неизвестный вид документа сохраняется как текст в ручной очереди. Сравните с ручным вводом: сначала человек набирает документ, а потом отвечает за него; здесь он сначала проверяет, а потом отвечает. Ответственность у него та же, работы меньше.

Права в самой 1С и черновик через OData: второй замок, который не зависит от нас

Мне важно, чтобы защита не держалась на одном слое, даже если это мой слой. Поэтому вторая линия обороны — сама 1С. В системе прав платформы для документов есть отдельные права на проведение, отмену проведения и их интерактивные варианты, а если у пользователя нет права интерактивного изменения проведённых, он не может интерактивно ни изменить проведённый документ, ни отменить его проведение (это интерактивное право; программные операции регулируются основными правами «Проведение» и «Отмена проведения»). Стандарты разработки 1С добавляют важное замечание: право редактирования документа включает проведение, а операции с повышенными привилегиями рекомендуется выдавать отдельной ролью. Практический вывод: для учётной записи интеграции ищите или соберите роль «чтение справочников и создание документов без проведения». Возможно ли это в вашей конфигурации без доработки, проверьте на своей версии.

Теперь про технику. Если 1С опубликована со стандартным интерфейсом OData, то по документации 1С:Фреш документ создаётся POST-запросом к коллекции, при этом свойство Posted не указывается, и документ появляется непроведённым. Проведение — отдельная операция Post(), отмена проведения — Unpost(). Иными словами, разница между черновиком и проведённым документом — один дополнительный HTTP-вызов. Поэтому правила безопасности надо ставить именно вокруг этого вызова: в конвейере он запрещён, а у учётной записи интеграции не должно быть права на такое действие. Шаблоны запросов из документации (имя документа и ключ подставьте свои):

POST .../odata/standard.odata/Document_ИмяДокумента?$format=json
POST .../odata/standard.odata/Document_ИмяДокумента(guid'КЛЮЧ')/Post()
POST .../odata/standard.odata/Document_ИмяДокумента(guid'КЛЮЧ')/Unpost()

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

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

curl -s -G -u "svc_readonly:$ODATA_PASS" \
  --data-urlencode '$format=json' --data-urlencode '$select=Posted' \
  "https://1c.example.com/base/odata/standard.odata/Document_ИмяДокумента(guid'КЛЮЧ')"

Если в ответе Posted равно false, документ не проведён. Замените адрес, имя документа и ключ на свои, а синтаксис сверьте с версией платформы: у разных версий нюансы бывают. Как я собирал такой же принцип «только черновики» в потоке из почты, я описывал в разборе n8n и LLM-агента для входящих счетов.

Третий слой — дата запрета изменения данных. В типовых конфигурациях механизм включается флагом «Даты запрета изменения» в разделе «Администрирование»; в каком именно подразделе он находится и откуда открывается сама настройка дат, зависит от конфигурации и релиза, поэтому сверьтесь с описанием своей версии. Закрыли период — сразу ставьте запрет: тогда даже случайное проведение задним числом не пройдёт. И ещё одно условие из нашего модуля: запись разрешается только при подтверждённой резервной копии. Как копия делается в вашей инфраструктуре (средствами СУБД, сервера виртуализации или выгрузкой базы), отдельный вопрос, но без неё включать запись я не советую никому.

• Учётная запись интеграции отдельная, не «администратор» и не учётка бухгалтера.
• У неё нет права проведения и отмены проведения; проверено под этой учёткой, а не по названию роли.
• Дата запрета изменения данных стоит на закрытых периодах.
• Перед включением записи есть подтверждённая резервная копия.
• Проведение делает бухгалтер под своей учётной записью.

Где автопроведения хочется и что я на это отвечаю

Самый частый аргумент «за» звучит так: «Вот УПД от постоянного поставщика, шаблон отработан, что там проверять? Пусть проводится само». Я понимаю логику, но отвечаю так: проверять нужно не документ, а решение. Шаблон поставщика в нашей системе ускоряет чтение: после одобрения запоминается макет бланка, и следующий документ читается по шаблону. Но он не отменяет вопрос «нужно ли принимать это к учёту и в каком периоде». К тому же считать надо честно. В условном «Финотчёте» при тех же допущениях 700 документов в месяц по 5 секунд на клик «Провести» — это около часа в месяц. Ради часа отдавать роботу ответственность за регистры я не стану.

Теперь про границы. Модуль не нужен, если первичка приходит единицами в месяц: проще вводить руками. Он ошибается на плохих фото и нестандартных бланках: там документ проходит подготовку скана (контраст, шум, выравнивание), при низкой уверенности включается второй движок PaddleOCR, а если и этого мало, документ честно помечается низкой уверенностью, и замечания показывают, какие поля проверить. Процентов точности я не обещаю: их нет ни на странице продукта, ни в моих замерах, которые я мог бы выдать за общие. Реальную картину даёт только ваша пачка сканов.

Что я советую сделать на этой неделе, по приоритету. Первое: договориться, что проводит только человек, и записать это в регламент. Второе: проверить, что у учётки интеграции нет права проведения, и что на закрытые периоды стоит дата запрета. Третье: собрать 10–20 сканов типичной первички и прогнать ваши сканы в dry-run: мы покажем карточки, замечания и то, что создалось бы в вашей 1С; это бесплатно, в вашем контуре или на нашем стенде. Если модуль вам не понадобится, вы всё равно получите проверенные права и регламент, которые полезны и без него.

Частые вопросы