Банковская выписка в 1С: как об этом думать

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

Всё, что здесь написано, оплачено ошибкой на настоящих книгах. Ни одно правило не выведено из общих соображений.

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

---

0. Почему эта работа трудная

Ошибка в разнесении выписки обладает тремя свойствами одновременно, и именно их сочетание делает её опасной.

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

Она долговечна. Проведённый документ двигает регистры. Через месяц на нём стоит сверка, через квартал — декларация. Отменить его — это не «удалить строку», это перепровести всё, что на нём стоит.

Сверка её не видит. Импорт может сойтись 52 из 52 до тиына — и при этом 27 документов уйдут с пустой статьёй движения денежных средств, а каждый аванс встанет на счёт расчётов. Сверка проверяет количество и суммы. Она не проверяет бухгалтерский смысл.

Отсюда единственное общее правило этой страницы, из которого выводятся все остальные:

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

И его следствие, которое стоит держать в голове весь прогон: отказ — это результат. Строка, про которую вы честно написали «не знаю, какой договор, вот три кандидата», — это выполненная работа. Строка, в которую вы поставили правдоподобный договор, — это работа, которую кто-то будет искать полгода.

---

1. Первый вопрос: чья это база?

Прежде арифметики, прежде разбора файла, прежде всего остального.

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

Это не гипотетический сценарий, а измеренный режим отказа, и поймать его может только внешняя сверка:

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

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

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

---

2. Что спросить у базы, прежде чем решать хоть что-нибудь

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

Так что относитесь к этой стадии как к сбору доказательств, а не как к разведке: то, что вы выяснили, должно быть записано.

2.1 База уже ответила на большинство ваших вопросов

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

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

Не большинством. Единогласно.

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

2.2 Область вопроса — это половина ответа

Здесь легче всего ошибиться, и ошибка выглядит как работающая функция.

Прежде чем считать прецеденты, спросите себя: свойством чего является этот ответ?

Каждая строка этой таблицы — исправленная ошибка.

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

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

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

2.3 Свежесть против пожизненной частоты

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

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

Чистое пожизненное единогласие переспрашивать не нужно.

2.4 Пустое — это тоже ответ

Тонкость, которая стоила очень дорого.

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

Измерено на одной базе: на входящем платеже покупателя поле счёта расчётов пусто на 4 980 проведённых документах — против 264 с одним счётом, 59 с другим, 35 с третьим и 21 с четвёртым. Выбросьте пустые из подсчёта — и пять процентов доказательств превращаются в «семидесятипроцентное большинство», которое запишет счёт по предоставленным займам на девяносто пять настоящих платежей покупателей. Почти пятьдесят миллионов тенге не на том счёте.

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

Для полей, несущих содержание (сумма, контрагент, назначение, договор), прецедент не применяется вообще. Никогда. Содержание берётся из выписки или не берётся ниоткуда.

2.5 Сколько это стоит и что кэшировать

Полное чтение набора документов — это минуты. На одной измеренной базе полный проход по 17 231 документу занимает от 9,6 до 45 минут; на маленькой базе те же операции — доли секунды. Разброс огромен, и заранее вы его не знаете.

Практические следствия:

• Читайте один раз, считайте много. Проведённая история нужна для нескольких разных вопросов; прочитайте её один раз в начале и отвечайте по одной копии.
• Говорите, где вы находитесь. Молчащий процесс и зависший процесс выглядят одинаково — и для бухгалтера, который смотрит, и для того, кто решает, не убить ли его. Печатайте прогресс по страницам, без знаменателя: сколько всего страниц, вы узнаете, только когда они кончатся, так что «3 000 из 6 550» можно только выдумать.
• Кэш — только для чтения, которое ничего не пишет. Прогон, который может записать, обязан перечитать базу целиком. Это делает опасность устаревшего индекса недостижимой, а не «маловероятной». Количество документов в качестве ключа инвалидации не годится: оно не видит пары «удалили и добавили» и не видит правку на месте — а правка на месте это ровно то, как документ, введённый руками, становится узнаваемым.
• Файловая база обслуживает один запрос за раз. Параллельная проверка, запущенная во время прогона, умрёт по собственному таймауту и будет выглядеть как недоступная база. Прежде чем объявить базу лежащей, проверьте, не идёт ли у вас уже прогон по ней.
• Таймаут — свойство публикации, а не ваших настроек. Он должен лежать рядом с адресом базы, потому что человек, который встречает медленную публикацию, — это агент внутри рабочего пространства, и переменной окружения он не поставит. Измеренный случай: страница из пяти тысяч платёжных поручений отдавалась дольше минуты, индекс дублей вернулся неполным, прогон правильно отказался писать всю выписку — и напечатал совет, которому никто не мог последовать.

---

3. Разбор выписки

3.1 Что вынуть из каждой строки

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

3.2 Нормализация, и что нормализовать нельзя

Приводите к каноническому виду: даты — к ГГГГ-ММ-ДД; ИИК — в верхний регистр без пробелов; БИН/ИИН — только цифры, ровно двенадцать; суммы — к десятичному виду с точностью до тиына.

Не нормализуйте:

• Ведущие нули в номерах документов. «00000000091» и «91» — разные строки, и это различие несёт смысл (см. §5.2).
• Исходное назначение платежа. Храните его целиком и записывайте в документ целиком. Сокращённое назначение — это потерянное основание.

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

3.3 Направление

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

Перевод между своими счетами выделяйте отдельно на этом же шаге. Он не приход и не расход в обычном смысле — см. §5.3.

3.4 Составная подпись строки

Это самое важное, что вы делаете при разборе, потому что от него зависит вся защита от дублей.

Подпись строки:

