При работе с электронным документооборотом (ЭДО) в системах «1С:Предприятие», таких как Управление торговлей 11, Бухгалтерия предприятия 3.0 или ERP, пользователи часто сталкиваются с неприятной ситуацией. При просмотре визуального представления УПД или счета-фактуры некоторые символы (диаметр, квадраты, специфические дроби, ударения) заменяются на символ «?». Рассмотрим подробнее, почему это происходит и как мы можем решить данную проблему в рамках текущего законодательства.
Проанализируем ситуацию: современные конфигурации 1С построены на платформе 8.3, которая по умолчанию работает с Юникодом (UTF-8). Однако при формировании XML-файлов для отправки через ЭДО система принудительно использует однобайтовую кодировку windows-1251. Это можно увидеть, если выгрузить файл на диск и открыть его в текстовом редакторе. Первая строка документа всегда выглядит так:
<?xml version="1.0" encoding="windows-1251"?>
Проблема заключается в том, что кодировка windows-1251 содержит ограниченный набор символов — в основном стандартную кириллицу, латиницу и базовые знаки пунктуации. Все символы, выходящие за пределы этого набора (например, ⌀, ±, ², ℃), при попытке записи в файл просто «теряются», превращаясь в знаки вопроса.
Посмотрим на ситуацию с точки зрения закона. Многие разработчики пытаются программно изменить кодировку на UTF-8, надеясь решить проблему. Однако это тупиковый путь. Проанализируем требования Приказа ФНС России (например, № ЕД-7-26/970@), который регламентирует формат УПД. В техническом описании формата четко указано: первая строка XML-файла обмена должна содержать encoding="windows-1251".
Это требование обусловлено архитектурой приемных шлюзов налоговой службы. Если вы попытаетесь отправить файл в UTF-8, могут возникнуть следующие проблемы:
ДвоичныеДанныеФайлов), стандартные механизмы 1С перестают корректно формировать печатную форму УПД, выдавая ошибку или ссылку на файл вместо таблицы.Поскольку мы не можем изменить закон и кодировку самого файла, разберем способы адаптации данных, чтобы они корректно передавались контрагентам. Совместно с методологами 1С рекомендуется использовать стратегию «безопасной замены» символов в наименованиях номенклатуры.
Вместо использования надстрочных символов и пиктограмм, которые выглядят красиво в интерфейсе 1С, но «бьются» при передаче, следует использовать текстовые сокращения согласно ГОСТ 8.417-2002. Рассмотрим примеры наиболее частых замен:
м² пишем кв. м или м2.м³ пишем куб. м или м3.⌀ используем латинскую заглавную O, сочетание д. или слово диам..± используем комбинацию +/-.℃ пишем град. С.Если в вашей базе данных уже накоплено много номенклатуры со спецсимволами, целесообразно внедрить механизм автоматической очистки строк перед формированием XML. В последних релизах Библиотеки стандартных подсистем (БСП) уже встроены функции, которые пытаются заменить «умные» кавычки (« ») на обычные (" ") и неразрывные пробелы на стандартные.
Для более сложных случаев можно использовать следующий алгоритм обработки строки в коде 1С перед передачей в модуль ЭДО:
Функция ОчиститьСтрокуДляЭДО(Знач ИсходнаяСтрока) Экспорт
// Заменяем распространенные спецсимволы на допустимые в windows-1251
Результат = СтрЗаменить(ИсходнаяСтрока, "⌀", "d");
Результат = СтрЗаменить(Результат, "±", "+/-");
Результат = СтрЗаменить(Результат, "²", "2");
Результат = СтрЗаменить(Результат, "≈", "~");
// Удаляем любые символы, которые не входят в кодировку windows-1251
// Это предотвратит появление знаков вопроса
// ... здесь может быть логика посимвольной проверки ...
Возврат Результат;
КонецФункции
Если для вашего контрагента критически важно видеть точное наименование со всеми знаками (например, при поставках по госконтрактам), проанализируем возможность использования дополнительных полей. В формате УПД предусмотрены Информационные поля (ИнфПоля). Хотя они также подчиняются общей кодировке документа, иногда в них удается передать расширенную информацию, если оператор поддерживает вложения или дополнительные текстовые блоки. Однако этот метод требует предварительного согласования с покупателем, так как его учетная система должна уметь «читать» данные из этих полей.
Выясним причину, почему ситуация до сих пор не изменилась повсеместно. ФНС осознает проблему и постепенно внедряет Юникод. Например, в новых форматах электронных путевых листов (ЭПЛ) и транспортных накладных уже разрешено использование UTF-8. Однако для массовых документов, таких как УПД и счета-фактуры, переход на новую кодировку требует одновременного обновления ПО у миллионов налогоплательщиков, что является сложной организационной задачей.
Подводя итог, можно сказать: на текущий момент технической возможности использовать полноценный Юникод в юридически значимом ЭДО (УПД) в России не существует из-за ограничений форматов ФНС.
Рекомендуем придерживаться следующего плана действий:
Номенклатура на наличие символов, не входящих в windows-1251.кв.м., +/-, град.).Таким образом, использование однобайтовой кодировки в ЭДО — это не ошибка программистов 1С, а строгое следование нормативной базе. Соблюдение этих простых правил поможет вам избежать конфликтов с контрагентами и проблем при налоговых проверках.