Бывают задачи, для решения которых необходимо сформировать «собственные» документы в системе на основе проведённых пользователем документов, так называемые «паровозики». Техника формирования таких документов может быть различной. Но существует общая проблема: последующая работа с ними - нахождение связанных документов. Чаще всего для этой задачи пишутся какие-то отчёты или, если связь определяется через назначение номеров документов в стандартные поля (например, ссылочный номер документа), то можно использовать стандартные отчёты. Впрочем, удобство использования стандартных отчётов сомнительно, так как «массовое» сопоставление связей оказывается ненаглядным.

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

Первой проблемой в системе является то, что номер транспортной заявки будет виден в документе движения материала, однако перейти к просмотру подробных данных из документа движения запасами нельзя, см. пример на Рис.1.

Рис.1 MIGO-01

Вторая проблема, даже если к транспортной заявке будет создан транспортный заказ, его не будет видно из документа системы управления запасами, хотя, если перейти к просмотру транспортных заказов, то транспортный заказ имеет ссылку на документ движения материала, Рис.2.

Рис.2 LT23-01

Задача заключается в том, чтобы добавить возможность просмотра связных документов системы управления складом с документами движения материалами.

Самым оптимальным и, наверное, логичным способом будет возможность использования RWIN-интерфеса связи документов. В общем виде это работает следующим образом, когда вы в документе логистики, например, выбираете кнопку «Док. RW», Рис.3.

Рис.3 MIGO-02

Система откроет окно, в котором будет отображен перечень связанных документов. В этом случае, как видим, это документы модуля финансов, контролинга и документ специальных регистров. Так как документы управления складом являются связанными с документом логистики, то было бы неплохо отражать их в стандартном окне с возможностью перехода к просмотру таких документов. Для этого необходимо выполнить несколько настроек в системе и реализовать функциональный модуль, который будет формировать связанные документы управления складом.

Для создания собственных объектов сначала необходимо создать в системе компонент RW-интерфейса и тип ссылочного объекта/операции. Не знаю по каким причинам, но просто внести новый код компонента система не позволяет, так перечень допустимых значений ограничен доменом, на которое ссылается поле таблицы компонентов, Рис.4. Думаю, что это остатки каких-то устаревших разработок, о которых давно забыли, но теперь это создает проблему — мы не можем внести собственный компонент для RW-интерфейса в таблицу TRWCI, хотя она просто содержит перечень кодов, с которыми происходит дальнейшая работа.

Рис.4 SE11-01

Однако, с версии системы 6.0 у нас появилось замечательная возможность расширения постоянных значений для доменов системы без использования ключа модификации объекта. Для этого в просмотре данных домена по меню выберите: «Перейти к» - «Дополнение к фиксированному значению», Рис.5.

Рис.5 SE11-02

После выбора создания дополнений вам нужно будет создать новый объект расширения, например ZI_WMS, Рис. 6. Фактически будет использована стандартная возможность расширения объектов системы.

Рис.6 SE11-03

Создадим новые значения к домену и активируем изменения, Рис.7. Ключ нашего объекта будет ZWMS, так как длинна поля 4 символа.

Рис.7 SE11-04

Теперь можем перейти к ведению созданного кода в ракурсе TRWCI, для этого перейдём в транзакцию SM30 и добавим собственный ключ объекта в перечень уже существующих компонентов, в списке предлагаемых значений появится код ZWMS, Рис.8. Внесем созданный нами код в перечень компонентов системы и сохраним изменения. Система запросит данные транспортного запроса, чтобы данные настройки можно было перенести в другие системы.

Рис.8 SM30-01

Рис.9 SM30-02

Примечание: К сожалению, на рисунке полностью введенный код не видел, так как ракурс ведения не настроен по ширине вывода данных таблицы.

Далее для созданного компонента  нужно установить «максимальный» год действия и признак активности RW-компонента. Для этого переходим к ведению ракурса TRWCA, в транзакции SM30, и добавляем новую запись с кодом ZWMS, Рис.10. Год ставим, например 2999, чтобы точно хватило и конца действия не дождались. Конечно, 2999 год - это очень оптимистично.

Рис.10 SM30-03

Далее зарегистрируем наш объект в связи с кодом момента вызова. Для этого в транзакции ведения ракурсов SM30, перейдем к ведению ракурса TRWPR. При входе будет системное предупреждение, что ракурс общий для всех мандантов, а далее будет выведено окно с правилами нумерации. Для клиентских разработок стандартно открыт интервал 900 — 999, Рис.11.

Рис.11 SM30-04

В этом ракурсе мы должны создать запись с кодом операции DOCUMENT и событием RECORD, так как проводить связные документы нам не требуется, а вся работа будет заключаться только в демонстрации связных документов. Сам документы проводятся системой. За основу можем взять, например, запись с номером 10, Рис.12 и скопировать ее.

Рис.12 SM30-05

Номер операции