организация + ИИК организации + дата + направление + сумма
          + банковская референция
          + БИН/ИИН контрагента + ИИК контрагента

Если банковской референции нет — добавьте нормализованное назначение платежа.

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

Последнее — не выдумка. В одной выписке две строки от 27-го числа на 185 000 ₸ одному контрагенту. Это два настоящих платежа. Подпись без референции их склеит, и второй будет объявлен дублем первого — то есть потерян.

---

4. Арифметика, которая даёт право писать

4.1 Чистый отчёт правом не является

Это исправление к самому распространённому и самому естественному заблуждению.

Измерено: восьмой пробный прогон вернулся с нулём ошибок и записал бы четыре перевода на общую сумму 4 400 000 ₸, которые уже были в базе. Отчёт был чистый. Всё было в порядке. Ничто не было в порядке.

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

Отсюда правило:

Разрешение писать даёт тождество, а не отсутствие ошибок:

записано + уже существует + осознанно пропущено == всего строк в выписке

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

Не сошлось — значит, есть строка, про которую вы не знаете, что с ней. Не важно, что ошибок нет.

4.2 Контроли самой выписки, до всякого импорта

Прежде чем что-либо решать про 1С, проверьте сам файл:

конечный остаток == начальный остаток + приход − расход

и вместе с ним: количество строк; сумму приходов; сумму расходов; отсутствие строк одновременно с дебетом и кредитом; отсутствие пустых сумм; отсутствие повторяющихся банковских референций; совпадение валюты операций с валютой счёта.

Не сошлось — не начинать импорт. Строка получает статус ОШИБКА_АРИФМЕТИКИ, прогон останавливается, и в отчёте написано, на сколько именно не сошлось. Расхождение в выписке — это либо повреждённый файл, либо файл не за тот период, либо файл не того счёта; ни один из этих случаев не лечится тем, что вы аккуратно разнесёте то, что в нём есть.

4.3 Каждая операция остаётся в плане

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

Выброшенная операция исчезает: её никто не посчитал, отчёт про неё не сказал, а контроль полноты потом выдаст вторую, вводящую в заблуждение ошибку про «потерянные операции». Пользователю сообщили число там, где нужен был вопрос.

Простейший контроль, который это ловит: количество строк в плане == количество операций в выписке, всегда, на каждом прогоне.

---

5. Дубли: почему повторный прогон — это норма

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

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

5.1 Подпись строки: обычный случай

Прежде чем создавать документ, ищите в базе документ с той же подписью. Нашли — строка получает НАЙДЕН_СУЩЕСТВУЮЩИЙ_ДОКУМЕНТ и считается в тождество §4.1 как «уже существует».

Это работает, когда документ создали вы, потому что вы записали в него узнаваемую метку.

5.2 Документ, введённый руками, вашей подписи не несёт

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

Ключевая деталь: поле «номер входящего документа» на введённом руками документе несёт собственный номер 1С, а не номер из выписки. Документ №00000000091 нёс «91», а выписка говорит «100». Ваш поиск по номеру банка его не найдёт никогда.

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

Так что строка получает статус вида «возможно, это документ №…, подтвердите», и её судьбу решает бухгалтер.

5.3 Перевод между своими счетами — это один документ и две выписки

Компания перевела деньги со своего счёта в банке А на свой счёт в банке Б. В выписке банка А это списание. В выписке банка Б это поступление. Документ в 1С один.

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

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

5.4 Три ловушки вокруг «наш ли это счёт»

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

Правило шире одного этого случая: когда вы чините предикат, найдите все места, где он спрашивается.

Вторая ловушка: проверка «ровно одна живая карточка несёт этот ИИК» ломается сама об себя. Прерванный прогон создал карточку «Счёт <наша компания> <банк>» — наш собственный ИИК на карточке контрагента, у которой тот же БИН, что у нашей организации. Теперь ИИК несут две карточки, проверка читает это как неоднозначность, и вся ветка «это наш перевод» замолкает. Правильная формулировка: счёт, которым организация владеет, наш — сколько бы других карточек ни упоминали его номер.

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

5.5 Осознанный пропуск — это четвёртое состояние строки

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

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

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

5.6 Вопросы «как построить» не задаются о строке, которую строить не нужно

Обобщение предыдущего пункта, и оно стоило целого раунда переписки с бухгалтером.

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

Измерено: апрельская выписка вернулась с нулём ошибок, 260 операциями из 263 уже импортированными — и тремя вопросами про КБК строки, которая была одной из этих 260. Документ был записан двумя неделями раньше и всё это время нёс правильный КБК.

Разделите вопросы на два вида и переместите только первый:

• о построении («какой договор», «какой налог», «какая статья ДДС») — задаются только для строк, которые действительно будут записаны;
• о состоянии («уже разнесено», «пропущено по правилу», «создано прошлым прогоном») — остаются всегда, потому что именно из них складывается читаемость арифметики §4.1.

---

6. Контрагент

6.1 Порядок поиска

1. По точному БИН/ИИН. Это единственный идентификатор, который что-то значит.
2. По точному ИИК — как подтверждение, не как основной ключ.
3. По наименованию — только как подсказка человеку. Никогда как основание для автоматического выбора.

Наименование не идентифицирует. В одной базе легко живут «ТОО Ромашка», «ТОО «Ромашка»» и «Ромашка ТОО» — иногда это три карточки одной компании, иногда три разные компании.

6.2 Что проверить у найденной карточки

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

6.3 Несколько карточек — это вопрос, а не выбор

Нашли больше одной? Посмотрите на пометку удаления, на точный ИИК, на историю проведённых документов, на договоры, на записанные правила клиента. Если после этого неоднозначность остаётся — строка получает НЕОДНОЗНАЧНЫЙ_КОНТРАГЕНТ и ждёт человека.

