Разноска банковской выписки в 1С (Казахстан)

Это регламент безопасной и проверяемой загрузки банковской выписки в 1С через стандартный интерфейс OData. Он получен из реальной загрузки в базу «Бухгалтерский учет для Казахстана, редакция 2.5» и предназначен одновременно для бухгалтера и для ассистента, выполняющего техническую работу: все команды здесь запускает ассистент, пользователю терминал не нужен.

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

Регламент применяется, когда нужно:

• разобрать банковскую выписку в формате 1CClientBankExchange;
• создать входящие и исходящие платёжные документы;
• обработать платёжные ордера эквайринга/QR;
• сопоставить контрагентов, договоры и банковские счета;
• сформировать пенсионные, социальные и медицинские платежи со списками сотрудников;
• оформить налоги и пени с правильными КНП, КБК и видом операции;
• доказать, что все операции выписки отражены один раз и только один раз;
• оставить документы непроведёнными до бухгалтерской проверки.

1. Главный принцип безопасности

Сначала полная проверка, потом создание черновиков, затем повторная сверка, и только после ручного просмотра — проведение.

До окончания проверки каждый созданный документ должен иметь:

• Posted=false — документ не проведён;
• DeletionMark=false — документ не помечен на удаление;
• Оплачено=true — операция действительно присутствует в банковской выписке;
• понятный комментарий о том, что документ создан из банковской выписки и требует проверки.

Ассистент не проводит документы автоматически. Проведение меняет бухгалтерские регистры и выполняется только после явного решения пользователя.

2. Что является источником истины

Приоритет источников:

1. Банковская выписка — источник даты операции, банковского номера, суммы, направления, назначения, КНП, БИН/ИИН и ИИК.
2. Отдельный банковский файл со списком сотрудников — источник ФИО, ИИН, периода и суммы по каждому сотруднику.
3. Справочники 1С — источник внутренних ссылок на контрагента, физическое лицо, договор, банковский счёт, налог и счета учёта.
4. Ранее правильно оформленные документы 1С — источник структуры и конфигурационных реквизитов, но никогда не источник текущей суммы или текущего банковского счёта.
5. Пользователь — источник решений по неоднозначной классификации.

Критически важно: сохранённый в карточке контрагента «основной счёт» не имеет приоритета над ИИК в текущей выписке. Для каждого платежа выбирается счёт, который указал банк.

3. Термины

Задействованные наборы OData:

4. Входные файлы

4.1 Основная выписка

Поддерживаемый формат: 1CClientBankExchange. Заголовок должен содержать ДатаНачала, ДатаКонца, РасчСчет, НачальныйОстаток, ВсегоПоступило, ВсегоСписано, КонечныйОстаток.

Каждая операция должна иметь минимум: НомерДокумента, ДатаДокумента, ДатаОперации, ВидДокумента, плательщика и получателя, БИН/ИИН, ИИК, СуммаПриход или СуммаРасход, НазначениеПлатежа, КодНазначенияПлатежа.

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

4.2 Файлы со списками сотрудников

«Платежное поручение со списком» нельзя создать только по общей выписке. Нужен отдельный файл версии 1CClientBankExchange 2.00 с блоком СПИСОКСОТРУДНИКОВ, где для каждого сотрудника обязательны СОТРУДНИК (ФИО), СотрудникБИН_ИИН, СотрудникДатаРождения, Период в формате ММГГГГ и Сумма.

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

4.3 Чья это выписка?

До арифметики и вообще до всего: убедитесь, что выписка относится к компании, под которую настроено это пространство. РасчСчет самой выписки должен совпадать с mapping.organization_account.iban, а база — действительно содержать организацию, закреплённую в mapping.json.

Это не формальность, и четыре равенства из §5 этого не покрывают: они доказывают, что файл внутренне непротиворечив, — а он таков и когда принадлежит другому клиенту. У бухгалтера с 17 компаниями 17 баз, и mapping, который скопировали и не адаптировали, указывает на предыдущую. Загрузка тогда проходит, сверяется и отчитывается чисто — в чужой учёт.

import-statement.py теперь проверяет и то и другое, и любой отказ считает ошибкой. Полное правило, включая случай, когда в одной базе две организации с почти одинаковыми названиями, — в §2.5 правил OData.

