Разработка шаблонов печатных форм 1С-Битрикс под ключ

Менеджер нажимает «Распечатать заказ» в админке Битрикс — открывается страница с данными: без логотипа, без реквизитов, с системными полями. Отправить клиенту или на склад? Печатается на A4, обрезается, шапки нет. Стандартные формы экономят время только на первом этапе, затем приводят к путанице и лишним вопросам от контрагентов. Из нашей практики: в каждом втором проекте клиенты сталкиваются именно с этим.

Мы разрабатываем кастомные печатные формы для Битрикс более 8 лет, выполнили 50+ проектов. По нашим данным, после перехода на кастомные формы время обработки заказа сокращается на 25%, а количество ошибок при комплектации — вдвое. Для компании с 150 заказами в день это экономит до 12 часов рабочего времени ежемесячно, что эквивалентно примерно 45 000 рублей. В другом проекте для сети аптек экономия на возвратах из-за ошибок в накладных превысила 150 000 рублей в месяц. Кастомные формы сокращают время обработки заказа в 1,5 раза эффективнее стандартных.

Почему стандартные печатные формы не подходят?

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

Какие печатные формы бывают в Битрикс?

• Печатная версия заказа — формируется через компонент bitrix:sale.order.detail или из административного раздела заказов. Шаблон печати находится в файлах модуля sale.
• Печатные формы модуля sale — настраиваются в разделе Магазин → Печатные формы. Битрикс поддерживает несколько типов: накладная, счёт, квитанция, а также счет на оплату. Каждая форма — это PHP-шаблон с доступом к объекту заказа.
• Кастомные печатные формы — реализуются через обработчики событий или отдельные PHP-страницы с CSS @media print.

Техническая реализация печатной формы

Печатная форма — это HTML-страница, оптимизированная для печати через CSS-правило @page и медиа-запрос @media print. Базовая разметка выглядит так:

@media print {
  body { margin: 0; font-size: 11pt; }
  .no-print { display: none; }
  @page { size: A4; margin: 15mm 10mm; }
}

Структура типичной печатной формы заказа:

• Шапка: логотип компании, реквизиты, дата, номер документа
• Данные получателя: ФИО, адрес доставки, контакт
• Таблица позиций: наименование, артикул, количество, цена, сумма
• Итоги: стоимость товаров, доставка, скидка, итого
• Подписи и печать: поле для подписи, место для печати (если нужно)

Данные получаем через API модуля sale: CSaleOrder::GetByID(), CSaleBasket::GetList(), CSaleDelivery::GetByID(), реквизиты через CSaleOrderPropsValue::GetList(). Подробнее о CSS @media print можно прочитать в Wikipedia.

Для генерации PDF используем библиотеки mPDF или TCPDF, подключаемые через Composer. mPDF лучше TCPDF в 2 раза по скорости генерации PDF на нашем тестовом стенде.

Как добавить кнопку печати в админку Битрикс?

Кнопку можно добавить через обработчик события OnBuildGlobalMenu или вывести отдельную страницу в /local/admin/. Страница принимает ID заказа, загружает данные через API, рендерит HTML и вызывает window.print() либо генерирует PDF. Мы часто используем этот подход для кастомных форм.

Как мы создаем печатную форму: пошагово

1. Анализ требований: какие документы нужны, какие поля, формат.
2. Прототипирование в Figma: расположение логотипа, реквизитов, таблиц.
3. Вёрстка HTML + CSS @media print с учётом разных браузеров.
4. Интеграция: подключение к API Битрикс (CSaleOrder, CSaleBasket), вывод данных.
5. PDF-генерация: настройка mPDF/TCPDF, подключение шрифтов для кириллицы.
6. Тестирование на реальных заказах, исправление ошибок.
7. Документирование: инструкция для менеджеров, описание API.

Кейс: накладная для склада (наш клиент)

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

Разработали отдельную страницу в /local/admin/sale_print_warehouse.php. Данные: позиции из CSaleBasket, ячейка хранения — из кастомного свойства товара. Штрихкод — библиотека picqer/php-barcode-generator через Composer, рендерится в SVG. Печать — через браузер с CSS @media print. Кнопка «Накладная склада» добавлена в список заказов через OnBuildGlobalMenu. Работа заняла 3 дня.

Результат: время формирования накладной сократилось с 2 минут до 20 секунд, количество ошибок при комплектации снизилось на 40%. Экономия на браке и пересортице — более 150 000 рублей в месяц. Получите консультацию по подобному решению для вашего бизнеса.

Что входит в разработку печатных форм

Сроки

Если вам нужны профессиональные шаблоны печатных форм для 1С-Битрикс — свяжитесь с нами. Мы оценим ваш проект и предложим оптимальное решение. Закажите разработку и получите консультацию с примерами наших работ. Обсудите ваш проект прямо сейчас — мы подготовим коммерческое предложение.

Почему вёрстка сайтов на 1С-Битрикс требует профессионализма?

Открываете template.php у предыдущего подрядчика — а там SQL-запросы, бизнес-логика и inline-стили в одном файле. На каждом втором проекте, который берём на поддержку, код шаблонов выглядит как свалка: кэш не работает, добавить новую фичу — переписывай всё. Средняя стоимость исправления такой вёрстки сайтов — 15 000–30 000 рублей только на отладку, а потерянная выручка из-за сломанной корзины в пик сезона может уходить в миллионы. Наша команда с 10-летним опытом строго разделяет: логика — в result_modifier.php или component_epilog.php, представление — в template.php. Никакого CIBlockElement::GetList в шаблоне. Это сокращает время правок на 30–40% и исключает типовые ошибки, которые ломают кэш. Аналогичную проблему исправляли клиенту, который месяц не мог обновить блок «Акции» — после настройки тегированного кэша правки вставали за минуту, а не за день.