Не выбирайте случайно. Не объединяйте карточки. Не помечайте лишние на удаление. Слияние дублей справочника — это отдельная работа с последствиями для всей истории, и она не входит в разнесение выписки.

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

6.4 Создание карточки

Контрагента, которого в базе нет, создавать можно — но:

• нужен корректный БИН/ИИН, полное наименование и тип лица;
• нужно убедиться, что карточки с этим же идентификатором нет, в том числе помеченной на удаление;
• нужно отдельное подтверждение, если политика клиента этого требует.

Важное следствие для отчёта: ошибка, которую этот же прогон уже объявил, что исправит, — не вопрос бухгалтеру. Измерено: отчёт сказал «20 блокирующих ошибок», из которых четырнадцать (восемь контрагентов, шесть счетов) создавались бы автоматически на следующем же прогоне. Агент прочитал число буквально и сообщил клиенту, что она заблокирована. Месяц простоял три дня.

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

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

6.5 Банковский счёт

Ищется по точному ИИК и владельцу. Один ИИК у разных владельцев — НЕОДНОЗНАЧНЫЙ_БАНКОВСКИЙ_СЧЕТ, и см. §5.4: если один из владельцев — ваша организация, это почти наверняка та самая карточка-фантом.

---

7. Договор

7.1 «Договора нет» и «база не может выбрать» — разные ответы

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

Спросите базу, вместо того чтобы выводить. Измерено на одной базе: из 8 246 проведённых строк расшифровки 2 780 не несут договора вообще — и все они принадлежат тем 25 контрагентам, у которых договоров нет. И наоборот: каждая строка контрагента, у которого договоры есть, называет один из них, без единого исключения.

То есть база отвечает на этот вопрос сама, и ответ у неё есть.

7.2 «Договор» живёт в строке расшифровки, а не в шапке

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

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

Вывод шире договоров: заготовка, построенная по вашему представлению о структуре документа, проверяет ваше представление, а не документ. Сверьтесь с настоящим проведённым документом хотя бы один раз.

7.3 Порядок выбора

1. Договор, номер и дата которого названы в назначении платежа.
2. Договор, закреплённый записанным правилом клиента.
3. Единственный действующий договор нужного вида.
4. Договор из последних аналогичных проведённых операций (§2.3 — свежесть важнее пожизненной частоты).

Несколько кандидатов и основание не определено — НЕОДНОЗНАЧНЫЙ_ДОГОВОР.

7.4 Вид договора

Обычный расход поставщику — договор вида «С поставщиком». Обычный приход от покупателя — «С покупателем». Договор вида «Прочее» вместо нужного вида — только по подтверждённому правилу.

Новый договор — только по отдельному подтверждению, с проверкой владельца, организации, вида, валюты и отсутствия дубля.

7.5 Почему пустой договор дороже, чем кажется

Документ, записанный с пустым «Договором» в расшифровке, принимается по OData как успех и потом отказывается проводиться навсегда: 1С скажет «Поле "Договор" не заполнено в строке 1 списка "Расшифровка платежа"» — но скажет это только в веб-клиенте, при нажатии «Провести». По OData это будет тишина.

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

---

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

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

Рабочий набор классов:

ОПЛАТА_ПОСТАВЩИКУ · ОПЛАТА_ОТ_ПОКУПАТЕЛЯ · ВОЗВРАТ_ПОСТАВЩИКА · ВОЗВРАТ_ПОКУПАТЕЛЮ · НАЛОГ · СОЦИАЛЬНЫЙ_ПЛАТЕЖ · ЗАРПЛАТА · БАНКОВСКАЯ_КОМИССИЯ · ВНУТРЕННИЙ_ПЕРЕВОД · ВОЗВРАТ_ЗАЙМА · ПОЛУЧЕНИЕ_ЗАЙМА · ВЫДАЧА_ЗАЙМА · ВЗНОС_СОБСТВЕННИКА · ПОДОТЧЕТ · ЭКВАЙРИНГ · ПРОЧЕЕ · НЕРАСПОЗНАНО

НЕРАСПОЗНАНО — это допустимый ответ. Класс, выбранный наугад, определяет вид операции, вид документа и счета учёта; ошибка здесь ветвится во все остальные решения.

Тип документа в файле («платёжное поручение») сам по себе ничего не решает. Значение имеют направление, КНП, текст назначения и наличие списка сотрудников.

Эквайринг и собственные средства — это учётная политика, а не классификация. Как конкретный бизнес проводит перевод на карту собственника и какой контрагент стоит за платёжным агрегатором — решение, подтверждённое этим клиентом для этой базы. Следуйте схеме, уже использованной в её ранних документах, запишите её в правила клиента (§19) и никогда не переносите в другую базу.

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

---

9. Счета учёта: почему таблица — это подсказка, а не источник

9.1 Таблица маршрутизации

Разумная отправная точка для казахстанского плана счетов:

9.2 …и почему из неё нельзя писать

Эта таблица — то, что делает база «вообще». Вам нужно то, что делает эта база.

Измерено: если спросить «какие счета ставит эта база на перечислении налога» в области «вид операции», двадцать шесть проведённых документов разделятся по четырём налогам — 13, 11, 1, 1. Большинство в 13 из 26 запишет счёт обязательства другого налога в документ, который выглядит законченным.

Правильный порядок рассуждения:

1. Спросите проведённую историю этой базы, в правильной области (§2.2).
2. Требуйте единогласия. Разногласие, ничья, слишком маленькая выборка — это не ответ.
3. Если ответа нет — уберите поле, в том числе то, что положил туда более широкий шаблон. Пустое поле — то, на что бухгалтер посмотрит; правдоподобное чужое — то, на что не посмотрит.
4. Таблица §9.1 — запасной вариант для базы, которая платит этот налог впервые. Отсутствие истории не является ошибкой: такую выписку всё равно нужно импортировать.

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

9.3 Полиморфные ссылки: значение без типа — это пустая аналитика

Если поле может ссылаться на элементы разных справочников (субконто, документ-основание), у него есть парное поле типа. Значение, записанное без своего типа, читается обратно как «не определено» — то есть как пустая аналитика, и выглядит это как заполненное поле.

Поэтому такие поля переносятся парой, и считаются в прецедентах тоже парой: «(значение, тип)» как один ответ.

9.4 Имя поля, которого нет в этой конфигурации, теряет весь запрос

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

Названия полей отличаются между конфигурациями. Поле, которого в этой конфигурации нет, названное внутри перечисления читаемых полей, даёт HTTP 400 на весь запрос — не на это поле, а на всё, что вы просили рядом с ним.

Измерено дважды и независимо: на одной живой конфигурации отсутствует поле счёта расчётов по авансам, и одно его упоминание в списке полей уронило чтение целиком; на другой — на исходящем платёжном поручении отсутствует поле договора контрагента (там договор живёт в строке расшифровки, §7.2).

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

---

10. Расчёты или аванс: вопрос, который никто не задавал

10.1 Что здесь на самом деле спрашивается

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

В выписке эти два платежа выглядят абсолютно одинаково. Отличает их только то, что уже лежит в базе.

Это, вероятно, главный кандидат на роль того самого «что-то не так», которое говорят бухгалтеры: ошибка молчалива, стоит на самом частом документе, и сверка её не видит — импорт сходится 52 из 52 до тиына с каждым авансом не на том счёте.

Важно понимать, почему обычные приёмы этой страницы здесь не работают. Прецедент по виду документа (§2.1) — свойство базы, а не платежа: он одинаков для двух соседних строк одной выписки. А ответ на этот вопрос между двумя соседними строками меняется, потому что меняется остаток. Прецедент структурно не может его увидеть.

10.2 Как посчитать остаток, не имея регистров

Регистр остатков публикуется не везде, а на некоторых публикациях фильтровать его нельзя. Но остаток выводится из самих проведённых документов, и этого достаточно.

Идея: перечислите виды документов, которые двигают расчёты с контрагентом, и у каждого объявите знак:

• +1 — документ увеличивает то, что мы должны поставщику (поступление товаров и услуг);
• −1 — документ уменьшает (платёж).

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

Положительный остаток означает, что долг есть в том направлении, которое делает платёж расчётом.

Считайте только проведённые документы. Непроведённый долг не создаёт.

10.3 Разбор случаев

Последняя строка — единственная, где нужен отдельный разговор.

10.4 Платёж больше долга: разделить или отказаться

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

Если не умеет — не округляйте в одну сторону. Целиком на расчёты — это долг, закрытый на 50 000 больше, чем он есть. Целиком на аванс — это долг, который остался висеть. Оба варианта неверны, оба выглядят аккуратно.

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

10.5 Ноль на новом договоре — не доказательство того, что долга нет

Это тонкость, на которой настаивает сама бухгалтерская практика, и она делает разбивку по договорам не просто «более узкой», а опасной.

Поставщика перевели на новый договор. По новому договору остаток — ноль. Долг стоит на старом.

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

Правильное поведение: если остаток по договору равен нулю или меньше, а по контрагенту в целом долг есть — это не аванс. Это вопрос человеку: НЕОДНОЗНАЧНЫЙ_ДОГОВОР с названной суммой по контрагенту, и счёт учёта не меняется.

Перенос долга между договорами — это осознанная корректировка (Дт 3310 по старому / Кт 3310 по новому), которую делает бухгалтер. Это никогда не массовая переделка исторических поступлений — см. §14.

Практическое замечание: более широкий остаток нужно читать только тогда, когда узкий равен нулю или отрицателен. Ни в каком другом случае он не может изменить ответ, а лишнее полное чтение на медленной базе стоит минут.

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

10.6 Доказанный расчёт не пишет ничего

Контринтуитивно, но важно.

Если остаток доказал, что это расчёт, — не записывайте счёт расчётов. Он уже пришёл из проведённой истории самой базы (§2.1), возможно единогласно, возможно пустым по решению бухгалтера (§2.4). Замена выведенного из доказательств значения на константу из настроек — это обмен доказательства на догадку.

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

10.7 Недоказанный остаток не становится счётом

Причины, по которым остаток может быть не доказан, и все они означают одно и то же действие — оставить счёт как есть и написать почему:

• источники не настроены;
• чтение не полное (см. §10.8);
• ноль по договору при долге по контрагенту (§10.5);
• платёж больше долга, а документ не делится (§10.4);
• контрагент не определён вовсе.

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

Отсюда — строка отчёта и есть весь продукт этой проверки:

• «3310 (остаток по договору на 22.06.2026: 450 000,00 ₸)» — это ответ;
• «3310 (остаток не проверен)» — это тот же счёт по другой причине, и ответом не является.

Одинаковый счёт, разное происхождение. Различить их может только отчёт.

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

10.8 Сумма по неполному чтению — это неверное число

Не приблизительное. Неверное.

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

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

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

• фильтрованная страница вернулась полной — публикация могла применить собственный предел строк и ответить короткой страницей вместо ошибки;
• полное чтение не дошло до конца;
• фильтр вообще не откалиброван (см. §15.6).

10.9 Настроенный наполовину список источников делает авансом всё