4.4 Несколько баз в одном пространстве

Одно пространство может быть настроено на несколько баз 1С — одна бухгалтерская практика ведёт четыре из одной папки scripts/1c, другая десять. Каждая база — это пара файлов: credentials.json и mapping. Базу выбирает именно mapping, и называется он по клиенту:

scripts/1c/mapping.json               ← база, которую имеет в виду прогон без --mapping
scripts/1c/<клиент>-mapping.json
scripts/1c/<клиент>-mapping.json

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

python3 scripts/1c/odata/bases.py

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

Из этого следует три вещи, и они важнее, чем кажутся:

• Называйте базу в каждой команде. Если настроено больше одной базы, прогон без --mapping отказывается вместо того, чтобы угадывать, и перечисляет базы. Раньше он брал mapping.json просто потому, что файл так называется, — это верно ровно один раз, а в остальных случаях это чужой учёт.
• Всё выведенное по базе хранится по базе. У <клиент>-mapping.json свой <клиент>-base-profile.json и своя страница «Правила учёта». Пространства с ОДНОЙ базой это не касается: у mapping.json остаётся base-profile.json, ровно как было, — переносить и переименовывать нечего.
• Несовпадение mapping и базы останавливает прогон. Если учётные данные ведут в базу одной компании, а mapping описывает другую, прогон откажется до любой записи и назовёт оба файла и обе компании. Это ошибка НАСТРОЙКИ — два файла от разных клиентов, — а не поломка кита. Исправляется тем, что --mapping (и --credentials) указывают на пару, которая принадлежит друг другу.

5. Арифметический контроль

До работы с 1С должны выполняться четыре равенства:

1. Сумма всех СуммаПриход равна ВсегоПоступило.
2. Сумма всех СуммаРасход равна ВсегоСписано.
3. Начальный остаток + Поступления − Списания = Конечный остаток.
4. Количество распознанных секций СекцияДокумент=выписка совпадает с количеством обработанных строк.

Если арифметика не сходится, импорт прекращается. Нельзя компенсировать расхождение ручной корректирующей строкой без объяснения банка.

6. Dry-run обязателен

Сначала запуск без --apply. Dry-run должен показать:

• количество операций в файле;
• количество уже существующих в 1С;
• количество планируемых документов;
• планируемую сумму;
• распределение по типам документов 1С;
• отсутствующих контрагентов;
• отсутствующие банковские счета;
• операции, требующие списка;
• налоговые или иные неоднозначные операции.

Предупреждения принимаются только осознанным решением пользователя. Ошибки этому флагу не поддаются никогда.

6.1 Одна плохая строка не держит хорошие

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

Поэтому у прогона четыре исхода, и код возврата их различает:

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

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

Никогда не выдавайте частичный импорт за законченный. В заголовке такого отчёта стоит «ЧАСТИЧНЫЙ ИМПОРТ», и код возврата не 0. Скажите пользователю, сколько строк записано, сколько нет и что нужно для каждой из них.

6.2 Строка, которую читают первой: «Сверка с источником»

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

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

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

Банковские номера повторяются в разные даты и годы, поэтому номер сам по себе не является идентичностью. Используйте составную сигнатуру — тип документа + банковский номер + дата операции + сумма — подкреплённую направлением, БИН/ИИН, ИИК, назначением и КНП. Подробное обоснование — в Работе с 1С через OData, §6.

Эта же сигнатура — единственное, что делает строку дублем. Две просто похожие строки — одна сумма, один день, разные банковские номера — считаются двумя движениями, пока не доказано обратное; планка описана в §13.2.

И сигнатура находит только те документы, которые записаны так, как записываете вы. Платёж, занесённый бухгалтером в 1С руками, не несёт ни банковского номера, ни якоря, поэтому он никогда не столкнётся со строкой выписки — каким бы полным ни выглядел индекс; см. Работу с 1С через OData, §6, «„Опознаваемый“ — не значит „сопоставимый“». До записи пройдите по расчётному счёту за период выписки и соберите документы, на которых нет вашего якоря и чья сигнатура ни с чем не совпала, сверьте их с выпиской по (дата, сумма, направление) и вынесите совпадения в сухой прогон как вопросы. Этот проход — единственное, что стоит между занесённым вручную платежом и его второй копией.

