С выходом платформы 1С:Предприятие 8.3.16 многие пользователи столкнулись с неприятной проблемой: при попытке распечатать документ на принтеры марки Kyocera из терминальной сессии (RDP) возникает ошибка «Ошибка при получении характеристик принтера». Ситуация осложняется тем, что в более ранних версиях платформы (например, 8.3.13 или 8.3.14) всё работало корректно, а официальная техническая поддержка 1С в ответ на обращения (код ошибки 10212820) рекомендует «не использовать терминальный сервер или использовать другие принтеры». В данной статье мы разберем причины этой проблемы и проанализируем все доступные способы её решения.
Для начала выясним причину, по которой это происходит. Начиная с релиза 8.3.16.1063, разработчики 1С внедрили механизм повышения стабильности работы с принтерами. Теперь работа с драйверами вынесена в отдельный процесс (часто его можно увидеть в диспетчере задач как spl.exe). Это сделано для того, чтобы в случае сбоя или зависания драйвера принтера не «падала» вся платформа 1С.
Проблема заключается в том, что драйверы Kyocera (особенно популярной серии KX) имеют сложную структуру передачи характеристик устройства (структура DEVMODE). Новый изолированный процесс печати 1С в условиях терминальной сессии не всегда может корректно опросить характеристики принтера через проброшенные порты RDP. Это приводит к тому, что 1С либо выдает ошибку сразу, либо неверно определяет границы страницы, из-за чего документ «разрывается» на множество мелких фрагментов при печати.
Рассмотрим самый простой и надежный метод, который не требует переустановки платформы или драйверов. Как отмечают специалисты на форумах, печать через формат PDF полностью обходит механизмы прямого опроса драйвера принтера платформой 1С. Разберем этот алгоритм:
Этот способ гарантирует сохранение форматирования и характеристик страницы, так как за рендеринг отвечает специализированное ПО, а не процесс spl.exe платформы 1С.
Проанализируем ситуацию с драйверами. Основная масса ошибок связана с использованием «тяжелого» драйвера Kyocera KX Driver. Мы рекомендуем заменить его на облегченную версию — Kyocera Classic Driver (PCL6 или KPDL). Выполним следующие шаги:
Драйверы типа KPDL эмулируют язык PostScript, который 1С воспринимает гораздо стабильнее в изолированном процессе печати.
Если специфика бизнеса не позволяет менять драйверы на сотнях рабочих мест, а бухгалтерия требует массовой печати «одной кнопкой», придется рассмотреть вариант отката платформы. Проблема наиболее выражена в ветке 8.3.16. Опытным путем установлено, что стабильная работа с принтерами Kyocera сохраняется на версиях:
Важно: Перед откатом убедитесь, что ваша конфигурация (например, БП 3.0 или ЗУП 3.1) не требует обязательного наличия версии 8.3.16. Обычно типовые конфигурации имеют минимальный порог 8.3.14, поэтому откат на стабильную 8.3.15 часто является самым быстрым решением «здесь и сейчас».
Иногда ошибка «Ошибка при получении характеристик принтера» связана с некорректно сохранившимися настройками в кэше пользователя. Посмотрим, как это исправить:
%AppData%\1C\1Cv8 и %LocalAppData%\1C\1Cv8).DEVMODE в базе данных для текущего пользователя.Системным администраторам стоит проверить сетевые настройки порта принтера на сервере. Часто драйвер Kyocera пытается опросить статус устройства по протоколу SNMP, что в терминальной сессии вызывает задержку и последующую ошибку 1С. Проанализируем действия:
Эти действия упрощают взаимодействие операционной системы с драйвером, уменьшая количество «характеристик», которые 1С пытается получить при формировании табличного документа.
Мы выяснили, что корень проблемы лежит в архитектурных изменениях подсистемы печати 1С в версии 8.3.16. Несмотря на то, что для принтеров HP разработчики выпустили исправления, для Kyocera проблема официально остается нерешенной. Наиболее эффективным техническим решением является переход на Classic PCL6 драйверы или использование печати через PDF. Если же требуется восстановить работоспособность немедленно для большого количества пользователей, единственным выходом остается использование платформы версии 8.3.15 до момента выхода исправлений в более новых релизах (сообщество отмечает, что в ветках 8.3.18 и выше ситуация стала более стабильной).