Измеренная ловушка, которую невозможно поймать построчно.

Если перечислить только платежи и забыть поступления, каждый остаток окажется отрицательным и каждый платёж будет объявлен авансом. Арифметика при этом безупречна.

Построчно это неотличимо от поставщика, который действительно ещё не выставил счёт: у него тоже нет поступлений и тоже отрицательный остаток. Отличить можно только на уровне всего прогона: источник со знаком +1, у которого в базе нет ни одного документа вообще, не может увеличить долг никому — значит, он назван неверно или не опубликован.

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

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

---

11. Налоги

11.1 Какой это налог

Порядок, в котором вопрос действительно решается:

1. КБК, если он есть в файле.
2. Записанное правило клиента — сопоставление КБК или назначения с конкретным налогом (§11.3).
3. Проведённая история базы по нормализованному назначению платежа (§11.2).
4. Ничего из этого не сработало — НЕОДНОЗНАЧНЫЙ_НАЛОГ.

КНП сам по себе не определяет налог. Один КНП покрывает несколько налогов; это измерено, а не предположено.

Различайте налог, пеню и штраф — это разные строки бюджета и, как правило, разные документы.

Если КНП и КБК противоречат друг другу — это вопрос, а не выбор в пользу одного из них.

11.2 Отзыв по назначению платежа

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

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

Две детали, каждая из которых оплачена:

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

Расширение области не может дать неверный КБК: единогласие по большему количеству документов превращает ответ в отказ, но никогда не превращает отказ в неверный ответ.

11.3 Записанное решение и три его отказа

Когда ни файл, ни история не отвечают — отвечает записанное решение клиента: «КБК такой-то — это такой-то налог».

Три проверки, без которых это правило опасно:

1. Правило, не называющее налог, не применяется.
2. Имя, которого нет в справочнике базы, не применяется.
3. Элемент справочника, чей собственный КБК противоречит тому, что правило собирается записать, не применяется.

Третья — главная. Правило сопоставляется по наименованию, потому что другого идентификатора у справочника нет, а опечатка в наименовании отправит каждый будущий платёж по неверной бюджетной классификации, и ниже по течению этого не увидит никто.

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

11.4 Налоговая — это контрагент

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

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

Разница между отказом, который блокирует, и отказом, который аннотирует, — ровно в одном, и это не формулировка сообщения.

11.5 Счета и субконто на налоговом платеже

См. §9.2: область — сам налог, ответ должен быть единогласным, а отказ убирает то, что положил более широкий шаблон.

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

---

12. Списочные платежи

Пять платежей в фонды — ОПВ, ОПВР, социальные отчисления, взносы ОСМС и отчисления ОСМС — не создаются агрегированным документом без списка сотрудников.

Это не техническое ограничение, а бухгалтерское: агрегированная сумма без разбивки по людям не даёт ни персонифицированного учёта, ни возможности сверить её с начислениями.

Нет файла со списком — ОТСУТСТВУЕТ_СПИСОК. И, по §4.3, строка остаётся в плане как документ, который знает, чего ждёт. Не выбрасывайте её: пользователю нужен запрос, а не расхождение в числах.

Тройной контроль, когда список есть: сумма по списку == сумма платежа == сумма, записанная в документ. Все три, до тиына.

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

---

13. НДС

13.1 Что распознавать

«Без НДС» · «НДС не облагается» · «В том числе НДС 12% — 12 345,67» · «НДС 12% 12 345,67» · «Включая НДС 12%» · «В т.ч. НДС 12 345,67»

13.2 Правила, и почему они такие

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

Проверка вычисленного: НДС = сумма с НДС × ставка ÷ (100 + ставка). Существенное расхождение — ОШИБКА_НДС, а не молчаливое исправление в пользу одной из версий.

---

14. Период: чего нельзя касаться

Самая дорогая из измеренных ошибок, и она не про технику.

Бухгалтер попросила: «где контрагент — такой-то банк, поставь счёт организации такой-то». Правило применили без ограничения по датам. Восемьдесят один проведённый документ с ноября 2022 по июль 2026 — 155,6 млн ₸ — были распроведены и переписаны, через четыре закрытых налоговых года.

Итог, сведённый неделей позже: 51 восстановлен, 13 остались распроведёнными, 10 молчаливо неверны, 7 уничтожены полностью — их больше нет в базе.

Что из этого следует:

1. Правило корректировки, полученное от пользователя, обязано иметь период. Если пользователь его не назвал — назовите его вы, вслух, и подтвердите.
2. Закрытый период не трогается по умолчанию. Флага «можно» быть не должно: флаг ставят один раз и забывают. Если запись в закрытый период действительно нужна, границу периода нужно назвать в запросе явно, чтобы согласие, данное на один период, нельзя было потратить на другой.
3. Распроведение — то, что делает ущерб поправимым; повторное проведение — то, что уничтожает улики. Пока повреждённые документы лежат распроведёнными, их видно. Как только один из них перепроводят, не исправив, он становится побайтово неотличим от законного, и найти его нельзя ничем.
4. Откат, ключом которого является «документы, которых коснулся этот прогон», небезопасен, если ущерб от более раннего прогона сделал ранее существовавшие документы похожими на его продукт. Единственная надёжная опора — снимок «до», сделанный самим прогоном.
5. Вопрос об откате должен предлагать область, и ответ на него нужно перечитать. В одном случае бухгалтеру предложили несколько вариантов, она выбрала один, второй остался невыбранным молча — и переписанные счета не были возвращены. Этого не заметили неделю.

И общее: если бухгалтер настаивает на правиле, которое вы считаете неверным, — примените его, но с периодом, и повторите вслух, что именно вы считаете неверным. В том измеренном случае агент сказал правильную вещь заранее, был переспорен и выполнил указание, не переспросив про область дат.