Форму документа называет собственная строка ВидДокумента, а не заголовок секции. Экспорт Kaspi открывает каждую секцию как СекцияДокумент=выписка — это имя ФАЙЛА, а не форма документа, — а настоящую форму («Платежный ордер», «Платежное поручение») пишет строкой ниже. До 14.09.2026 разбор предпочитал заголовок, поэтому doc_kind у всех строк был «выписка» и ни одна строка не могла стать платёжным ордером. Пустая строка ВидДокумента= заголовок не затирает, а признак «со списком» читается из обоих полей. parse-statement.py печатает про это одну строку на весь файл — с обоими словами и числом строк.

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

Строка выписки может лежать в базе кассовым ордером, и прогон об этом спросит. «Взнос наличными в банк» и «Получение наличных в банке» — это документы, которые бухгалтер заводит сама, и денег по ним столько же, сколько в выписке. Такой ордер несёт собственный номер 1С, а не банковский, поэтому сигнатура его не найдёт никогда; прогон сверяет его с планируемой строкой по дате и сумме и не пишет эту строку, называя номер и ссылку документа (cash-order-collision) — остальные строки записываются, импорт завершается как частичный (код выхода 3). Это вопрос к бухгалтеру, а не тихий пропуск, и ответ записывается одной из двух записей, которые отчёт печатает с точной подписью строки: если это тот же взнос — duplicate_decisions.known_existing_by_signature («строка уже в 1С»); если другая операция — duplicate_decisions.distinct_from_cash_orders со списком Ref_Key проверенных ордеров («пишите»). Второй ответ привязан к названным документам: ордер, заведённый после проверки, снова остановит строку. Номер входящего документа в кассовом ордере ничего не меняет — ордера сверяются без номера. reconcile.py читает тот же список типов и показывает строку, которая и импортирована, и заведена кассовым ордером, отдельным разделом. Останавливает только совпадение — кассовые ордера, которые ни с чем не совпали, просто перечисляются в отчёте, иначе контроль держал бы каждую загрузку компании, сдающей выручку в банк. Если кассовые ордера прочитать не удалось (таймаут, недоступный набор), прогон выдаёт предупреждение, а не сообщение: сравнение не выполнялось, и знать об этом нужно до записи.

8. Классификация операций

Классификация никогда не определяется одними словами «платежное поручение». Важны направление, КНП, текст назначения и наличие списка.

9. Обычные платежи

Для исходящего платежа проверяются: организация; расчётный счёт организации; контрагент; ИИК получателя из выписки; договор; вид операции; статья движения денежных средств; счета расчётов БУ и НУ; сумма; дата выписки; банковский номер; назначение; КНП; НДС, если применим.

Для оплаты поставщику контрагент и счёт выбираются по БИН/ИИН и ИИК, назначение копируется из банка без сокращений. Если назначение содержит счёт на оплату, по возможности проверьте соответствующий документ 1С — но отсутствие ссылки не должно превращаться в выдуманную связь.

Для входящего платежа покупателя: плательщик сопоставляется с контрагентом, его ИИК — с банковским счётом, вид операции ОплатаПокупателя, сумма и назначение копируются из банка. Если в назначении НДС указан явно, ставка берётся из Catalog_СтавкиНДС, а сумма НДС должна точно совпасть с текстом банка. Если НДС не указан, вычислять его по догадке из суммы нельзя.

Для договоров используется основной договор контрагента, если назначение или документ-основание не указывают другой. Нельзя автоматически создавать новый договор только потому, что основной не найден.

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

9.1 Расчёты или аванс — 3310 против 1710

Платёж поставщику, которому вы должны, закрывает долг (Дт 3310). Платёж поставщику, которому вы не должны, — это аванс (Дт 1710). У покупателя тот же вопрос на счёт в сторону: 1210 против 3510. В выписке они выглядят одинаково и отличаются только тем, что уже есть в базе.

Пока это не настроено в рабочей области, ничего не меняется — счёт берётся из того, что база ставит на сопоставимых проведённых документах, ровно как раньше. Где настроено, остаток считается по собственным проведённым документам базы, поэтому публиковать регистр не нужно: каждый источник в mapping.json объявляет знак, которым он двигает остаток, +1 для документа, увеличивающего долг поставщику, и -1 для уменьшающего.

