Реализации по счетам покупателям в 1С

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

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

Документ-основание — это и есть идентичность

Реализация, созданная по счету, несет ДокументОснование — Ref_Key счета — и ДокументОснование_Type (StandardODATA.Document_СчетНаОплатуПокупателю). Эта пара и есть ключ дубля. Не номер, не сумма, не пара «контрагент + дата».

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

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

Два источника реквизитов, и они не взаимозаменяемы

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

Не выбирайте ссылку потому, что название похоже. Каждая записываемая ссылка должна существовать в этой базе и относиться к организации документа. См. правила OData §5 и §11.

Сборка payload

Возьмите образец и уберите из него то, чем владеет 1С, и то, что принадлежит образцу, а не вашему документу:

• Ref_Key, DataVersion, Number — их назначает сервер.
• все ключи с суффиксами @navigationLinkUrl и @associationLinkUrl, а также metadata-ключи. Это артефакты чтения; отправленные обратно, они в лучшем случае игнорируются, в худшем дают 400.

Далее:

• Передайте пустые табличные части, которых требует объект — обычно Товары, НомераГТД, УчастникиСовместнойДеятельности — как []. Не передать обязательную часть и передать её пустой — не одно и то же.
• Пронумеруйте строки Услуги последовательным LineNumber с единицы. Строки без него могут сохраниться в порядке, который вы не выбирали.
• Любая табличная часть передается внутри POST самого документа. Через собственный entity set строки не создаются.
• Сверьте по каждой строке: количество × цена = сумма, ставку НДС, сумму НДС, и сумму строк против итога шапки.

Posted = false, DeletionMark = false и комментарий о происхождении черновика — как и во всём остальном, что пишет кит.

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

Только по прямой команде пользователя и только через OData-действие Post(). Запись поля Posted — это не проведение, а флаг на документе, чьи регистры не двигались. См. правила OData §7.

Неудачное проведение — это остановиться и сообщить, а не повторить. 2026-08-04 Post() по одной реализации вернул Не удалось провести "Реализация ТМЗ и услуг 00000000269 …", документ не изменился. Это отказ учетной логики 1С, и лечится он в 1С — бухгалтером, который прочитает журнал регистрации, — а не другим payload.

Проверять чтением

Перечитайте каждый созданный документ по Ref_Key и сверьте с посчитанным: ссылку на основание и её тип, организацию, контрагента, договор, число строк, в каждой строке номенклатуру, количество, цену, сумму и НДС, итог шапки и Posted = false.

Затем сделайте сверку, которую поштучная проверка сделать не может: ровно одна реализация на каждый исходный счет и ни одного счета без неё. Отдельно укажите, сколько счетов пропущено из-за уже существующей реализации, и сколько создано. HTTP 2xx — не доказательство, см. правила OData §9.

ЭАВР — электронный акт выполненных работ

ЭАВР — это отдельный документ 1С: Document_ЭлектронныйАктВыполненныхРабот, связанный со своей реализацией через ДокументОснование и ДокументОснование_Type. Не печатная форма и не представление реализации.

Неопубликованный объект неотличим от неиспользуемого

Прежде чем заключить, что база не использует какой-то тип документа, установите, что этот тип опубликован в OData. 1С публикует объекты в OData-интерфейс по одной галочке, и неопубликованный объект просто отсутствует в $metadata — без ошибки, без пустой коллекции, без единого признака.

2026-08-04 это стоило половины рабочего дня. База отдавала 687 наборов и никакого объекта ЭАВР — это читалось как «в этой конфигурации ЭАВР не ведут». Галочку включили; наборов стало 692, и 1 106 ЭАВР оказались доступны — они лежали там всё время.

Поэтому, когда ожидаемого типа документа нет:

python3 scripts/1c/realization/check-eavr.py

Скрипт сообщает, опубликован ли объект, сколько ЭАВР в базе и какова местная конвенция нумерации, — либо говорит, что следующий шаг — галочка публикации. «Не опубликовано» и «не используется» требуют разных действий, и только одно из них ваше.

СпособВыпискиАктовВыполненныхРабот — это способ, а не акт

Поле реализации СпособВыпискиАктовВыполненныхРабот задает, как выписывать акты: на бумаге, через портал госзакупок или НаПорталеИСЭСФ. Значение НаПорталеИСЭСФ не создает ничего.

Это стоит сказать прямо, потому что данные говорят обратное. В той базе 849 из 1 013 сопоставимых проведенных реализаций несли НаПорталеИСЭСФ, и все реализации с видимым ЭАВР несли его тоже. Поле коррелирует с актом, потому что и то и другое ставят одни и те же бухгалтеры, — но не создает его.

Реализация не «сделана с ЭАВР» из-за заполненного поля. Подтверждайте акт записью ЭАВР, у которой ДокументОснование — эта реализация, и читайте её Статус и Состояние.

Номер берется у основания

В той базе 99% исходящих ЭАВР несут тот же номер, что и реализация: 212 из 214 подтвержденных, 5 из 5 черновиков, 37 из 37 ошибочных. Берите номер у реализации- основания и проверяйте его после записи.

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

Начальное состояние черновика и то, что никогда не берется из образца

Подтверждено по пяти существующим черновикам той базы:

Никогда не копируйте из подтвержденного образца: регистрационный номер, идентификатор, подписи, статус и состояние. Локальный черновик с AKT-… и ПодтвержденПолучателем утверждает регистрацию на портале, которой не было, на документе, который никто не подписывал.

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

Суммы строк зависят от флагов НДС базы

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

В OData нет «создать на основании»

Для ЭАВР 1С публикует только действия Post и Unpost. Серверного «заполнить по реализации» нет, payload собирается вручную — именно поэтому правила по полям выше не факультативны.

Известный блокер: ОбработкаЗаполнения отклоняет создание

Создание ЭАВР через OData сейчас не работает, и create-eavr.py в ките — это сухой прогон без --apply.

POST по полностью проверенному payload — девять актов, чистый dry-run, суммы сходятся, дубли исключены — вернул:

HTTP 500: Ошибка при выполнении обработчика «ОбработкаЗаполнения»

Установлено: документ не создан (повторное чтение не нашло ничего); частичной записи не было; это не ошибка прав. Наиболее вероятная непроверенная причина — непроведенные реализации-основания: обработчик конфигурации может требовать проведенное основание.

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

До тех пор ЭАВР делается в 1С — вами или бухгалтером.