Ещё один вывод того же случая, менее очевидный: правило вида «где X, поставь Y» почти всегда неверно в принципе, а не только по области. «Банк как контрагент» в том случае означал зарплатные переводы на карты сотрудников, которые штатно платятся с другого счёта. Прежде чем применять массовое правило, проверьте на трёх документах, что оно означает то, что вы думаете.

---

15. Запись: девять способов, которыми 1С говорит «нет»

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

15.1 Таблица классов

Ни один из этих случаев OData не называет. Все они найдены попыткой.

15.2 «Не удалось записать» — три причины, и «проверьте права» обычно неверная

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

Как различить: запишите в объект значение, которое в нём уже стоит.

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

15.3 Права на запись проверяются до планирования, а не после

Учётная запись, которая может создавать документы, но не может их изменять, превращает каждое исправление в дубль. Измеренный случай: 52 строки выписки стали 86–95 живыми документами, потому что на каждую правку агент создавал замену и оставлял оригинал жить. Плюс уверенное объяснение «это стандартное ограничение OData в 1С», которого не существует.

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

15.4 Перечитывать обязательно, и по полям

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

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

Не создавайте исправленную копию поверх ошибочного документа. Это §15.3 в действии.

15.5 Некоторые поля пишутся только при создании

Ряд полей конфигурация принимает при INSERT и отказывает при UPDATE. Документ, созданный без такого поля, починить нельзя — его можно только пересоздать: создать новый без ссылки-основания, пометить старый на удаление, затем связать.

Отсюда следствие для порядка действий: выясните, какие поля вашей конфигурации доступны только при создании, до того как создадите шестьдесят документов, а не после.

15.6 Ноль, которому нельзя верить

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

Измерено на одной публикации: поиск подстроки с кириллическим литералом возвращает ноль строк для документа, который заведомо есть в базе — проверено на проведённом документе, найденном по его же собственному назначению платежа. Фильтр по дате на той же базе отклоняется вслух. На другой платформе фильтр по полю документа отклоняется как HTTP 200 с HTML-страницей — редиректом на портал хостинг-провайдера, а не ошибкой.

Что из этого следует практически: прежде чем поверить нулю от узкого запроса, докажите, что фильтр на этой базе вообще работает.

Калибровка — три запроса:

1. прочитайте страницу без фильтра, чтобы получить значение, которое база точно несёт;
2. попросите отфильтровать ровно по этому значению. Пусто — фильтр доказанно лжёт: вы держите в руках строку, которую он не вернул;
3. попросите значение, которого не может быть ни у кого. Строки в ответе — фильтр игнорируется, и вам вернули чужие данные.

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

Выход, когда фильтру верить нельзя: прочитать набор целиком и сопоставить у себя. Это исчерпывающе по построению и не требует от сервера ничего. Цена: полное чтение — от долей секунды на маленькой базе до сорока пяти минут на большой, поэтому читайте один раз за прогон и держите результат (§2.5).

---

16. Проведение

16.1 Проведение — отдельное решение

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

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

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

16.2 Posted=true успехом не является

Самое важное предложение этого раздела.

1С отвечает на отказ в проведении HTTP 200 с пустым телом, оставляя Posted истинным. Статус не несёт информации вообще. Измерено: документы, проведённые по OData, → Posted=true и ноль движений по всем девяноста опубликованным регистрам; соседний документ, проведённый бухгалтером в клиенте, → четыре движения. Та же база, тот же пользователь, тот же вид документа, ноль различий по сорока двум полям шапки.

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

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

Никогда не отправляйте параметр оперативного режима проведения: он отвечает 200 и оставляет Posted ложным — полный no-op, отчитавшийся успехом.

16.3 Когда документ не двигает регистры

Причина почти всегда в самом документе, а не в канале: проведение по OData проводит корректный документ правильно. Что теряется — это причина отказа.

Откройте документ в веб-клиенте 1С и нажмите «Провести». Панель сообщений напечатает то, чего не несёт OData: «Не совпадают сумма документа и её расшифровка», «Поле "Договор" не заполнено в строке 1 списка "Расшифровка платежа"», «Укажите основной банковский счёт в реквизитах организации». Это и есть список того, что нужно исправить.

Типичные причины: строка табличной части присутствует, но пуста (нулевая сумма, нулевой идентификатор); итог шапки не равен сумме строк; не заполнены настройки организации; на закупке с НДС не выставлен признак учёта НДС — последнее особенно коварно, потому что документ выглядит полностью корректным.

16.4 Цена проверки, и почему её надо назвать заранее

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

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

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

---

17. Статусы строки

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

Два статуса стоит выделить.

ПРОВЕДЕНИЕ_БЕЗ_ДВИЖЕНИЙ существует потому, что 1С отвечает успехом. Без отдельного статуса такая строка неотличима от СОЗДАНО_И_ПРОВЕДЕНО.

СЧЕТ_УЧЕТА_НЕ_ОПРЕДЕЛЕН — это не сбой. Это отчёт о том, что база не дала единогласного ответа, и правильное действие — оставить поле пустым.

---

18. Что должен доказать итоговый отчёт

Отчёт — это не журнал. Это доказательство, и его читают в определённом порядке.

18.1 Первая строка — арифметика

записано + уже существует + пропущено == всего строк

по количеству и по сумме, до тиына. Читатель должен увидеть это раньше всего.

18.2 Дальше — тождества