Четыре вещи, которых он не сделает, и в них весь смысл:

• Доказанный расчёт не меняет ничего. Этот счёт уже выведен из истории самой базы, и заменять его константой из настроек — менять доказательство на догадку, в том числе на базах, где бухгалтер оставляет поле пустым намеренно. Пишется только аванс: именно его история показать не может.
• Ноль на новом договоре — это не «долга нет». Поставщик, переведённый на свежий договор, несёт ноль там, пока долг стоит на старом. Прогон говорит об этом, называет сумму и ничего не меняет. Перенос долга между договорами — корректировка, которую бухгалтер делает осознанно, а не массовая переписка прежних документов.
• Платёж больше долга не округляется до одного счёта. Он закрывает долг, а остальное — аванс. Может ли документ нести оба счёта, спрашивается у самой базы (allow_split: "auto", по умолчанию): где не может или где allow_split равен false, прогон сообщает обе половины и оставляет счёт как есть.
• Каждый счёт пишется только туда, где у документа есть такое поле. В измеренной конфигурации счёт авансов (СчетУчетаРасчетовПоАвансам_Key, без «БУ») есть в строке расшифровки платежа и отсутствует в шапке документа — а одно поле, которого у документа нет, и 1С отклоняет весь документ. Поэтому прогон один раз читает список полей базы, пишет каждый счёт только туда, где поле есть, и называет в отчёте настроенное поле, которое некуда записать.
• Пустой счёт авансов заполняется. 1С сама делит платёж при проведении на «Оплата» и «Оплата (аванс)», и при пустом счёте авансов в строке относит аванс на счёт расчётов — без всякой ошибки. Если счета настроены, строка платежа без счёта авансов получает настроенный; заполненный счёт не трогается, и ничего не заполняется там, где долг может стоять на другом договоре.
• Ничего не блокируется. Любой отказ — это строка в отчёте, а не остановка импорта.

В отчёте видно разницу между «3310 (остаток по договору на 22.06.2026: 450 000,00 ₸)» и строкой, которую проверить не удалось. Это один и тот же счёт по двум очень разным причинам, и ответом является только первая.

9.2 У каждого платежа есть статья ДДС

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

Кит записывает одну строку РасшифровкаПлатежа со всей суммой и статьёй и вообще ничего не пишет, пока статью не удалось определить. Настраивается в mapping.json:

"cash_flow_articles": {
  "default_incoming": "Реализация работ и услуг",
  "default_outgoing": "Расчеты с поставщиками и подрядчиками",
  "by_knp": { "851": "Расчеты с поставщиками и подрядчиками" }
}

Не копируйте эти названия как значения по умолчанию. Статья — это учётная политика конкретной компании: посмотрите, что использовали собственные прежние документы этой базы для операций того же рода, и запишите это. by_knp перекрывает значение по направлению для конкретного КНП. Статьи указываются наименованием, а не Ref_Key: Ref_Key в другой базе бессмыслен (§11 правил OData), а другого идентификатора этот справочник не даёт.

Это ошибка, а не предупреждение, потому что сбой невидим: импорт может записать все строки, свести все итоги и пройти сверку, пока статья у большинства документов пуста. Теперь сверка проверяет и статью, а нулевой GUID из 1С считает отсутствием, а не значением.

9.3 Оплату платёжными картами нельзя провести без договора эквайринга

Если пользователь просит вместе с эквайринговыми поступлениями создать документы «Оплата платежными картами», сначала проверьте, что Catalog_ДоговорыЭквайринга и Catalog_ВидыОплатЭквайринга не пусты — это показывает check-access.py. Если они пусты, Post() отвечает HTTP 500 без внятных деталей, и никакой payload это не исправит: справочных данных, которые нужны алгоритму проведения, в базе просто нет.

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

10. Налоги

Налоговый платёж оформляется операцией ПеречислениеНалога и требует ВидНалога_Key, КБК, КНП, налогового органа и его счёта, счетов учёта БУ и НУ, субконто вида налога, вида платежа Налог, а также суммы и назначения из выписки.

Нельзя выбирать вид налога только по КНП. У разных налогов один КНП, но разные КБК и счета учёта — например, ИПН у источника выплаты и социальный налог обычно приходят с КНП 911 и различаются только КБК.

