Акты сверки взаиморасчётов в 1С

«Акт сверки взаиморасчётов» фиксирует по одному контрагенту и одному периоду, что каждая сторона считает долгом другой. В нём две табличные части, потому что в нём два мнения, и документ полезен только когда заполнены оба.

Для этого есть кит: установите 1c-reconciliation-act-kz (см. стартовый кит 1С), а не пишите новый скрипт. Правила ниже — то, что он проверяет, и то, что нужно соблюсти, если вы его адаптируете.

Сторона контрагента — его, и вы её не знаете

ПоДаннымОрганизации — это ваш учёт. ПоДаннымКонтрагента — их, и что у них в учёте, скрипт не знает.

Есть три честных состояния, и по умолчанию — третье:

1. У вас есть их акт. Заполните вторую таблицу по нему и явно укажите расхождения. В этом весь смысл документа.
2. Человек установил, что они отразили те же операции. Отразите строки зеркально — те же даты, документы, типы и договоры, дебет и кредит меняются местами — и отметьте сверку согласованной: create-act.py --counterparty-confirmed.
3. Вы не знаете ничего. Их таблица пустая, «Сверка согласована» — нет.

Не отражайте зеркально по умолчанию. Акт, чья колонка контрагента выведена из вашего же учёта и помечен «Сверка согласована», утверждает, что они подтвердили цифры, которых не видели, — на документе, который вы им отправите. Кит отказывается и предупреждает, когда акт пишется несогласованным, чтобы пустая колонка была решением, а не недосмотром.

Правило договора

Посчитайте договоры контрагента в Catalog_ДоговорыКонтрагентов по Owner_Key, с нужной Организация_Key, DeletionMark=false и IsFolder=false. Далее:

Выбрать один из нескольких наугад хуже, чем оставить пустым: пустое поле читается как «по всем договорам», и это правда, а угаданное утверждает, какой именно долг сверяется.

Направление дебета и кредита

Для расчётов с покупателями в ПоДаннымОрганизации:

• реализация (РеализацияТоваровУслуг) — дебет;
• входящая оплата (ПлатежноеПоручениеВходящее, ПлатежныйОрдерПоступлениеДенежныхСредств) — кредит.

Не принимайте это на веру во всех конфигурациях — и не читайте акты вручную. Запустите:

python3 scripts/1c/reconciliation-act/check-direction.py
python3 scripts/1c/reconciliation-act/check-direction.py --since 2025-01-01

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

Нужно минимум 3 строки минимум в 2 актах на каждый тип документа. Меньше — он сообщает, что данных не хватает, и не печатает ничего для вставки. Одна строка — это частный случай, а вставленное сюда значение определяет знак каждого будущего акта: три строки одного акта могут быть одной и той же операцией, а два акта по одной строке — в шаге от совпадения. Акты, написанные китом, исключаются: принимать собственный вывод за доказательство методики — это способ сделать первую ошибку постоянной.

Локальным, а не универсальным, это делают две вещи, и обе видны как «BOTH — mixed evidence»: направление инвертируется по виду расчётов (дебиторка покупателя растёт от реализации, кредиторка перед поставщиком — падает) и меняется со временем: акты базы трёхлетней давности могут быть обратными нынешним. --since — это способ спросить, как база делает сейчас. Направление — единственное здесь, где неверный ответ выглядит правдоподобно и молча.

Начальное сальдо и расхождение — это разные числа

ОстатокНаНачало — свёртка всех документов расчётов до начала периода, а не ноль и не первая строка. Считайте его по тем же документам и тем же правилам, что и тело акта.

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

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

Все типы расчётов из базы, а не только настроенные

Типы для чтения определяются по базе — по тому, что знает entity_sets этой установки, — и только потом сверяются с document_sides. В обратном порядке это проверка, которая не может сработать: если читать только уже объявленные типы, то забытый тип никогда не прочитан, не показан и молча отсутствует в сальдо. Так и было сальдо — а акт читается как готовый: код возврата 0 и ничего в отчёте, что намекало бы на пропущенное число.

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

Одна валюта

Не складывайте документы в разных валютах в одно сальдо и не берите валюту из акта-шаблона. Берите из документов; отказывайтесь, если они расходятся. Число, верное в одной валюте и подписанное другой, — самая незаметная ошибка.

Договор в строке — это договор того документа

В шапке договор выбирается по правилу выше. Каждая строка несёт ДоговорКонтрагента_Key своего документа, а договор из шапки — только когда документ не называет своего. Переклеивание сегодняшнего договора на исторический документ искажает, какой именно долг сверяется.

Поля, которые кит заполняет сам

• Posted = false, DeletionMark = false — такой же черновик, как всё остальное, что пишет кит. Проведение остаётся решением бухгалтера, принятым в 1С.
• СверкаСогласована — следует за подтверждением, а не за фактом записи. См. выше.
• Автор, ответственный и СписокСчетов берутся из свежего корректного акта той же организации в той же базе. Это настройки уровня базы, и Ref_Key из другой базы не значит ничего. Валюта — нет: она берётся из документов.

Обе табличные части передаются внутри POST самого документа — строки нельзя создать через их собственный entity set.

Защита от дублей

Перед созданием найдите активный акт с той же организацией, тем же контрагентом и тем же периодом. Один период, сверенный дважды, — это два документа, которые противоречат друг другу по построению.

Контрагента находите по точному БИН/ИИН. Ноль совпадений или несколько — это остановиться и спросить, а не догадка по названию.

Проверять чтением — суммы

После записи перечитайте документ по Ref_Key и сверьте с тем, что вы посчитали: период, контрагента, договор, валюту, начальное сальдо, расхождение, Posted=false, «Сверка согласована», а по обеим таблицам — число строк и в каждой строке «Дебет», «Кредит» и ссылку на документ.

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

HTTP 2xx — не доказательство. См. Работу с 1С через OData §9.

Известные ограничения

• Проверка дублей не атомарна. Сначала читается список актов, потом делается POST. Ограничения уникальности через OData 1С не даёт, поэтому два одновременных запуска по одному контрагенту и периоду могут пройти оба и записать оба. Запускайте по одному.
• Поле конечного сальдо не записывается. В каком реквизите конфигурация его держит — не установлено, а записать непроверенное имя поля хуже, чем позволить конфигурации посчитать его по строкам.

Проведение

Только по отдельной прямой команде пользователя.