Как решить проблему отсутствия дополнительных реквизитов в документе «Операция по платежной карте» в 1С:ERP?

Программист 1С v8.3 (Управляемые формы) 1С:ERP Управление предприятием Управленческий учет IT и автоматизация бизнеса
← На главную

При внедрении, доработке или организации синхронизации данных в крупных корпоративных системах на базе 1С:ERP Управление предприятием 2 специалисты часто сталкиваются с техническими ограничениями типовой конфигурации. Одной из таких проблем в ветке конфигураций ERP 2.4 (в частности, в релизах 2.4.7.147 и аналогичных) стало отсутствие табличной части ДополнительныеРеквизиты у документа ОперацияПоПлатежнойКарте (Операция по платежной карте).

Это ограничение существенно усложняет жизнь разработчикам, когда требуется передать специфическую аналитику при синхронизации между базами данных (например, между сайтом, фронт-офисом и ERP) или сохранить кастомные признаки транзакций без снятия конфигурации с поддержки.

В этой статье мы подробно разберем, почему возникла эта ситуация, проанализируем архитектурные особенности подсистемы свойств БСП (Библиотеки Стандартных Подсистем) и рассмотрим три практических сценария решения проблемы: от временного обходного пути без программирования до штатного исправления от фирмы «1С».

---

Почему в ERP 2.4 отсутствует табличная часть дополнительных реквизитов?

Выясним первопричину. В платформе «1С:Предприятие 8» и типовых конфигурациях за работу со свободными реквизитами отвечает подсистема БСП «Свойства». Она разделяет кастомные поля на два принципиально разных типа:

  1. Дополнительные реквизиты — визуально выглядят как обычные реквизиты на форме документа. Физически они хранятся внутри самого объекта базы данных в специальной табличной части с именем ДополнительныеРеквизиты.
  2. Дополнительные сведения — также заполняются пользователем, но хранятся отдельно от документа — в независимом регистре сведений ЗначенияСвойствОбъектов.

Разработчики фирмы «1С» проектируют метаданные с учетом оптимизации производительности и размеров таблиц СУБД. На момент выпуска линеек ERP 2.4 документ ОперацияПоПлатежнойКарте не был включен в список объектов, поддерживающих локальные доп. реквизиты, так как это требовало создания дополнительной таблицы для каждого документа в базе данных. Предполагалось, что кассовые и эквайринговые документы являются строго регламентированными и не требуют частой кастомизации со стороны пользователей.

---

Вариант решения №1: Использование «Дополнительных сведений» (без программирования)

Проанализируем самый быстрый и безопасный способ обхода проблемы, который не требует изменения метаданных конфигурации и отлично подходит для задач синхронизации.

Поскольку дополнительные сведения хранятся во внешнем регистре сведений ЗначенияСвойствОбъектов, для их привязки к документу конфигураторам не требуется изменять структуру самого документа ОперацияПоПлатежнойКарте. Достаточно, чтобы этот документ входил в состав определяемого типа ОбъектСвойств.

Шаги по настройке дополнительных сведений для документа:

  1. Перейдите в раздел Администрирование -> Общие настройки -> Дополнительные реквизиты и сведения.
  2. Убедитесь, что флаг Дополнительные реквизиты и сведения активен.
  3. Перейдите по гиперссылке Дополнительные сведения.
  4. В списке найдите группу документов Операция по платежной карте.
  5. Нажмите кнопку Добавить -> Новое и создайте необходимое свойство (например, «ID_Транзакции_Сайта» или «Код_Синхронизации»). Настройте тип значения (Строка, Число, Ссылка на справочник).

Теперь пользователи смогут заполнять это поле прямо из формы документа по кнопке Еще -> Дополнительные сведения.

Как программно прочитать или записать дополнительное сведение при синхронизации:

Для чтения этих данных в правилах обмена или коде интеграции нам понадобится написать простой запрос к регистру сведений. Рассмотрим пример кода:


// Пример получения значения дополнительного сведения для документа
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	ЗначенияСвойствОбъектов.Значение КАК ЗначениеСведения
    |ИЗ
    |	РегистрСведений.ЗначенияСвойствОбъектов КАК ЗначенияСвойствОбъектов
    |ГДЕ
    |	ЗначенияСвойствОбъектов.Объект = &ДокументСсылка
    |	И ЗначенияСвойствОбъектов.Свойство = &СвойствоСсылка";

// Передаем ссылку на наш документ "Операция по платежной карте"
Запрос.УстановитьПараметр("ДокументСсылка", СсылкаНаДокумент);

// Находим нужное свойство в Плане видов характеристик
СвойствоОбъекта = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию("ID_Транзакции_Сайта");
Запрос.УстановитьПараметр("СвойствоСсылка", СвойствоОбъекта);

Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
    ЗначениеПараметра = Выборка.ЗначениеСведения;
КонецЕсли;

Этот способ полностью решает задачу передачи аналитики, не нарушает обновление базы и гарантирует стабильность работы системы.

---

Вариант решения №2: Использование расширений конфигурации

Если бизнес-требования категорически настаивают на том, чтобы поле находилось непосредственно на форме документа (как это реализовано для других документов через дополнительные реквизиты), можно прибегнуть к механизму расширений платформы «1С:Предприятие 8.3».

Однако на старых версиях платформы, под управлением которых работает ERP 2.4, добавление собственных табличных частей через расширения имеет существенные недостатки:

Поэтому данный путь является наиболее трудоемким и наименее рекомендуемым для долгосрочного использования.

---

Вариант решения №3: Переход на актуальные версии ERP 2.5 / 2.6 (Рекомендуемый)

Хорошие новости для тех, кто сомневался, стоит ли писать обращения в техническую поддержку фирмы «1С». Обращения пользователей по данной проблеме были услышаны и официально зарегистрированы.

Начиная с релизов линейки 1С:ERP Управление предприятием 2.5.7 (в частности, 2.5.7.150 / 2.5.7.203) и выше, разработчики добавили табличную часть ДополнительныеРеквизиты для целого ряда кассовых и банковских документов, включая ОперацияПоПлатежнойКарте и ОперацияПоЯндексКассе.

Что это дает на практике?

Если ваша компания планирует или уже осуществляет переход на новые версии ERP 2.5 или 2.6, вы сможете отказаться от временных схем с дополнительными сведениями и переписать правила обмена на стандартное использование табличной части ДополнительныеРеквизиты.

---

Резюме и рекомендации

Подведем итог нашему анализу:

  1. Если вы вынуждены оставаться на версии ERP 2.4, оптимальным, самым стабильным и безопасным решением является использование механизма Дополнительных сведений. Это позволит вам настроить обмен данными без изменения конфигурации и без риска повредить структуру СУБД при обновлении.
  2. Если перед вами стоит задача реализации сквозного учета и вы планируете развитие системы, инициируйте обновление конфигурации до актуальных версий ERP 2.5/2.6. В них проблема решена на уровне платформенного кода вендора, и весь необходимый функционал доступен в типовой поставке.
← На главную