Печатные формы УПД, ТОРГ-12, КС-2 и КС-3 в ERPNext: как сделать и что проверить

Российских печатных форм УПД, ТОРГ-12, КС-2 и КС-3 в коробке ERPNext нет. Счёт и УПД верстают как Print Format на HTML и Jinja, а КС-2 и КС-3 удобнее формировать в 1С. Ниже: что выбрать, как собрать шаблон и что проверить до первой печати.

Какие печатные формы есть в ERPNext и какие придётся делать

В ERPNext из коробки печатается любой документ: у каждого типа есть стандартный формат (Standard), который выводит поля документа в общем виде. Это годится для внутренней работы, но не для документов, которые уходят контрагенту. Российских бланков в системе нет: ни УПД, ни ТОРГ-12, ни форм КС-2 и КС-3, ни счёта на оплату по привычной форме. Региональный модуль для России в ядре отсутствует, и это одно из тех ограничений, о которых я говорю заказчику в первой же встрече. В нашем решении ERPNext под ключ нормативные печатные формы не входят в базовый пакет и оцениваются отдельно по ТЗ.

Практическая картина по четырём документам, которые просят чаще всего: | Документ | Где формируем | Комментарий | |---|---|---| | Счёт на оплату | ERPNext, Print Format | вёрстка по вашему образцу, объём фиксируем в ТЗ | | УПД | ERPNext, Print Format | нормативная форма, оценка по ТЗ, проверка с бухгалтером | | ТОРГ-12 | ERPNext, Print Format, по запросу | аналогично УПД, оценка по ТЗ | | КС-2 и КС-3 | 1С | нужны накопительные итоги и привязка к смете |

Этот материал про то, как сделать форму в ERPNext. Нормативные подробности, связанные с обязательным переходом на новый формат УПД, я здесь не разбираю: для этого есть отдельная статья про УПД 5.03 и переход в 1С в 2026 году. Коротко о границах: российского регионального модуля в ERPNext нет, поэтому формы, обмен с 1С и ЭДО всегда отдельная работа. А как похожую задачу решают в другой открытой системе, читайте в разборе Odoo в России: локализация и печатные формы.

Print Format Builder или Jinja: что выбрать для строгой формы

В Frappe есть два способа сделать свой формат печати, и выбор между ними определяется требованиями к вёрстке. Print Format Builder, это визуальный конструктор: вы перетаскиваете поля из боковой панели на страницу, добавляете блок Custom HTML и сохраняете. Он быстрый и подходит для внутренних форм, актов передачи и простых документов. Но документация сама говорит о его пределе: если нужно полностью поменять макет, конструктор не годится, и тогда пишут свой HTML.

Второй способ — Print Format с типом «Jinja»: вы создаёте запись Print Format, включаете флаг «Custom Format», выбираете «Print Format Type» = Jinja и пишете HTML, CSS и шаблон. В документации Frappe для вёрстки предлагаются классы Bootstrap, а динамика строится на Jinja. Строгие бланки, где важны границы ячеек, ширины колонок и многостраничность, делают только так. Мой выбор прост: внутренние документы собираю конструктором, всё, что уходит контрагенту, пишу Jinja.

Теперь о правах и мелочах, на которых спотыкаются. Стандартный формат (Standard) править нельзя, сначала нужно создать копию и работать с ней: код Print Format в v15 запрещает изменять стандартный формат вне режима разработчика. Создавать и править форматы может роль System Manager, и это сознательное ограничение, потому что поля формата допускают HTML и скрипты. Сделанный формат нужно назначить по умолчанию: открываете Customize Form для нужного типа документа (например, Sales Order), выбираете формат в поле «Default Print Format» и сохраняете. Если портал для клиентов у вас включён, он тоже использует формат по умолчанию, поэтому ошибки вёрстки увидит и заказчик.

УПД и счёт на оплату: из чего собирается шаблон

Шаблон собирается из трёх частей: шапка с реквизитами сторон, таблица позиций и блок итогов. Данные берутся из документа через переменную doc, табличная часть доступна как doc.items, налоги как doc.taxes. Для счёта на оплату я беру за основу Sales Order, для УПД Sales Invoice или Delivery Note. Названия полей проверяйте по метаданным DocType, а не по памяти: в Sales Order, например, есть customer_name, transaction_date, tax_id, grand_total, in_words, а в строках items есть item_name, uom, qty, rate, amount.

Рабочий скелет счёта на оплату. Это не готовая нормативная форма, а каркас, по которому видно принцип:

<style>
  table.items { width: 100%; border-collapse: collapse; font-size: 9pt; }
  table.items th, table.items td { border: 1px solid #000; padding: 2px 4px; }
  table.items thead { display: table-header-group; }
  table.items tr { page-break-inside: avoid; }
  .r { text-align: right; }
</style>

<h3>Счёт на оплату № {{ doc.name }} от {{ doc.get_formatted("transaction_date") }}</h3>
<p>Покупатель: {{ doc.customer_name }}, ИНН {{ doc.tax_id or "" }}</p>

<table class="items">
  <thead>
    <tr><th>№</th><th>Наименование</th><th>Ед.</th>
        <th>Кол-во</th><th>Цена</th><th>Сумма</th></tr>
  </thead>
  <tbody>
  {% for row in doc.items %}
    <tr>
      <td>{{ loop.index }}</td>
      <td>{{ row.item_name }}</td>
      <td>{{ row.uom }}</td>
      <td class="r">{{ row.get_formatted("qty") }}</td>
      <td class="r">{{ row.get_formatted("rate") }}</td>
      <td class="r">{{ row.get_formatted("amount") }}</td>
    </tr>
  {% endfor %}
  </tbody>
</table>

{% for t in doc.taxes %}
  <p class="r">{{ t.description }}: {{ t.get_formatted("tax_amount") }}</p>
{% endfor %}
<p class="r"><b>Всего к оплате: {{ doc.get_formatted("grand_total") }}</b></p>
<p>{{ doc.in_words }}</p>

Что в нём важно. Метод get_formatted применяет формат поля: даты и деньги выводятся так, как настроено в системе, а не сырыми числами. Сумма прописью берётся из стандартного поля in_words. CSS-правило page-break-inside для строк таблицы и display: table-header-group для thead нужны, чтобы строки не рвались между страницами, а шапка повторялась на каждой: это проверяйте на реальном PDF, потому что движок генерации PDF по-разному делит страницы. В v15 это wkhtmltopdf, в v16 в настройках печати появился выбор между wkhtmltopdf и Chrome; как поведёт себя ваша форма на вашем движке, покажет только пробная печать.

Две практики безопасности и производительности для шаблонов. Не делайте запросов к базе внутри цикла по строкам: вызов frappe.db.get_value на каждую из 200 позиций замедлит печать, лучше подготовить данные заранее или вывести нужное через поля документа. И помните, что поле HTML формата исполняется на сервере и в браузере, поэтому править его может только доверенная роль, и выдавать её прорабам или менеджерам «на время» я не советую. Заготовленный шаблон я кладу в систему управления версиями проекта, чтобы после обновления ядра его можно было восстановить.

Отдельно про реквизиты. В коробочной карточке покупателя поле для налогового номера одно, Tax ID, и оно же приходит в документ как tax_id. Для КПП, ОГРН и других российских реквизитов заводят пользовательские поля (Custom Field) на карточке клиента и поставщика и потом выводят их в шаблоне. Я делаю это в рамках проекта вместе с формой, чтобы данные не пришлось дозаполнять после запуска. Для печати больших пачек документов в списках есть массовая печать (Bulk Print). Её удобно использовать для пакета УПД в конце месяца, но на первых запусках я печатаю по одному документу и сверяю с образцом.

КС-2 и КС-3: почему лучше формировать в 1С

С формами КС-2 и КС-3 я обычно советую не торопиться делать их в ERPNext. Причина в том, что это не просто красивая таблица. КС-2, акт о приёмке выполненных работ, и КС-3, справка о стоимости выполненных работ, зависят от накопительных итогов: объём выполнения нарастает по периодам, а суммы сверяются со сметой и договором. Частичный счёт ERPNext выставить умеет: из заказа можно создать Sales Invoice на часть количества. Но накопительного акта «выполнено с начала работ и за отчётный период» со ссылкой на смету, как в КС-2, в системе нет, и собрать его одним шаблоном печати не получится. Там, где логика приёмки по этапам нужна жёстко, она реализуется отдельной доработкой, а не одним шаблоном печати.

Рабочая схема у нас такая. ERPNext ведёт данные о выполнении этапов: проект, задачи, объёмы, закупки, материалы на объекте. Эти данные передаются в 1С, где бухгалтер формирует КС-2 и КС-3 и обычные закрывающие документы по привычной для него схеме. Обмен строится через HTTP-сервисы, REST или OData, без прямой записи в базу 1С. Это решение не для красоты: акт попадает в регламентированный учёт, а там и должны быть сметы, накопительные итоги и форматы, принимаемые заказчиком.

Если всё же нужно напечатать КС-2 из ERPNext (например, как внутренний документ или прототип), для больших спецификаций используют приём со строками-группами. В таблицу позиций добавляют служебные строки, которые обозначают разделы, а кастомный формат на Jinja считает подитоги по разделам. Но предупреждаю: такая форма легко ломается при изменении состава позиций, и каждая правка шаблона требует проверки. Смета по ФЕР и ТЕР в ERPNext не ведётся: её считают во внешних программах, а в систему загружают итоговую ресурсную спецификацию. Поэтому КС-2 по сути опирается на данные, которых в ERPNext нет.

«Акт-Смета Групп»: 12 мест и пошаговая сборка формы

Условный пример. Строительно-монтажная компания «Акт-Смета Групп», 12 рабочих мест: директор, два ПТО, три прораба, два снабженца, два бухгалтера и два сметчика. Операционный учёт переехал в ERPNext, бухгалтерия осталась в 1С. Задача, с которой пришли: счета на оплату и УПД печатать из ERPNext, а КС-2 и КС-3 по-прежнему готовить в 1С, но чтобы данные туда не переписывали руками.

Мы сделали две формы: счёт на оплату от Sales Order и УПД от Sales Invoice. Вёрстку строили по образцу, который дал главный бухгалтер, и согласовывали с ним каждый шаг. Срок в условном примере: два рабочих дня на счёт, три дня на УПД с проверкой, ещё день на правки по замечаниям. Права на создание форматов остались только у администратора системы: прорабам и снабженцам достаточно права на печать.

Какие шероховатости всплыли на пробной печати. Первая: на документе из 45 позиций шапка таблицы не повторялась на второй странице, пока мы не добавили в стиль thead правило display: table-header-group. Вторая: сумма НДС в итоге отличалась от суммы по строкам на одну копейку из-за порядка округления, и мы выровняли расчёт с тем, как это делает 1С, вместо того чтобы подгонять цифры руками. Третья: у двух контрагентов не был заполнен КПП, и в форме осталась пустая строка. Это решили обязательным пользовательским полем на карточке. Все три находки выявила обычная сверка на трёх документах, которую я рекомендую не пропускать.

В результате прорабы запрашивают счёт кнопкой «Print», бухгалтеры видят единый внешний вид, а данные для КС-2 и КС-3 выгружаются в 1С отдельным шагом. Показать собранный шаблон на тестовых данных можно на демостенде erp-demo.itfresh.ru по запросу. Порядок работ, который мы прошли и который годится для вашего проекта, ниже по шагам.

• Взяли за основу Sales Order (счёт) и Sales Invoice (УПД) и создали копии стандартных форматов.
• Завели Custom Print Format с типом Jinja и скелетом из шапки, таблицы и итогов.
• Добавили пользовательские поля на карточку контрагента (КПП, юридический адрес) и вывели их в шапку.
• Проверили на трёх документах с разным числом строк: 5, 22 и 45 позиций, смотрели разрыв страниц.
• Сверили суммы НДС в строках и в итоге с проводками в 1С на тех же документах.
• Назначили форматы по умолчанию через Customize Form и закрыли правку для всех, кроме System Manager.

Что проверить перед первой печатью: юридическая сила и ЭДО

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

Теперь о том, что стоит за словами «юридическая сила». Печатная форма сама по себе не придаёт документу силу: важно, где документ оформлен, кем подписан и как передан. Для передачи контрагентам и налоговой документы, как правило, оформляются в учётной системе и по ЭДО, где подпись электронная. Поэтому форму из ERPNext я рассматриваю как управленческий и внутренний документ или как документ для бумажного обмена, а юридически значимый поток по ЭДО строят вокруг 1С. Подробнее про обмен документами смотрите в материалах про ЭДО с контрагентами и про электронную подпись сотрудников.

Что остаётся за границей этой статьи, в моём списке ограничений: форма печатается, но электронный формат для оператора ЭДО по ней не создаётся; согласованность вёрстки с обновлениями версии нужно проверять на тестовой копии, потому что кастомные печатные формы относятся к зоне риска при обновлении ядра; а какие именно поля обязательны в актуальном формате УПД, определяет бухгалтер, а не разработчик шаблона. Если у вас есть сомнения, проверьте форму на трёх реальных документах и покажите образец бухгалтеру до запуска.

• Реквизиты компании и контрагента заполнены без пропусков.
• ИНН и КПП выводятся там, где нужны (КПП из пользовательского поля).
• Ставка и сумма НДС в строках и в итоге совпадают с документом.
• При 20 и более позициях таблица разбивается на страницы без обрезанных строк.
• Места подписей и печати на месте.
• Формат принимается вашим оператором ЭДО: проверить с бухгалтером.

Частые вопросы