10.1 В выписке нет КБК — это норма, а не повод остановиться

В банковских выписках Казахстана поля КБК нет. Его отсутствие — обычный случай, а не нехватка данных, и само по себе оно не должно превращаться в вопрос пользователю. КБК — не значение, которое вы выбираете, а реквизит элемента справочника, который вы выбираете. Документ ссылается на налог через ВидНалога_Key, а Catalog_НалогиСборыОтчисления.КодБК подтягивается вместе с ним. Поэтому определяйте элемент, в таком порядке, и останавливайтесь на первом шаге, который даёт ответ:

1. Сопоставьте назначение платежа с элементом справочника. Прочитайте Catalog_НалогиСборыОтчисления и сопоставьте назначение платежа из выписки с Description. «Таможенный сбор», «Таможенная пошлина» и «НДС при импорте» — разные элементы с разными КодБК; назначение платежа разделяет их даже там, где КНП совпадает.
2. Подтвердите историей проведённых документов. Найдите проведённые документы с тем же КНП, тем же налоговым органом и той же или близкой суммой. Совпадение подтверждает элемент — это самое сильное доступное доказательство; зафиксируйте его в отчёте.
3. И только потом спрашивайте — и только если под назначение подходят два и более элемента, а история их не разделяет. Назовите кандидатов и скажите, чем они отличаются, вместо того чтобы просить пользователя назвать код.

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

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

11. Пени

Пени по взносам в фонды — не платежи со списком. Они оформляются как:

• операция ПеречислениеНалога;
• вид платежа ПениСам;
• соответствующий элемент Catalog_НалогиСборыОтчисления;
• КНП и счёт фонда из выписки;
• сумма и назначение из выписки;
• пустые табличные части пенсионных и социальных перечислений.

Системное значение перечисления — ПениСам. Значения Пеня в этой конфигурации нет — попытка его использовать вызывает ошибку OData. Если сомневаетесь, прочитайте EnumType из $metadata.

12. Пять платежей со списками

Списки требуются только этим пяти:

12.1 Тройной контроль суммы

Должны совпасть три суммы:

сумма платёжного поручения
= сумма связанных документов-оснований
= сумма строк по сотрудникам

Любое расхождение блокирует проведение.

12.2 Период

Период=062026 преобразуется в 2026-06-01T00:00:00. Записывается в ПериодРегистрации, а для социальных строк — также в МесяцПериода.

12.3 Разделение личных сумм предпринимателя

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

12.4 Виды операций оснований

12.5 Структура строк основания

Для ОПВ/ОПВР:

ФизЛицо      = Ref_Key физического лица
ФизЛицо_Type = StandardODATA.Catalog_ФизическиеЛица
Сумма        = сумма по сотруднику

Для СО/ООСМС/ВОСМС дополнительно:

МесяцПериода = первый день месяца начисления

Сотрудники сопоставляются по ИИН через Catalog_ФизическиеЛица.ИдентификационныйКодЛичности, с подтверждением по ФИО и дате рождения. Если у двух физических лиц один ИИН, используйте ссылку, которая уже применялась в правильных документах, — не выбирайте случайную.

12.6 Связь платежа с основаниями

В платёжном поручении создаётся строка:

Документ_Key       = Ref_Key документа-основания
СуммаКПеречислению = сумма основания

Строки табличной части нельзя создавать отдельным entity set, поэтому эта строка передаётся внутри самого POST платёжного поручения.

12.7 Правильная последовательность

1. Получить основную выписку.
2. Обнаружить «Платежное поручение со списком».
3. Не создавать платёжный документ по одной общей сумме.
4. Получить отдельный файл списка.
5. Проверить по нему банковский номер, КНП, период и итоговую сумму.
6. Проверить сумму всех сотрудников.
7. Сопоставить каждого сотрудника по ИИН.
8. Разделить личные суммы предпринимателя, если это практика базы.
9. Создать непроведённые документы-основания.
10. Проверить их строки и суммы.
11. Создать платёжное поручение сразу с заполненными строками ссылок.
12. Перечитать созданный документ из 1С.
13. Выполнить тройной контроль суммы.
14. Только теперь показать документ пользователю на проверку.

