Олег,
1. Транзакция – CRMC_IC_AUIADDR, содержит электронные адреса для получателей почты в системе SAP CRM.
2. Транзакция - SO28, содержит мэппинг между электронным адресом, который заведен на почтовом сервере SMTP, и адресом получателя в системе SAP CRM.
3. ВАЖНО: С технической точки зрения, любое входящее письмо в системе SAP CRM оборачивается в BOR-объект (бизнес объект системы SAP). Для данного объекта запускается поток операций (work-flow), в котором на определенном шаге формируется задача (task). Именно данная задача является диалоговым шагом потока операций, который пользователи видят и обрабатывают в системе SAP CRM.
4. Именно поток операций (work-flow) определяет механизм, который будет использован для маршрутизации входящих писем. Как раз во второй статье и рассмотрен наиболее часто используемый такой механизм, называемый ERMS (система управления электронной почтой). Где маршрутизация может быть построена на основании таких критериев, как:
• адрес отправителя;
• адрес получателя;
• тема письма;
• содержание (текст) письма.
С Уважением, Андрей.

Андрей,
а как можно для любого потенциального клиента завести настройки в транзакциях CRMC_IC_AUIADDR и SO28 и использовать стандартную маршрутизацию?
или была сделана еще дополнительная маршрутизация, которая использовалась в том случае, если предыдущие не отработали?
 
Дело в том, что я как-то решал сходную задачу и пришлось добавить немного своего кода, чтобы охватить все возможные ситуации.
 
Спасибо тебе за эту статью и за часть2 к этой статье.
 
sapland.ru/articles/stats

Порекомендовал бы создавать индексы по полям в клаузе WHERE. Выборка будет значительно быстрее, также рекомендую не использовать в WHERE конструкцию <>(не равно).

Порекомендовал бы создавать индексы по полям в клаузе WHERE. Выборка будет значительно быстрее, также рекомендую не использовать в WHERE конструкцию <>(не равно).

Добрый день, Илья! Спасибо, интересная и актуальная публикация! Совсем недавно нами проводился анализ подобного рода. Были найдены схожие с Вашими аргументы для выбора того или иного сценария. В ходе этой работы была сделана попытка сформулировать для самих себя выводы в какой-нибудь более-менее краткой форме, примерно так: если все данные лежат в HANA и нет иных аналитических задач, кроме оперативного мониторинга факта, то, да, вероятно, достаточно S/4HANA Analytics )

Спасибо за ваши комментарии!
Я ни разу не сомневался, что затронутая мною тема, уже поднималась и не раз. И тут я полностью согласен с Олегом Кашуба: Каждый раз одни и те же грабли. :)
Про микрофон - согласен, прогресс идет вперед. А дальше - виртуальный шлем и управление работой системы посредством мысли. :)

Олег. книги многие написаны, статьи пачками выходят, теоретически все подкованы. А на практике - опять те же грабли.
Так что повторение - мать учения.

Опыт штука хорошая, но иногда бывает полезнее прочитать, написанное кем-то, причем уже давно :-) А потом уже изобретать вИлосИпеду... кстати там как раз чистый запад, но грабли и мысли у автора те же.
 
Для начала:
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, а может быть сложной - через согласование, но она есть).