При автоматизации документооборота часто возникает задача расширения типового функционала для специфических нужд, таких как учет почтовых отправлений. Типовая конфигурация 1С:Документооборот (1С:ДО) предоставляет механизмы дополнительных реквизитов, однако при большом количестве полей (30 и более) и необходимости сложной логики (расчеты, интеграции, проверка заполнения) стандартных средств становится недостаточно. Рассмотрим подробно, как правильно спроектировать такое решение, реализовать интеграцию с внешними сервисами и настроить корректную печать штрихкодов.
На начальном этапе важно определиться, где хранить данные. Использование механизма дополнительных реквизитов БСП (Библиотеки стандартных подсистем) удобно тем, что не требует изменения структуры метаданных. Однако, если планируется внедрение сложной бизнес-логики (например, автоматический расчет стоимости доставки при изменении веса), работа с доп. реквизитами превращается в «программный кошмар». Выясним почему: элементы на форме создаются динамически, их сложно типизировать в коде, а поиск нужного реквизита в коллекции ЭтотОбъект.СвойстваУправления замедляет работу системы.
Рассмотрим более надежный путь — использование расширений конфигурации. Проанализируем преимущества этого метода:
ВесПисьма, ТрекНомер) непосредственно в справочник ИсходящиеДокументы (для версии 2.1) или Документы (для версии 3.0).Чтобы не перегружать стандартную форму документа для всех пользователей, разберем, как реализовать контекстное отображение полей. Нам нужно, чтобы специфические поля для корреспонденции (адрес, габариты, стоимость) появлялись только при выборе определенного вида документа, например, «Заявка на отправку почты».
Для этого в расширении формы документа в процедуре ПриСозданииНаСервере или ПриИзмененииВидаДокумента реализуем логику управления видимостью. Рассмотрим пример кода:
&НаСервере
Процедура Корр_УправлениеВидимостьюПолей()
ЭтоЗаявкаНаПочту = (Объект.ВидДокумента = Справочники.ВидыИсходящихДокументов.НайтиПоНаименованию("Заявка на отправление почты"));
// Управляем видимостью целой группы (страницы), созданной в расширении
Элементы.ГруппаПочтовыеДанные.Видимость = ЭтоЗаявкаНаПочту;
КонецПроцедуры
Создадим в редакторе формы отдельную вкладку «Параметры отправки» и разместим там все необходимые поля. Это позволит сохранить чистоту интерфейса для сотрудников, не связанных с логистикой.
Для реализации «хотелок» по расчету стоимости и отслеживанию статусов проанализируем возможности внешних API. Основной механизм взаимодействия в 1С строится на использовании объекта HTTPСоединение.
Разберем этапы интеграции с Почтой России (сервис otpravka.pochta.ru):
Посмотрим на пример функции для расчета стоимости (упрощенно):
&НаСервере
Функция РассчитатьСтоимостьНаСервере(ДанныеОтправления)
Сервер = "otpravka.pochta.ru";
Ресурс = "/v2/tariff";
Заголовки = Новый Соответствие;
Заголовки.Вставить("Authorization", "AccessToken " + Константы.Корр_ТокенПочты.Получить());
Заголовки.Вставить("X-User-Authorization", "Basic " + Константы.Корр_КлючАвторизации.Получить());
Заголовки.Вставить("Content-Type", "application/json;charset=UTF-8");
Соединение = Новый HTTPСоединение(Сервер, 443, , , , , Новый ЗащищенноеСоединениеOpenSSL());
Запрос = Новый HTTPЗапрос(Ресурс, Заголовки);
Запрос.УстановитьТелоИзСтроки(ДанныеОтправления);
Ответ = Соединение.ОтправитьДляОбработки(Запрос);
Возврат Ответ.ПолучитьТелоКакСтроку();
КонецФункции
Аналогичным образом настраивается интеграция с DHL. Важно настроить Регламентное задание, которое будет раз в несколько часов обходить все «активные» документы с трек-номерами и обновлять их статусы (например, «Принято в отделении», «В пути», «Вручено»).
Ввод адреса «текстом» — плохая практика, приводящая к ошибкам при доставке. Выясним, как использовать штатный механизм 1С. В справочнике «Виды контактной информации» добавим новый элемент для объекта ИсходящиеДокументы с типом «Адрес». Это позволит пользователям открывать стандартный диалог выбора адреса из классификатора ФИАС. При этом индекс будет заполняться автоматически, что критически важно для корректного расчета стоимости через API.
Как показал опыт обсуждения, использование шрифтов (типа eangnivc) часто приводит к тому, что сканеры не могут прочитать код из-за отсутствия контрольных символов или неправильного масштабирования. Проанализируем правильный способ вывода штрихкода в печатную форму табличного документа.
Вместо шрифтов следует использовать программную генерацию картинки. В 1С:ДО для этого предназначен общий модуль ШтрихкодированиеСервер. Рассмотрим пошагово, как вывести штрихкод в макет:
РисунокШтрихкод.
// Получаем параметры штрихкода (тип, значение, размеры)
ПараметрыШтрихкода = ШтрихкодированиеСлужебный.ПараметрыВыводаШтрихкода();
ПараметрыШтрихкода.ТипКода = 4; // Например, Code128
ПараметрыШтрихкода.Штрихкод = Объект.Штрихкод;
ПараметрыШтрихкода.Ширина = 300;
ПараметрыШтрихкода.Высота = 100;
// Генерируем картинку
ДанныеШтрихкода = ШтрихкодированиеСервер.ПолучитьКартинкуШтрихкода(ПараметрыШтрихкода);
// Выводим в область макета
ОбластьМакета.Рисунки.РисунокШтрихкод.Картинка = ДанныеШтрихкода;
Этот метод гарантирует, что штрихкод будет сформирован по всем стандартам (с учетом контрольных сумм) и будет одинаково корректно отображаться у всех пользователей без необходимости установки дополнительных шрифтов в операционную систему.
Мы выяснили, что для полноценной реализации учета корреспонденции в 1С:ДО необходимо отказаться от перегрузки системы дополнительными реквизитами в пользу расширений. Это дает нам возможность использовать табличные части для описей и создавать отзывчивый интерфейс. Интеграция через HTTP-запросы позволяет автоматизировать расчеты с почтовыми операторами, а программная генерация штрихкодов через БСП обеспечивает надежность печатных форм. Такой комплексный подход позволит системе «взлететь» и обеспечит запас для масштабирования под будущие требования бизнеса.