13. Финальная сверка

После импорта постройте независимый индекс документов 1С и повторно сопоставьте каждую строку выписки. Обязательный результат:

• каждая строка выписки найдена;
• отсутствующих строк — 0;
• неожиданных дублей — 0, посчитанных по счёту, по (дата, сумма, направление), а не по одной вашей сигнатуре. Подсчёт только по сигнатуре не увидит двойник, который вы сами создали рядом с занесённым вручную документом, — а это ровно тот дубль, ради которого шаг и существует (§7);
• сумма поступлений совпадает;
• сумма списаний совпадает;
• остаток совпадает;
• обороты по счёту в 1С, применённые к начальному остатку выписки, дают её конечный остаток (§13.1);
• каждая осознанно пропущенная строка перечислена с суммой, и вызванное ею расхождение остатка заявлено заранее (§13.1);
• все новые документы непроведены;
• все новые документы не помечены на удаление;
• статья ДДС заполнена в каждой строке расшифровки — нулевой GUID это отсутствие, а не значение, а секция, которую состав OData не публикует, считается непроверенной, и отчёт так и говорит, а не умалчивает;
• КНП и КБК совпадают;
• банковские счета совпадают с выпиской;
• списки сотрудников заполнены;
• суммы списков совпадают.

Для каждой строки проверяется не только наличие, но и правильный тип документа.

13.1 Сверяйтесь с банком, а не со своими же решениями

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

Поэтому по другую сторону сравнения должен стоять банк:

• Сравнивайте обороты по счёту в 1С с шапкой самой выписки. Просуммируйте приход и расход, фактически отражённые в 1С по расчётному счёту организации за период выписки, примените их к НачальныйОстаток и требуйте, чтобы получился КонечныйОстаток. Это единственный контроль во всём регламенте с внешней точкой отсчёта. Четыре равенства §5 доказывают, что файл внутренне непротиворечив; построчное сопоставление доказывает, что каждый созданный документ отвечает оставленной строке. Ни то ни другое не заметит строку, которую вы не оставили.
• Пропуски оформляйте как названное и посчитанное расхождение — до того, как его найдёт бухгалтер. Каждая осознанно исключённая строка должна попасть в отчёт с банковским номером, датой, суммой и причиной, с итогом, а контроль остатка обязан прямо назвать вызванную разницу: «конечный остаток в 1С меньше выписки на X — ожидаемо: N строк пропущено как Y, на сумму Z». Заявленное расхождение — это решение, которое бухгалтер принимает или отменяет за минуту. То же расхождение, найденное потом, — это дефект, и первым он находит недостающую сумму, а не строки за ней.
• Никогда не отчитывайтесь о чистой сверке по суженному множеству. Если строки пропускались, «всё сходится» — неправда, что бы ни показывали счётчики. Скажите, что исключено и что из-за этого показывает учёт.

13.2 Планка, ниже которой строка не называется дублем

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

Три проверки дёшевы и обычно решают вопрос:

• Собственная арифметика выписки. Если Начальный остаток + Поступления − Списания даёт заявленный банком КонечныйОстаток только тогда, когда посчитаны все похожие строки, значит все они — реальные деньги: этим равенством банк утверждает именно такой состав строк. Уберите одну — равенство перестаёт выполняться, и это ровно та недостача, которую увидит бухгалтер.
• Как эта же строка ведёт себя во все остальные дни файла. Возьмите сумму, назначение и контрагента и посчитайте их по всей выписке. Платёж, который в двадцати датах стоит один, а в трёх удваивается, — это график, а не повторная выгрузка; правило «одна сумма, один день» отметит ровно эти три даты, то есть сработает наоборот: пропустит дни, доказывающие закономерность, и остановится на днях, которые ей следуют. Повторяющаяся фиксированная сумма одинакова по замыслу, поэтому одинаковость — признак графика, а не дубля.
• История самой базы и заметки рабочего пространства. Накопленные знания о компании могут уже содержать разбор конкретной похожей пары как двух настоящих операций. Прочитайте это прежде, чем открывать вопрос заново, и запишите ответ обратно, чтобы следующая загрузка его тоже не открывала.