• каждая строка выписки сопоставлена ровно с одним документом либо несёт объяснённый блокирующий статус;
• нет пропусков и нет дублей;
• сумма приходных документов == приход по выписке;
• сумма расходных документов == расход по выписке;
• обороты по банковскому счёту в базе соответствуют выписке;
• конечный остаток соответствует банку;
• каждый проведённый документ имеет подтверждённые движения;
• счета учёта соответствуют тому, что было решено, и у каждого названо происхождение;
• по поставщикам проверено разделение 3310 / 1710, по покупателям — 1210 / 3510.

18.3 Потом — таблицы

Таблица операций: контрагент, БИН/ИИН, сумма, документ, договор, дебет, кредит, НДС, статус.

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

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

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

Итог: ЗАВЕРШЕНО или НЕ ЗАВЕРШЕНО. Сверка не сошлась — НЕ ЗАВЕРШЕНО, независимо от того, сколько документов создано.

18.4 Прогон говорит, где он находится

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

Пишите строку на документ во время записи и строку на страницу во время чтения.

---

19. Правила клиента: как перестать спрашивать одно и то же

Каждый ответ, полученный от пользователя, — это правило, а не реплика в разговоре.

Записывайте его в карточку клиента с тремя вещами: что решено, когда и откуда взято (кто ответил). В следующий раз не спрашивайте — примените и скажите в отчёте, что применили записанное правило от такого-то числа.

Что сюда попадает: чем считать поступления от агрегатора; куда относить перевод на карту собственника; какой договор у контрагента, у которого их несколько; какой налог соответствует какому КБК; какие строки не разносятся из выписки вообще.

Два свойства, без которых это вредно:

• Записанное правило должно читаться. Одиннадцать записанных решений о пропуске пролежали без единого чтения (§5.5). Ненужное правило хуже отсутствия правила: оно создаёт ложную уверенность, что решение учтено.
• Устаревшее правило должно отказывать, а не тихо откатываться назад. Правило, указывающее на элемент, которого больше нет, обязано сообщить об этом как о неразрешённом поиске. Тихий откат к той самой неоднозначности, ради которой правило и писали, превращает правило в комментарий.

И граница: правило одного клиента не переносится в базу другого. Никогда, ни при каких обстоятельствах.

---

20. Когда остановиться

Останавливайтесь и спрашивайте при:

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

Во всех остальных случаях — работайте. Отказ, который блокирует законную работу, учит человека обходить контроль, и тогда нет ни контроля, ни видимости. Это не риторика: остановленный на три дня месячный импорт из-за четырнадцати самоустраняющихся ошибок — измеренный случай (§6.4).

Как формулировать вопрос:

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

---

21. Чего этот документ гарантировать не может

Честный раздел, и он важнее остальных для того, кто решает, чему доверять.

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

Отсюда следует граница, которую эта страница провести обязана:

• Рассуждение — то, что документ несёт хорошо. Какие вопросы задать базе, в какой области считать прецеденты, чем отличается ноль от «не знаю», почему пустое поле лучше правдоподобного, когда отказ — правильный ответ. Здесь текст сильнее кода: он объясняет, а код только исполняет.
• Безопасность записи — то, чего документ не несёт никак. Идемпотентность, граница закрытого периода, проверка организации, обязательное перечитывание, «движения, а не флаг» — это свойства, которые должны быть невозможно нарушить, а не «описаны в инструкции». Правило, которое можно не выполнить, при достаточном количестве прогонов не выполняется.

Практический вывод для того, кто это читает: считайте разделы 1–14 и 17–20 руководством к рассуждению, а разделы 15–16 — описанием того, что должно проверяться механизмом, а не вашим вниманием. Если механизма нет, выполняйте эти проверки вручную и в отчёте пишите прямо, что они выполнены вручную.

И последнее, что стоит держать в голове весь прогон:

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

---

Приложение А. Одна выписка целиком

Восемь строк — по одной на каждый класс рассуждения этой страницы. Данные вымышленные, ситуации настоящие.

Шапка выписки. ТОО «Пример», счёт KZ..1030, период 22–30.06.2026. Начальный остаток 730 112,68 ₸, приход 1 665 607,00 ₸, расход 1 909 271,62 ₸, конечный остаток 486 448,06 ₸.

Сначала §4.2: 730 112,68 + 1 665 607,00 − 1 909 271,62 = 486 448,06. Сходится. Идём дальше.

Затем §1: РасчСчет выписки совпадает с настроенным; организация в базе есть, БИН совпадает; счёт принадлежит ей. Идём дальше.

---

Строка 1 — 22.06, расход 500 000,00, «ТОО Поставщик А», КНП 710

Классификация: ОПЛАТА_ПОСТАВЩИКУ.

Подпись строки собрана. Ищем её в базе — находим: документ №00000000649, созданный прошлым прогоном 24.06.

Ответ: НАЙДЕН_СУЩЕСТВУЮЩИЙ_ДОКУМЕНТ. Ничего не создаём, считаем в тождество §4.1 как «уже существует».

Обратите внимание, чего мы не делаем: не задаём вопросов про договор, счёт учёта или остаток (§5.6). Строка не будет записана, значит вопросы о том, как её записать, — шум.

---

Строка 2 — 23.06, расход 180 000,00, «ТОО Поставщик Б», КНП 710

Подписи в базе нет. Проверяем §5.2 — дата+сумма+контрагент+наш счёт: совпадений нет. Строка новая.

Контрагент по БИН — одна живая карточка, элемент, не группа. Хорошо.

Договор: у контрагента их два. Назначение платежа номера договора не называет. Записанного правила нет. Смотрим прецедент (§7.2 — в строках расшифровки, не в шапке): за всю историю договор №1 в 12 случаях, договор №2 в 7. Тонкое большинство → переспрашиваем последние двадцать (§2.3): 19 из 20 — договор №1. Чистый недавний ответ.

