Олег, привет!
 
В статье под Клиентом подразумевается - любой потенциальный клиент на рынке. А вот уже на основании его обращения в компанию, которое представлено в системе SAP CRM как входящее письмо, может быть создана сущность "Деловой партнер (ДП)" в CRM. И как следствие дальнейшее взаимодействие с Клиентом будет выполняться уже в привязке к сущности "ДП".

Не ну это ты через отладчик как-то жестоко решил сделать :-) к тому же базисники все больше окультуриваются и перейти в отладку, кроме системы разработки, никто не даст.

Т.е.только справочник МТР?
а контрагенты? МВЗ? МВП? план счетов?

Все материально-технические ресурсы потребляемые ОАО "РЖД"

Спасибо!
OTD хорошая идея. Возможно новый виток развития принесет "интернет вещей".
Какие объекты НСИ ведет служба в РЖДС?

К тому же для конструкции:
WRITE: /
itab_multi_comp[ kunnr = '123' ]-ort01.
нельзя будет забывать писать
TRY.
CATCH CX_SY_ITAB_LINE_NOT_FOUND.
ENDTRY.
Иначе, приведет к неминуемому дампу, если такой записи во внутренней таблице нет.

Статья интересная, но подразумеваемый в ней "новый подход" в ОАО "РЖД" используется с 2000 года ...
Перспективы развития систем НСИ. Основополагающие документы давно написаны - ГОСТ P 51725.(0-21),рекомендации  Р 50.5.(001-009),ГОСТ P 56214/ISO/TS 8000, ГОСТ P 56213/ISO/TS 29002, ГОСТ P ИСО 22745, а вот успешных внедрений с полноценным созданием открытых технических словарей  нет (по крайней мере не видел). Промышленных систем использующих математические алгоритмы (вероятностный поиск)  единицы. Большинство используют алгоритм Лёвенштайна и его модификации.
НСИ в составе которых имеются ФИО, координаты, адреса являются наиболее простыми.
Проблемные вопросы при внедрении проекта (рассматриваю справочник товаров). Основную беду при внедрении, вижу не в необходимости нормализации  (поскольку это  дело техники, времени и квалификации специалистов НСИ), а в необходимости согласования терминологической базы и последующем отстаивании позиций службой НСИ.
Примеры:
Что является комплектом, набором, восстановленной номенклатурой, отремонтированной, старогодней, агрегатом, индивидуальным заказом ... ?  
Со временем в компании появляется множество несвязанных организационно-распорядительных документов, которые оказывают косвенное влияние на правильность ведения НСИ и никак не согласовываются с причастными. Пример: порядок ведения инвестиционной программы,  предполагает жесткий регламент по срокам (при наличии рисков срыва сроков инвест. программы, качество данных уходит на второй план), стоимости заказа (происходит агрегация товара для обеспечения заказа через инвестиционный бюджет, рождается «чудо номенклатура»).    
Хотелось бы пообщаться с представителями организаций, у которых реализован параметрический (описаны свойства и характеристики оказываемых работ/услуги) справочник работ/услуг.

Не согласен с:
1. "Невозможно поддерживать и развивать фасетную классификацию всего справочника ТМЦ..." - более 1.5 млн. уникальных записей.
2. "...будет меняться и классификатор, и все позиции в нем". - Мы у себя реализовали некоторые из потребностей "бизнеса" и при этом ни одна позиция не поменялась.
Можно почитать на Wiki статью - СК-МТР
В Едином реестре российских программ для электронных вычислительных машин и баз данных № 7702178020

Да я просто не знаю, как бы статья не моя, наверное лучше чтобы автор продолжил раскрывать данную тему, ну как мне кажется.
 
Хорошо, буквально один пример, из приведенного выше, который я использовал в самом начале.
 
* Старый метод доступа
READ TABLE itab_multi_comp INTO ls_comp WITH KEY kunnr = '123'.
WRITE: / ls_comp-ort01.
 
* Новый метод доступа
WRITE: / itab_multi_comp[ kunnr = '123' ]-ort01.
 
На самом деле старый метод написан не правильно, эквивалент нового метода должен быть таким:
READ TABLE itab_multi_comp INTO ls_comp WITH KEY kunnr = '123' TRANSPORTING ort01.
 
т.е. вы фактически читаете значение одного поля. К чему это ведет с точки зрения производительности. В старой конструкции обычно читали всю запись, а дальше фактически вы могли работать со всеми полями считанной записи. В новой методике многие начинать писать так:
 
WRITE: /
itab_multi_comp[ kunnr = '123' ]-ort01,
itab_multi_comp[ kunnr = '123' ]-ort02,
itab_multi_comp[ kunnr = '123' ]-ort03,
itab_multi_comp[ kunnr = '123' ]-ort04.
 
Абап не умеет оптимизировать такие конструкцию, фактически это приводит к 4 последовательными чтениям т.е. в старых терминах можно считать что будет выполняь следующий код:
 
READ TABLE itab_multi_comp INTO:
ls_comp WITH KEY kunnr = '123' TRANSPORTING ort01,
ls_comp WITH KEY kunnr = '123' TRANSPORTING ort02,
ls_comp WITH KEY kunnr = '123' TRANSPORTING ort03,
ls_comp WITH KEY kunnr = '123' TRANSPORTING ort04.
 
Как можно понять производительность при этом проседает, хотя написание кода более короткое и визуально воспринимается проще.

Екатерина, здравствуйте,
 
Могли бы Вы уточнить, к какому решению относятся ракурсы ZTEDT_DOCTYPE и ZTEDT_PROCEDURE. Как я понимаю, эта часть настроек не относится к SAP-стандартным.
 
Также добавлю, что возможность активации FIN_LOC_CI_41 FI, LO Localization Topics for Russia 8 существет только для версий старше EHP 7 SP4 и EHP 6 SP12

Наталья, спасибо за интересную статью.
Было бы интересно ознакомиться с вашим опытом взаимодействия с ЭТРАН в части расчёта провозной платы (Прейскурант № 10-01).

Олег, добрый день. Если не трудно, напишите плз, какие возникают проблемы при использовании нового синтаксиса? ( не считая того , что надо использовать TRY..  ENTRY ).  Чисто практический интерес..

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

Ознакомить то оно конечно полезно, только в таком виде лучше бы не делать этого. А то ведь послушают вас и возьмут на вооружение, например предложенный вами последний пример:
 
* Старый метод доступа
READ TABLE itab_multi_comp INTO ls_comp WITH KEY kunnr = '123'.
WRITE: / ls_comp-ort01.
 
* Новый метод доступа
WRITE: / itab_multi_comp[ kunnr = '123' ]-ort01.
 
а потом плакать будут, окружающие, ну зато мне работы может подкинут :-) в перспективе, так как суть старого и нового методов различна и сравнивать их в таком виде очень не рекомендуется, а вы вот сравниваете и не понимаете в чем существенная разница.

Андрей, спасибо за статью!
 
Проясните, пожалуйста, что Вы понимаете под клиентом в данной статье: это Дебитор/бизнес-партнер в CRM/ERP или это любой потенциальный клиент на рынке?