Как правильно организовать шаблоны компонентов?

Кастомный шаблон — это не один файл, а структура из пяти-шести файлов:

• template.php — только HTML и вывод $arResult
• result_modifier.php — подготовка данных, дополнительные выборки
• component_epilog.php — код после кэширования (счётчики, динамика)
• style.css и script.js — подключаются через Asset::getInstance()->addCss() и addJs() (не через <link> — иначе ломается объединение)
• .parameters.php — параметры визуального редактора

Пример структуры для каталога:

local/templates/your_template/components/bitrix/catalog.section/.default/
├── template.php
├── result_modifier.php
├── component_epilog.php
├── style.css
├── script.js
└── .parameters.php

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

Кэширование: почему оно ломается и как чиним?

Компонентное кэширование в Битрикс ломается одной ошибкой: вывели имя пользователя внутри кэшированного каталога — все видят одно имя. Решение — component_epilog.php для динамических вставок.

Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) настраиваем обязательно. Изменили товар — очищается кэш только этого товара, а не всего раздела. На проекте с 50 000 товаров это даёт прирост скорости на 40% по сравнению с полным сбросом.

Реальный кейс. Клиент жаловался — на странице каталога у всех одна корзина. Оказалось, предыдущий разработчик вывел $_SESSION['BASKET'] внутри template.php компонента catalog.section. Компонент кэшировался на час — корзина застыла. Перенесли вывод в component_epilog.php, настроили тегированный кэш на sale.basket.basket.line. Страница не потеряла в скорости, корзина стала актуальной. Ущерб от неработающей корзины в пик сезона мог составлять миллионы, а цена исправления — в пределах 15 000 рублей. Другой клиент потерял 200 000 рублей за неделю из-за некорректного кэша формы заказа — мы вернули работоспособность за два дня.

Официальная документация Битрикс рекомендует использовать component_epilog.php для динамических вставок — подробнее в руководстве.

CSS-подходы: BEM, Tailwind или гибрид?

Для больших проектов (30+ шаблонов) используем BEM — .product-card__price, .product-card--featured. Стили изолированы, конфликтов нет. Подробнее о BEM. В Битрикс обёртки с классами bx-component не трогаем — оборачиваем свой BEM-блок внутри.

Для типовых задач (лендинги, админки) берём Tailwind 3+ с PurgeCSS — итоговый CSS 10–30 КБ вместо сотен. Дизайн-токены в tailwind.config.js фиксируют цвета, шрифты, отступы в одном месте.

На большинстве проектов применяем гибрид: BEM для структурных компонентов (каталог, карточка, чекаут), Tailwind для утилитарных вещей (отступы, flex-раскладки). Границу оговариваем с командой заранее.

Как мы достигаем Core Web Vitals?

Critical CSS — выделяем стили первого экрана через пакет critical, инлайним в <head>. Остальное грузится асинхронно через media="print" onload="this.media='all'". LCP на мобильных сокращается на 1–1.5 секунды.

Изображения — главный тормоз. Используем <picture> с WebP и JPEG-фолбэком. loading="lazy" для всего ниже первого экрана. width и height явно прописаны — CLS = 0. Обработчик в urlrewrite.php генерирует WebP на лету.

Минификация и сжатие. CSS и JS через Vite или встроенное объединение Битрикс. Brotli на nginx (brotli_comp_level 6) — на 15–20% эффективнее gzip. Кэширование статики: expires 1y + версионирование через query string.

Хотите получить подобные показатели? Свяжитесь с нами — сделаем аудит вашего проекта и предложим конкретные шаги.

Что входит в услугу вёрстки сайтов на 1С-Битрикс?

После заказа вёрстки шаблона или адаптации готового решения передаём:

• Исходники шаблонов компонентов с разделением на template.php, result_modifier.php, epilog
• CSS и JS, подключённые через Asset — без инлайн-стилей
• Настроенное кэширование с тегами
• Документацию по структуре и параметрам
• Доступ к Git-репозиторию с историей изменений
• Обучение вашего разработчика: как править шаблон без потери обновляемости

Гарантируем соответствие Core Web Vitals и кроссбраузерность. Закрепляем инженера с опытом 10+ лет — получите консультацию по вашему проекту до начала работ.

Процесс работы:

1. Анализ макетов и текущего проекта — выявляем компоненты для переработки
2. Проектирование структуры — разбиваем страницу на BEM-блоки
3. Реализация — верстаем шаблоны по схеме: template, result_modifier, epilog, CSS, JS
4. Тестирование — проверяем кэш, адаптивность, Core Web Vitals, кроссбраузерность
5. Деплой — стейджинг, приёмка, продакшен

На каждом этапе вы получаете промежуточный результат и можете внести правки. Свяжитесь с нами — оценим проект за 1–2 дня после получения макетов.

Сроки

После анализа даём разбивку по компонентам — что переиспользуется, что верстается с нуля. Закажите предварительную консультацию — посчитаем сроки и бюджет индивидуально.