Договор №1, происхождение — «19 из 20 последних проведённых».

Остаток (§10.2): поступления 640 000,00, платежи 460 000,00 → долг 180 000,00 на 23.06. Платёж ровно 180 000,00.

Расчёты, ровно закрывает. Счёт расчётов не пишем (§10.6) — он и так придёт из истории базы. В отчёте: «3310 (остаток по договору на 23.06.2026: 180 000,00 ₸)».

СОЗДАНО_НЕПРОВЕДЕНО.

---

Строка 3 — 24.06, расход 250 000,00, «ТОО Поставщик В», КНП 710

Остаток по контрагенту: поступлений нет вовсе, платежей нет. 0,00.

Договоров у контрагента тоже нет — и по §7.1 это не неоднозначность: спрашиваем базу, и она отвечает, что у контрагентов без договоров строки расшифровки договор не несут. Значит, пустой договор здесь законен.

Аванс. Счёт аванса записываем — это единственное, что §10.6 разрешает писать. В отчёте: «1710 (аванс — задолженности нет на 24.06.2026)».

СОЗДАНО_НЕПРОВЕДЕНО.

---

Строка 4 — 25.06, расход 500 000,00, «ТОО Поставщик Г», КНП 710

Остаток по договору, который назван в назначении: 0,00.

Но §10.5: проверяем остаток по контрагенту целиком — 800 000,00. Долг стоит на старом договоре, а платёж назвал новый.

Не аванс. НЕОДНОЗНАЧНЫЙ_ДОГОВОР, счёт учёта не меняем, в отчёте: «по договору №2 задолженности нет, но по контрагенту в целом числится 800 000,00 ₸ — долг может стоять на другом договоре; счёт учёта не изменён».

Документ всё равно создаётся (§10.7 — проверка никогда не блокирует строку). Просто счёт остался тем, что дала история базы, и об этом написано.

---

Строка 5 — 26.06, расход 620 000,00, «ТОО Поставщик Б», КНП 710

Тот же контрагент, что в строке 2. Долг на 26.06: 180 000,00 − 180 000,00 (строка 2 уже учтена, если документ проведён) … и здесь важная деталь: строка 2 создана непроведённой, а §10.2 считает только проведённые. Значит долг на 26.06 всё ещё 180 000,00.

Платёж 620 000,00 больше долга. Разложение: 180 000,00 — расчёты, 440 000,00 — аванс.

Конфигурация этой базы обе суммы в одном документе нести не умеет.

СЧЕТ_УЧЕТА_НЕ_ОПРЕДЕЛЕН (§10.4): счёт не меняем, в отчёте — обе половины с суммами. Округлить в одну сторону было бы аккуратно выглядящей ошибкой в одном из двух регистров.

---

Строка 6 — 27.06, расход 185 000,00, «ТОО Поставщик Д»

Строка 7 — 27.06, расход 185 000,00, «ТОО Поставщик Д»

Две одинаковые строки в один день на одну сумму одному контрагенту.

Это два настоящих платежа, а не дубль. Различают их банковские референции — и именно поэтому референция входит в подпись строки (§3.4). Подпись без неё склеила бы их, и вторая была бы объявлена дублем первой, то есть потеряна.

Обе → СОЗДАНО_НЕПРОВЕДЕНО.

---

Строка 8 — 30.06, расход 274 271,62, «ТОО Пример», ИИК KZ..1040

Наименование и БИН совпадают с нашей организацией. KZ..1040 — наш второй счёт.

Проверяем §5.4: счётом владеет наша организация — значит он наш, сколько бы карточек ни несли его номер. Это ВНУТРЕННИЙ_ПЕРЕВОД.

Ищем по паре счетов как по множеству, по всем типам документов (§5.3): находим «Платёжный ордер» от 30.06 — база разнесла эту операцию из выписки второго счёта неделю назад.

НАЙДЕН_СУЩЕСТВУЮЩИЙ_ДОКУМЕНТ. Это не ошибка и никогда ей не станет.

И не создаём карточку контрагента «ТОО Пример» (§5.4, третья ловушка) — иначе следующий прогон поверит ей.

---

Что печатает отчёт

СВЕРКА
  создано              5   1 909 271,62 − 774 271,62 = 1 135 000,00
  уже существует       3                                 774 271,62
  пропущено            0                                       0,00
  ────────────────────────────────────────────────────────────────
  итого                8                               1 909 271,62
  по выписке           8                               1 909 271,62
  расхождение          0                                       0,00   ✔

СЧЕТА УЧЁТА
  расчёты (3310)       1   подтверждено остатком
  аванс   (1710)       1   подтверждено остатком
  не изменено          3   см. вопросы ниже

ТРЕБУЮТ РЕШЕНИЯ                                                    2
  стр. 4  Поставщик Г   500 000,00   долг может стоять на другом договоре
                                      (по контрагенту 800 000,00 ₸)
  стр. 5  Поставщик Б   620 000,00   180 000,00 расчёты + 440 000,00 аванс,
                                      документ не делит — счёт не изменён

ЖУРНАЛ РЕШЕНИЙ
  стр. 2  договор №1    19 из 20 последних проведённых документов
  стр. 3  договор пуст  у контрагентов без договоров база их не заполняет
                        (2 780 из 8 246 строк расшифровки)

ИТОГ: НЕ ЗАВЕРШЕНО — 2 строки ждут решения

Три вещи, которые делает этот отчёт и которые стоит скопировать.

Арифметика стоит первой и сходится до тиына. Читатель узнаёт это раньше, чем что-либо ещё.

«Не изменено — 3» — это не молчание. Три документа получили счёт из истории базы, и про каждый написано почему.

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