При работе с крупными контрагентами, использующими зарубежные ERP-системы (например, SAP R/3 или S/4HANA), поставщики часто сталкиваются с требованием передавать в электронных документах специфические данные. Одним из таких требований является указание номера заказа ТОРО (Техническое обслуживание и ремонт оборудования) в каждой строке УПД. Если в день оформляется несколько десятков позиций, ручное создание уникальных карточек номенклатуры под каждый заказ быстро приведет к деградации базы данных и хаосу в справочниках.
В этой статье мы разберем, как реализовать передачу номера ТОРО технически грамотно, сохранив чистоту справочника Номенклатура и обеспечив автоматизацию процесса в 1С:Бухгалтерия 8.3 при использовании ЭДО через оператора Тензор (СБИС).
Прежде всего, проанализируем ситуацию: почему покупатель настаивает на этих данных? В системе SAP модуль ТОРО требует жесткой привязки каждой копейки затрат к конкретному сервисному заказу. Без номера заказа в пришедшей «электронке» система покупателя не сможет выполнить Three-way matching (автоматическое сопоставление заказа, поступления и счета-фактуры). Бухгалтеру на стороне покупателя придется вносить данные вручную, что нивелирует пользу от ЭДО.
Наша задача — передать данные так, чтобы они попали в XML-файл (формат по приказу ФНС №820), но не создавали лишних объектов в нашей локальной базе 1С.
Это самый популярный метод, позволяющий оставить справочник Номенклатура нетронутым. Мы будем изменять текст наименования товара только в момент формирования электронного сообщения.
Рассмотрим алгоритм реализации через расширение конфигурации. Нам необходимо перехватить процедуру заполнения данных для ЭДО. В типовых конфигурациях на базе БСП (Библиотеки стандартных подсистем) данные для формирования XML собираются в модулях менеджера или специализированных модулях ЭДО.
Посмотрим на пример кода, который можно внедрить в расширение для модификации текста строки:
&После("ЗаполнитьДанныеПозицииУПД")
Процедура Расш_ЗаполнитьДанныеПозицииУПД(ДанныеПозиции, ТекСтрокаДокумента)
// Допустим, номер ТОРО хранится в текстовом поле "Содержание" табличной части
Если ЗначениеЗаполнено(ТекСтрокаДокумента.Содержание) Тогда
// Формируем новое наименование для XML
НовоеНаименование = СокрЛП(ДанныеПозиции.Наименование) + " ТОРО " + ТекСтрокаДокумента.Содержание;
ДанныеПозиции.Наименование = НовоеНаименование;
КонецЕсли;
КонецПроцедуры
Преимущество метода: Покупатель видит нужную строку и в визуальном представлении (PDF), и в XML-данных в теге НаимТов. В вашей базе 1С номенклатура остается стандартной: "Замена кнопки".
Согласно формату ФНС, в УПД предусмотрены специальные поля для передачи дополнительных сведений о товаре/услуге. Это тег ИнфПолФХЖ2. Это более профессиональный подход, так как данные передаются в структурированном виде (ключ-значение), а не "сваливаются" в одну кучу с названием.
Проанализируем структуру этого поля. Оно позволяет передать Идентификатор и Значение. Для SAP это идеальный вариант, так как их интеграционная шина может быть настроена на чтение конкретного идентификатора ORDER_ID.
Для реализации этого способа в 1С:Бухгалтерия 8.3 при использовании встроенного модуля ЭДО, необходимо дополнить коллекцию ДополнительныеСведения в структуре данных строки. Разберем, как это может выглядеть в коде:
// Пример добавления структуры в доп. поля строки документа
НовоеСведение = Новый Структура;
НовоеСведение.Вставить("Имя", "НомерЗаказаТОРО");
НовоеСведение.Вставить("Значение", НомерТОРОИзДокумента);
ДанныеСтроки.ИнформационныеПоля.Добавить(НовоеСведение);
Важно помнить, что при использовании оператора Тензор (СБИС), их визуализатор отлично отображает данные из этих полей. Покупатель увидит их в табличной части как дополнительные колонки.
Если вы используете внешнюю обработку от Тензора (СБИС) для 1С, вам даже не обязательно лезть в конфигуратор расширений. В современных версиях обработки СБИС реализован механизм пользовательских настроек маппинга полей.
Выясним, как это настроить:
Наименование = Номенклатура.Наименование + " " + Документ.Комментарий (или другое поле, где вы храните номер ТОРО).Этот метод хорош тем, что он не требует обновления конфигурации и не влияет на поддержку базы 1С.
В исходном вопросе звучало опасение: "Выдержит ли база такой объем номенклатуры?". Выясним причину этого страха. Автор опасался, что придется создавать новую карточку номенклатуры для каждой уникальной комбинации "Товар + Номер заказа".
Проанализируем цифры: 20-30 позиций в день — это около 700-900 новых записей в месяц или 10 000 в год. Для платформы 1С:Предприятие 8.3 это "капля в море". Современные базы данных (SQL или даже файловые) легко оперируют справочниками в сотни тысяч и миллионы записей.
Однако! Проблема здесь не в производительности базы, а в удобстве работы пользователя. Если вы будете создавать 10 000 карточек "Замена кнопки" с разными номерами, ваш бухгалтер никогда не сможет построить внятный отчет по продажам или остаткам этой самой кнопки. Именно поэтому методы 1 и 2 являются приоритетными.
Подведем итог нашему разбору. Для решения задачи наиболее эффективным путем мы рекомендуем:
ИнфПолФХЖ2 для передачи данных в структурированном виде, что обеспечит 100% автоматизацию на стороне SAP.Таким образом, мы обеспечим выполнение требований контрагента, сохраним порядок в справочниках и автоматизируем процесс обмена документами без лишних затрат на ручной труд.