Дубль, с которым действительно нужно что-то делать, — это артефакт повторной выгрузки: одинаковые тип документа, банковский номер, дата операции и сумма дважды в файле, либо документ, уже лежащий в 1С с этой составной сигнатурой (§7). Именно это означает «неожиданных дублей — 0». Всё, что слабее, — вопрос к бухгалтеру, а не решение ассистента; а если он пропуск подтвердил, тот становится посчитанным расхождением по §13.1, а не молчаливым умолчанием.

Если арифметика §5 сходится на полном составе строк, искать артефакт не в чем — остановитесь. Повторная выгрузка дублирует строку, но не дублирует деньги в банке, поэтому она ломает равенства шапки ровно на свою сумму. Если Начальный остаток + Поступления − Списания = Конечный остаток выполняется при учёте всех похожих строк, банк тем самым утверждает, что каждая из них двигала деньги, и вопрос закрыт самим файлом. Не выносите его бухгалтеру «на всякий случай». Вопрос «эти три списания по 347 825 ₸ — дубли?» по файлу, который уже доказал, что нет, провоцирует ответ «да», стоящий реального оборота, — и приходит этот ответ как указание, после которого его уже никто не переспрашивает.

Решение о дубле убирает копии. Оригинал оно не убирает никогда. N похожих строк дают максимум N−1 пропуск; «пропустить всю группу» не является возможным исходом находки дубля, кем бы он ни был предложен. Если бухгалтер просит убрать группу целиком — это другое решение: строки исключаются по какой-то иной причине, и записать и показать их нужно именно так, по §13.1, а не в графе дублей. Это не умозрительное различие: на реальной загрузке по такому указанию были пропущены три группы целиком и потеряно 2 367 455 ₸ настоящих списаний — каждое из них банк зафиксировал.

14. Чек-лист ручной бухгалтерской проверки

Перед проведением бухгалтер проверяет:

• Организация верна.
• Расчётный счёт организации совпадает с выпиской.
• Дата документа и дата выписки верны.
• Банковский номер перенесён правильно.
• Сумма совпадает до тиына.
• Контрагент найден по БИН/ИИН.
• ИИК контрагента совпадает с выпиской.
• Назначение платежа не искажено.
• КНП совпадает.
• Для налогов выбран правильный КБК.
• Для пеней выбран ПениСам.
• Для платежей со списком видны все сотрудники.
• Период сотрудников указан правильно.
• Сумма сотрудников равна платежу.
• НДС совпадает с назначением банка.
• Нет второго документа с той же сигнатурой.
• Каждая пропущенная строка перечислена с суммой, а вызванная ею разница остатка заявлена заранее.
• Конечный остаток по счёту в 1С совпадает с выпиской либо отличается ровно на эту заявленную сумму.
• Документ, который планируется провести, является исправленной версией.

15. Отчёт

Каждая загрузка завершается отдельным отчётом — держите их в synced_data/1c/, по одному на выписку — со следующими разделами: источник и период; расчётный счёт; количество операций; итоги поступлений и списаний; контроль остатков; сколько документов уже существовало; сколько создано; какие строки пропущены, с их суммами и вызванным расхождением остатка (§13.1); сколько обнаружено дублей; разбивка по типам документов; платежи со списками и результат тройной сверки; налоги и пени с КНП/КБК; отсутствующие справочные данные; документы, которые нельзя проводить; таблица замен и документов для удаления.

16. Краткий чек-лист ассистента

1. Прочитать index.md рабочего пространства, его контекстные заметки и этот регламент.
2. Проверить доступ к OData.
3. Прочитать только явно указанные пользователем файлы.
4. Разобрать выписку и проверить арифметику.
5. Найти существующие документы по составной сигнатуре.
6. Построить классификацию операций.
7. Сопоставить контрагентов по БИН/ИИН.
8. Сопоставить счета по точному ИИК.
9. Остановить платежи со списком, у которых нет отдельного файла.
10. Проверить налоги и пени по КНП/КБК и виду операции.
11. Запустить dry-run.
12. Показать пользователю предупреждения, влияющие на учёт.
13. Создать только непроведённые документы.
14. Перечитать созданные документы из 1С.
15. Сверить каждую строку и общие суммы.
16. Сформировать отчёт.
17. Ничего не проводить без отдельной команды.

17. Когда операция завершена

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

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