Plank help · updated 2026-09-16
Готовые скрипты для 1С
Готовый и адаптируемый Python для работы с 1С через OData — проверка доступа, загрузка банковской выписки с обязательным dry-run, защита от дублей и пять платежей в фонды со списками сотрудников. Скачайте в любое пространство вместо того, чтобы писать заново.
Agents: fetch the raw markdown of this page at /ru/help/1c-starter-kit.md
Готовые скрипты для 1С
Прежде чем писать скрипт для 1С, проверьте, не написан ли он уже. Это рабочий Python для того, что нужно любой интеграции с 1С, и он предназначен для адаптации. Писать своё с нуля — дорогой путь: одна бухгалтерская практика потратила на это три дня и 86% всего своего бюджета на ИИ, а та же операция стала выполняться в 4,5 раза быстрее, как только скрипты появились.
Установлен ли он уже?
ls scripts/1c/
Если видите odata/ и bank-statement/ — всё на месте, читайте
scripts/1c/README.md и адаптируйте. Если нет — установите.
Установка
Скачайте файлы. Не перепечатывайте их: манифест перечисляет всё, каждый файл отдаётся как есть.
BASE=https://plank.md/help/kits
for KIT in $(curl -fsS "$BASE/1c-bank-statement-kz/manifest.json" | jq -r '.installOrder[]'); do
curl -fsS "$BASE/$KIT/manifest.json" | jq -r '.files[].path' | while read -r p; do
[ -e "$p" ] && continue
mkdir -p "$(dirname "$p")"
curl -fsS "$BASE/$KIT/files/$p" -o "$p"
done
done
installOrder — это замыкание зависимостей, поэтому вместе с набором для
выписки скачивается и общее ядро. Запускайте из корня пространства.
Затем учётные данные и проверка связи:
cp scripts/1c/credentials.example.json scripts/1c/credentials.json
# заполните base_url, username, password — это единственное место, где живёт пароль
python3 scripts/1c/odata/check-access.py
Обновление уже установленного набора
Никогда не запускайте установку поверх существующей scripts/1c/ и не
заменяйте файл только потому, что он отличается от опубликованного. Цикл
выше пропускает существующие файлы именно поэтому. Отличающийся файл может
быть устаревшим, а может содержать правила этой компании: 15.09.2026 помощник
скопировал 44 опубликованных файла поверх пространства, где _classify.py,
_statement.py и import-statement.py были доработаны под компанию, и
четыре её доработки — и 90 из 142 её тестов — пропали без копии, из которой их
можно было бы восстановить.
Сравните sha256 с $BASE/<набор>/manifest.json и поступите с каждым файлом
по его состоянию:
- Отсутствует — добавьте.
- Совпадает — ничего не делайте.
- Отличается — сначала скопируйте текущий файл в
synced_data/1c/_кит-до-обновления-<ГГГГ-ММ-ДД>/<тот же путь>. Затем прочитайте различия и перенесите изменения опубликованной версии в файл пространства, сохранив все местные правила. Если не можете понять, какие строки местные, не трогайте файл и скажите об этом. mapping.json,credentials.json— обновление их никогда не пишет.
Если в пространстве есть свои тесты (synced_data/1c-tests/ или
scripts/1c/tests/), запустите их до и после: тест, который был зелёным и
стал красным, — это местная возможность, которую обновление удалило. Сначала
обновляйте 1c-core, потом зависящие от него наборы; перед любым
--apply — пробный прогон.
Что внутри
Шесть наборов. 1c-core универсально и от него зависят все остальные; каждый
остальной — одна операция в одной юрисдикции.
1c-core → scripts/1c/odata/
| Файл | Что делает |
|---|---|
check-access.py | Проверка доступа из правил OData §2. Только чтение. |
_odata.py | Клиент: авторизация, постраничное чтение, $metadata, перечисления, очистка служебных полей. Не проводит, не изменяет, не удаляет. |
_catalogs.py | Сопоставление по идентификатору — БИН/ИИН, ИИК с проверкой владельца, ИИН. |
_signature.py | Составная подпись документа — повторный запуск ничего не создаёт. |
_documents.py | Создание непроведённых документов, строки внутри POST родителя, перечитывание после записи. Плюс correct() — единственный путь правки на месте, с проверкой, что документ несёт именно названный якорь, принадлежит закреплённой организации и остаётся непроведённым черновиком. |
correct-document.py | Точка входа для correct(). По умолчанию сухой прогон; запись — с --apply; по одному --set Поле=значение. Без него путь исправления существовал только как функция, которую никто не вызывал. |
find-runs.py | Только чтение. Перечисляет запуски импорта в базе и все документы каждого — в пределах закреплённой организации — чтобы уборка касалась одного запуска, а не всех импортов, которые база когда-либо получала. |
_runner.py | Механика dry-run и правило «ошибка блокирует, предупреждение — нет». |
Плюс два файла в самом scripts/1c/, уровнем выше odata/:
| Файл | Что делает |
|---|---|
mapping.json | Всё, что различается между базами. Адаптация начинается здесь. |
credentials.example.json | Копируется в credentials.json — единственное место, где живёт пароль. |
1c-bank-statement-kz → scripts/1c/bank-statement/
Реализация регламента разноски выписки.
| Файл | Что делает |
|---|---|
parse-statement.py | Разбирает выписку, проверяет арифметику §5, классифицирует строки. Без учётных данных и без сети. |
import-statement.py | Загрузка. По умолчанию dry-run; запись — только с --apply. |
reconcile.py | Независимая сверка: каждая строка отражена один раз и нужным видом документа. |
_employee_lists.py | Разбор файла со списком и распознаватели пяти платежей. |
_classify.py | Классификация §8, налоги §10, пени §11. |
_kz_codes.py | Таблицы КНП, КБК и элементов фондов. Только данные. |
1c-reconciliation-act-kz → scripts/1c/reconciliation-act/
Один «Акт сверки взаиморасчётов» на контрагента и период, реализация правил актов сверки.
| Файл | Что делает |
|---|---|
create-act.py | Собирает один акт как непроведённый черновик. По умолчанию dry-run; запись — с --apply. |
check-direction.py | Только чтение. Читает собственные проведённые акты базы и печатает готовый блок document_sides — или объясняет, почему данных недостаточно. |
_act.py | Правила чистыми функциями — начальное сальдо, обе таблицы, правило договора, payload. Без сети, поэтому проверяемо тестами. |
Скрипт не запустится, пока вы не объявите направление дебета и кредита в
reconciliation_act.document_sides файла mapping.json. Это не формальность:
неверное направление даёт акт, который читается безупречно и утверждает обратное
сальдо, и его действительно легко перепутать: работа одного дня уже давала скрипт и
заметку с противоположными ответами. Прочитайте собственные свежие акты этой базы и
запишите, как в них на самом деле.
Он также отказывается, если находит в базе тип расчётов без объявленного направления, — и это настоящая проверка только потому, что типы определяются по базе, а не по той настройке, которую он проверяет. И колонку контрагента он оставляет пустой, пока человек не подтвердит, что тот отразил те же операции: зеркальное копирование своих же строк с отметкой «Сверка согласована» утверждает подтверждение, которого никто не давал, — на документе, который вы ему отправите.
1c-esf-import-kz → scripts/1c/esf/
Входящие электронные счета-фактуры, реализация правил загрузки ЭСФ.
| Файл | Что делает |
|---|---|
import-esf.py | Одна ЭСФ (или первые N) → связанные непроведённые счёт-фактура и поступление. По умолчанию dry-run; запись — с --apply. |
fill-esf-units.py | Заполняет пустые «Ед. изм.» и «Ед. изм. остатков», с которыми ЭСФ приходит с портала. По умолчанию dry-run; запись — с --apply. |
_esf.py | Правила чистыми функциями — построчная арифметика, порядок разрешения, оба payload, проверка трёх связей. Без сети. |
_units.py | Правило единиц чистыми функциями — сначала карточка, затем упаковка по названию, иначе ручная проверка. Без сети. |
_nomenclature.py | Создание карточки номенклатуры для строки, которой ничего не соответствует, под --create-nomenclature: ключ идентичности, выведенный флаг Услуга, полезная нагрузка и перечитывание. Чистое, кроме самой записи. |
fill-esf-units.py заполняет единицу по праву карточки номенклатуры или не
заполняет вовсе: сначала базовая единица из карточки, затем готовая фармацевтическая
упаковка по названию, а весовой товар, розлив и коэффициент не 1 уходят в список
ручной проверки с причиной. Отчёт всегда состоит из трёх списков — заполнено, уже было
заполнено, требует человека, — потому что прогон, заполнивший всё и не отметивший
ничего, угадал: записанная единица неотличима от проверенной, а меняет смысл каждого
количества в строке.
Он записывает все три связи, включая СчетФактура у самой ЭСФ: без неё ЭСФ, у
которой есть и счёт-фактура, и поступление, всё равно читается в 1С как
необработанная. Он отказывается угадывать товар (похожее название — не совпадение),
создаёт карточку справочника только с --create-nomenclature и не берёт ЭСФ, которую
1С уже считает обработанной.
С этим флагом пробный прогон сначала перечисляет каждую карточку, которую создаст, и
строку ЭСФ, из которой она взялась. Ключ карточки — GTIN, затем код Нацкаталога, затем
точное полное наименование: две ЭСФ на один товар дают одну карточку, а повторный
прогон месяца — ни одной. Полное наименование хранится в НаименованиеПолное, потому
что Description 1С обрезает. Услуга это или товар, берётся из проведённой истории
этого же поставщика, а если история молчит или противоречива — строка отклоняется, а не
угадывается. Каждая карточка перечитывается после записи, и все они названы в отчёте.
1c-sales-realization-kz → scripts/1c/realization/
Счета покупателям в черновики реализаций и вопрос ЭАВР, реализация правил по реализациям.
| Файл | Что делает |
|---|---|
create-realizations.py | По одной реализации на каждый счёт, у которого её нет. По умолчанию dry-run; запись — с --apply. |
check-eavr.py | Только чтение. Опубликован ли ЭАВР в OData, сколько их, нумерует ли база акты по реализации и сколько реализаций несут портальный способ выписки без акта. |
_realization.py | Правила чистыми функциями — пара основания, выбор образца, payload, арифметика НДС, проверка. Без сети. |
create-eavr.py | Только сухой прогон. --apply нет — см. ниже. |
Идентичность реализации, построенной по счёту, — это пара
(ДокументОснование, ДокументОснование_Type), и кит перепроверяет её
непосредственно перед каждым POST, а не один раз на пачку. Реквизиты сделки
берутся из счёта; вид операции, подразделение, счета учёта и номенклатурная группа —
из проведённой реализации той же организации. Нет образца — счёт отклоняется, а
не пишется с догадками.
create-eavr.py не умеет писать намеренно. Полностью проверенный POST ЭАВР
отклоняется обработчиком конфигурации ОбработкаЗаполнения с HTTP 500 ещё до
появления документа, а внутренний текст ошибки есть только в журнале регистрации 1С.
Писатель, который перебирает payload против непрочитанного обработчика, даст неверный
документ на форме, которая уходит контрагенту.
Запускайте check-eavr.py до любых выводов про ЭАВР. Неопубликованный в OData
объект отсутствует в $metadata ровно так же, как объект, которого в конфигурации
нет: 2026-08-04 эта неоднозначность стоила половины дня — галочка публикации
превратила 687 наборов в 692 и открыла 1 106 актов, лежавших там всё время.
1c-payroll-kz → scripts/1c/payroll/
Один месяц зарплаты как четыре черновика, реализация правил начисления зарплаты.
| Файл | Что делает |
|---|---|
check-payroll.py | Только чтение. Какие из четырёх документов есть по месяцам, дубли, охват по документам и все строки отражения с пустой «Статьёй расходов». |
create-payroll.py | Собирает месяц по проверенному проведённому месяцу. По умолчанию dry-run; запись — с --apply. |
_payroll.py | Правила чистыми функциями — период, ключ дубля, перенос строк, проверка статьи расходов, верификация. Без сети. |
Он не считает зарплату. Ставки, пределы и производственный календарь — это
регулирование, которое меняется в том числе среди года, и скрипт с зашитыми порогами
этого года в январе молча подаст прошлогодние числа. Суммы переносятся из исходного
месяца, полностью печатаются в сухом прогоне и удерживаются за --accept-warnings,
чтобы их кто-то прочитал.
Два правила он всё же обеспечивает. Между четырьмя документами нет
ДокументОснование, поэтому ключ дубля — организация + ПериодРегистрации +
физлицо и ничего больше: второй «Расчет СН и СО» за месяц — это двойные налоги, и 1С
не возразит. И он отказывается писать отражение с пустой «Статьёй расходов»:
именно этот дефект дошёл до живого бухгалтера 2026-08-04 на черновиках, верных во
всём остальном.
Порядок запуска
python3 scripts/1c/bank-statement/parse-statement.py statement.txt --lists ./lists
python3 scripts/1c/odata/check-access.py
python3 scripts/1c/bank-statement/import-statement.py statement.txt --lists ./lists
python3 scripts/1c/bank-statement/import-statement.py statement.txt --lists ./lists --apply
python3 scripts/1c/bank-statement/reconcile.py statement.txt --report synced_data/1c/june.md
Чего скрипты не сделают
Это заложено в код, а не в советы. Если что-то из этого вас останавливает — нужно устранить причину, а не обойти скрипт.
- Запись без
--apply. По умолчанию — dry-run. - Запись в ненастроенную базу.
--applyне запустится, пока вmapping.jsonне указаны организация и её расчётный счёт. - Продолжение после ошибки. Одна ошибка сопоставления блокирует запись.
Предупреждения тоже останавливают и снимаются только флагом
--accept-warningsпосле показа пользователю. Два из них —index-gapиidentical-rows-undecided, где принятие может записать одни и те же деньги дважды, — этим флагом не снимаются: каждому нужен свой--accept-warning <код>. Строка «Held» печатает нужный флаг для каждого кода. - Создание записи в справочнике. Идентификатор, который ничего не нашёл, — это вопрос пользователю; нашедший две записи — решение, а не совпадение.
- Проведение. Документы создаются с
Posted=falseиDeletionMark=false. Проведение — решение бухгалтера. - Платёж со списком без файла списка. Такая строка останавливается.
- Платёж с расходящимися суммами. Платёжное поручение = сумма оснований = сумма строк по сотрудникам, проверяется до создания платежа.
Известный пробел: черновики по налогам и пеням неполны
Налоги и пени классифицируются правильно — верный вид документа,
ВидОперации = ПеречислениеНалога, ПениСам для пеней, КБК если он есть в
выписке. Но черновик намеренно неполон: не заполняются ВидНалога_Key (вид
налога), налоговый орган как контрагент и его счёт, счета учёта и субконто.
Причина в §10: вид налога нельзя выбрать по одному КНП — под 911 приходят и ИПН, и социальный налог, они различаются только КБК, а соответствие КБК→налог своё в каждой базе.
Поэтому строку по налогу или пене бухгалтер дозаполняет в 1С до проведения. Dry-run помечает каждую налоговую строку соответствующим вопросом. Обычные платежи, ордера эквайринга и пять платежей со списками записываются полностью.
Адаптация
Начинайте с scripts/1c/mapping.json. Имена наборов сущностей, значения
перечислений, организация и её счёт — всё там, потому что ничто из этого не
переносится между базами.
Если сам скрипт не подходит этой конфигурации — исправьте скрипт и скажите пользователю, что изменили.
Два вопроса — локальная учётная политика, её подтверждают, а не выводят: как организация проводит переводы собственных средств и эквайринг, и как отделяются личные суммы предпринимателя. Запишите договорённость в заметки пространства и никогда не переносите её в другую базу.
Проверка
python3 -m unittest discover -s scripts/1c/tests
Фикстуры синтетические — вымышленные компании и ИИН, — так что запускать их безопасно в любой момент.
Где живут регламенты, а где нет
Страницы /help и есть регламент. Не копируйте их в рабочие пространства.
Вписанный вручную в knowledge/ каждого пространства, один и тот же регламент
превращается в N копий, которые нужно держать синхронными и которые нельзя исправить
все сразу. Ставьте ссылку: каждая страница отдаёт исходный markdown по адресу
/help/<slug>.md именно для этого.
Что действительно место в пространстве: то, что верно для одной базы и ни для какой другой — подтверждённые договоры и настройки поставщиков, устойчивая структура документов этой базы, её локальные исключения, решения пользователя о создании справочников и проведении, номера уже созданных документов. Никогда — GUID, БИН/ИИН, адреса баз и банковские реквизиты одной базы в заметках другого пространства.
Правила, которые всё это реализует
- Работа с 1С через OData — механика.
- Разноска банковской выписки в 1С — регламент.
- Акты сверки взаиморасчётов в 1С — то, что
реализует
1c-reconciliation-act-kz. - Загрузка входящих ЭСФ в 1С — то, что реализует
1c-esf-import-kz. - Реализации по счетам покупателям — то, что
реализует
1c-sales-realization-kz, включая ЭАВР. - Начисление зарплаты в 1С — то, что реализует
1c-payroll-kz. - Подключение 1С — как включить OData.
Если скрипт и эти страницы расходятся — истина в страницах.