Опыт штука хорошая, но иногда бывает полезнее прочитать, написанное кем-то, причем уже давно :-) А потом уже изобретать вИлосИпеду... кстати там как раз чистый запад, но грабли и мысли у автора те же.
 
Для начала:
sapland.ru/books/sinyaya-kniga-sap-kratkii-biznes-putevoditeli-po-miru-sap.html
 
Ну и дальше:
sapland.ru/books/zelenaya-kniga-sap-biznes-rukovodstvo-po-upravleniyu-zhiznennim-tsiklom-sap.html
 
Красную еще не перевели, но можно если очень хочется купить ее в английском варианте.

Красные кнопки и педальки - это прошлый век. С современным развитием программ по распоясыванию голоса нужен просто микрофон. В него четко говорить: "Оборотка по 30-ым счетам за первый квартал 2017" Тогда руки и ноги можно полностью освободить.

Приведите пример любого подшипника по гост в разрезе фасетов СК-МТР

если продуктив упал с грохотом - использовать отладку уже поздно...
 
из твоей фразы вижу, что полномочия были ограничены именно у тебя, а не в целом у всех в системе. полагаю, что не нужно говорить "лишнего/жестокого" в адрес базиса - тогда и с полномочиями будет ок и с ключами на формулы проблем не будет.

1. Имею в виду не продуктивны системы. Но даже в тестовых/контроль качества в последнее время довольно жесткие ограничения на отладку.
 
2. Отладку не дают, от слова вообще. А процедура заключается в том, что конечно если продуктив упал с грохотом, то к сожалению это не случай получения журнала SM35. Хотя и в том случае меня пустили так, что местный сотрудник получил доступ и нажимал кнопки, а я типа говорил что и смотрел.

1) под системами разработки ты имеешь ввиду именно системы разработки или "не продуктивные системы" (т.е. контроль качества, тестирование, песочница и т.д.) ?
 
2) а в чем "жестокость" отладки в продуктиве заключается по твоему мнению? именно отладки (а не изменение под отладкой), т.е. объект полномочий S_DEVELOP, ACTVT = 03 (а не 02).
 
по моему мнению "жестокости" нет и даже у самого строгого базиса всегда есть процедура предоставления прав на отладку в продуктиве (процедура может быть простой - просто включить /h, а может быть сложной - через согласование, но она есть).

Олег, привет!
 
В статье под Клиентом подразумевается - любой потенциальный клиент на рынке. А вот уже на основании его обращения в компанию, которое представлено в системе 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).