База знаний

Фильтр
[+]

Рубрики:
Выбрано 656 материалов
Олег Башкатов
17.11.2013, 20:19
Олег Башкатов:

Комментарий 1.

При пояснении шага 4 (Настройте Вашу программу печати) автор предлагает сказать текст ABAP-кода, однако не приводит код в электронном виде. Для возможностей использования кода в электронно-текстовой форме (а не графической) привожу созданный автором кусок ABAP-кода.

Комментарий 2. 

При создании программ по отправке документов в качестве pdf-приложения весьма разумно использовать класс CL_BCS.
Пример использования данного класса есть в стандартной системе SAP ERP в программах:
BCS_EXAMPLE_5 (BCS-использование, пример 5 (приложение Winword)),
BCS_EXAMPLE_6 (Отправка PDF‑формуляра по мэйлу).
По поводу отправки писем из SAP есть замечательная справка на портале wiki.sdn.sap.com по адресу: 
 
 
Александр Сырчин
17.11.2013, 17:56
Александр Сырчин:
Предложенный автором статьи подход по процессу ведения сотрудников, занимающих несколько штатных должностей, решает поставленные задачи, но если вписывать его в общую систему взаимоувязанных процессов HCM, то он несет определённые риски, его можно применить на практике в России, но могут возникнуть следующие вопросы:
 
  1. В рамках интеграции PA\OM в части PA соединение A008 имеет четкое отражение в инфотипе 0001 «Организационное присвоение». В одно и то же время, по табельному номеру(лицу) может существовать лишь одна запись этого инфотипа. Т. е. с точки зрения PA, сотрудник может занимать одну штатную должность. Та штатная должность, которая была введена в приведенной статье первой и будет той штатной должностью, которую в PA занимает сотрудник (назовем ее «основной»). Все группировки персонала (раздел, подраздел, группа, категория персонала), которые используются в процессах PA, PT, PY (не только для определения тарифной ставки) по умолчанию будут копироваться из «основной» штатной позиции. Соответственно, возникает необходимость из нескольких штатных позиций, которые занимает сотрудник корректно определять «основную» штатную позицию. 
  2. На практике кадровые процессы — прием, перевод, увольнения и другие, в рамках которых производится изменение организационного присвоения, —  выполняются в рамках мероприятий PA (тр. PA40) . Применение подхода, описанного в статье, приведет к пересмотру данных кадровых процессов. 
  3. Стандартная отчетность, основанная на ЛБД PNP,PNPCE не поддерживает обработку неосновных штатных позиций. Это необходимо учитывать при разработке пользовательских отчетов, а также при расширении стандартных отчетов.
  4. Нет операции установления основной штатной должности из неосновной. Т.е., например,  для того чтобы сделать вторую должность основной, необходимо будет удалить соединение с первой, а потом его восстановить.

На практике обычно используется инфотип «Распределение затрат», а для отражения связи сотрудника со штатными должностями дополнительные пользовательские соединения в OM, а в части PA — пользовательский инфотип.

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

Александр Сырчин
17.11.2013, 16:55
Александр Сырчин:
Нельзя представить эффективную систему безопасности без применения структурных полномочий. Разграничение доступа к инфотипам объектов организационного менеджмента и развития персонала в рамках одной роли или одного пользователя невозможно без применения структурных полномочий.
 
Что касается применения к  разграничению доступа к инфотипа администрирования персонала, на практике встречаются решения с использованием поля «ключ организации» (объект P_ORGIN). Стандартное примените этого поля достаточно ограничено, но, расширив правило заполнения поля, можно добиться необходимой гибкости. Например, запрещать доступ на просмотр инфотипа 0008 по определённым должностям или подразделениям. Но это решение, безусловно, проигрывает структурным полномочиям в части администрирования (сопровождения) решения.
 
Зачастую, компании, использующие структурные полномочия, не используют на практике контекстно-зависимый подход и присвоение профилей структурных полномочий через объекты орг. структуры ввиду отсутствия необходимости применения на этапе проектирования системы HR-безопасности. В перспективе же, по мере усложнения матрицы ответственности, это приводит к тому, что задачи обеспечения надежности на требуемом уровне становятся более затратными.
 
Принципы использования структурных полномочий, описанные в статье, значительно помогают уменьшить затраты на администрирование, обеспечивая необходимую гибкость и надежность.  Максимально используя возможности, предоставляемые SAP, можно построить эффективную систему HR-безопасности, избежав в будущем дополнительных серьезных затрат на ее сопровождение. Это важно понимать на этапе проектирования концепции полномочий HR-системы.
Иваненко Игоревич
17.11.2013, 14:03
Иваненко Игоревич:
Читателям, которым интересна информация, которая изложена в данной статье, может быть, крайне полезно узнать о стратегии развития приложений SAP Fiori и пользовательского интерфейса SAP решений в целом (SAP UX Strategy).
 
Примечание

SAP Fiori это набор Web‑приложений с простым и легким в использовании интерфейсом, которые обеспечивают доступ к наиболее часто используемым функциям SAP Business Suite, как со стационарных компьютеров, так и с мобильных устройств. SAP Fiori построен на базе стандартных технологий сервера приложений SAP Netweaver Application Server, что дает клиентам SAP возможность максимального использования ранее сделанных инвестиций в ИТ инфраструктуру и ее поддержку. В текущей версии SAP Fiori включает в себя 25 приложений, которые предоставляют доступ к наиболее широко используемым функциям SAP SAP Business Suite таким, как шаги согласования, информационные запросы и сервисы самообслуживания. (https://experience.sap.com/fiori )

 

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

По стратегии развития пользовательского интерфейса SAP решений (SAP UX Strategy) интересные материалы можно найти здесь: https://experience.sap.com/post/show/111 . Обратите внимание на размещенные на странице документы.

Олег Башкатов
19.10.2013, 20:59
Олег Башкатов:
"
Целью является усложнить задание для опытных пользователей.
"
 
Хорошее оправдание для "кривых" инструкций :-)
Александр Дублин
15.10.2013, 11:49
Александр Дублин:
Дмитрий, спасибо за замечание. Исправили.
Дмитрий Карпов
08.10.2013, 18:58
Дмитрий Карпов:
Статья обрывается на таблице 4. Где табл.5 и дальше?
Дмитрий Карпов
03.10.2013, 13:57
Дмитрий Карпов:
Поставщик создает прогноз для клиента и не согласовывает его с последним. С точки зрения бизнеса это несколько неадекватно. Ничего не сказано про горизонты. Представляется, что процесс должен выполняться в два этапа - на месячном горизонте с потроением прогноза спроса клиентом и доведением его до поставщика и оперативном дневном с учетом точки заказа и расчетом размера партии. Точка заказа, понятное дело, рассчитывается на первом этапе. При наличии сети клиентов предпочтительнее использовать оптимизатор распределения.
Если работать по предложенной схеме, то нужно каждый день DP гонять, который внутри месяца вряд ли сможет что-то точно показать.
Кис ван Вестероп
25.08.2013, 21:35
Кис ван Вестероп:

В рамках проектов я использовал транзакцию MR11 только для выравнивания перерасчетного счета ПМ/ПСч и только в случае, если значения ПМ/ПСч были верными. Я согласен с тем, что не стоит использовать эту транзакцию для корректировки значений ПМ/ПСч. Но я хотел бы заметить, что ее целью является выравнивание перерасчетного счета ПМ/ПСч, без чего невозможно будет закрыть и архивировать связанные заказы на поставку.

Иваненко Игоревич
25.08.2013, 21:15
Иваненко Игоревич:

Автор статьи утверждает, что бОльшая часть стандартных мобильных приложений для повышения производительности труда специалистов по управлению логистической цепочкой может быть использована с минимальной доработкой. Это особенно справедливо и актуально, если у Вас внедрена достаточно современная версия SAP ERP (SAP ERP, SAP HCM, SAP SRM) системы и процессы настроены в рамках стандартных лучших практик.

Рекомендую обратить внимание на продукт SAP Fiori, который вышел после написания Автором данной статьи. SAP Fiori отлично укладывается в описанную автором парадигму и может служить хорошим началом для перехода к мобилизации предприятия и к управлению логистической цепочкой с помощью мобильных приложений на базе решений SAP.

С описанием функциональности приложений SAP Fiori вы можете ознакомиться в моей статье, опубликованной на портале www.sapland.ru .

Контактная информация

Если Вы хотите узнать больше или заказать сервис по внедрению SAP Fiori, - пожалуйста, пишите нам, мы будем рады помочь:

Igor.ivanenko@sap.com

alexey.kokin@sap.com

Михаил Савкин
29.07.2013, 17:25
Михаил Савкин:

Экспертные комментарии к статье : Введение в моделирование и создание отчетности с помощью SAP HANA

SAP HANA : Взгляд на архитектуру

Несмотря на новую архитектурную и прикладную концепцию, комплекс НАNA не является первым решением SAP в области ‘in-memory’. Такие приложения как : APO – Advanced Planer and Optimazer, BWA – Business Warehouse Accelerator, SAP NetWeaver Enterprise Search существуют уже несколько лет. Поэтому можно сказать, что новая волна ‘in-memory ’ – приложений от SAP основывается на хорошо проверенной и опробованной технологии.

С технической точки зрения HANA представляет собой систему, состоящую из аппаратной части(комплекса blade –серверов на базе архитектуры Intel Nehalem-EX CPU) и программного обеспечения SAP, поставляемую в виде предконфигурированного комплекса. Такой подход позволяет с наименьшими усилиями интегрировать комплекс в существующую инфраструктуру компании. Программная часть комплекса состоит из трех элементов. Первый элемент – инструмент моделирования, определяющий, какие данные и из каких источников будут присутствовать в HANA. Вторая составляющая – инструменты загрузки данных, задающие правила перемещения данных в HANA. Третий элемент является наиболее интересной частью – это база данных ‘in-memory’, способная хранить огромные объемы данных и обрабатывать их с высокой скоростью. Она является гибридной базой данных, хранящей информацию как в поколоночной модели хранения, так и в традиционной построчной. Именно об этой базе, которая получила в SAP название IMCE (In-memory Computing Engine), я и хотел сказать в своем обзоре несколько слов. Несмотря на то, что в первой версии решения база данных IMCE выполняет роль только репозитория аналитической информации, она разрабатывалась как SQL ANSI 92 –совместимая база данных , с полной поддержкой требований, предъявляемых к транзакционной системе ACID(Атомарность, Изолированность, Долговечность). В ближайшем будущем IMCE в составе HANA должна полностью заменить традиционные базы данных, находящиеся под управлением SAP BW и SAP ERP. Таким образом, IMCE, работающая полностью в оперативной памяти, станет выполнять роль механизма хранения данных всех систем, причем как аналитических, так и транзакционной информации. Стоит ли говорить о том, насколько большое значение имеет многократное увеличение скорости работы хранилища данных SAP BW и учетной системы SAP ERP? Ценность такого подхода заключается и в том, что организация сохраняет всю свою инфраструктуру, экономя существенные финансовые средства при технологическом развитии ландшафта. Говоря о IMCE хотелось бы особо отметить важную часть новой платформы – так называемый ‘Сalculation Engine’, или о машине расчетов, которая является неотъемлемой частью IMCE. Такой подход “совмещения ” механизмов хранения и обработки позволяет выполнять ресурсоемкие операции над данными непосредственно в IMCE, те непосредственно в оперативной памяти, значительно сокращая обмен данными между БД и уровнем приложения. Чтобы продемонстрировать, насколько важен этот принцип, разберем его на простом примере в области планирования.

Представим, что в сводный бюджет организации вносится корректировка планового значения по одному из дивизионов на следующий год. Что в этом случае происходит сейчас, при традиционном подходе? Система планирования, работающая на отдельном сервере приложений, определяет разницу (X), выполняет дисагрегацию этой велечины по неделям (52) и по входящим в дифизион подразделениям (пусть будет 100). Итого получается X*52*100 комбинаций (те новых значений), которые должны быть записаны. Далее сервер приложений начинает инициировать данное количество операций для записи в БД. Неудивительно, почему пользователи часто жалуются на производительность системы бюджетирования! Теперь посмотрим, как с этой задачей будет справляться HANA. Система произведет одну единственную операцию записи в базу IMCE, сопровождая ее инструкцией для дисагрегации.

Далее процесс разбиения по неделям и подразделениям и последующая запись полученных X*52*100 комбинаций будет выполнятся в одном месте – в оперативной памяти сервера.

Использование подобного подхода позволит значительно увеличить производительность не только систем планирования и бюджетирования, но все ключевые информационные системы от SAP, включая BI,DWH,ERP,CRM и тд.

Алексей Зимин
29.07.2013, 17:07
Алексей Зимин:

Статья, на мой взгляд, очень полезная, так как демонстрирует правильный общий подход к внедрению SAP HANA. В ней охвачены как техническая часть, так и экономическая целесообразность и организационные мероприятия. С точки зрения техники правильный акцент сделан на том, что при всей инновационности HANA, все технологии, на которых она основана (я бы, в отличие от автора, выделил другие 3 кита - колоночное хранение (сжатие - его следствие), in-memory и параллелизация) достаточно давно известны в индустрии СУБД. И если для маркетинга это звучит, может быть, не очень ярко, зато с точки зрения внедрения и непредвзятой оценки дает намного больше уверенности что это не маркетинговая пустышка, а реальная работающая технология.

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

Что касается вопроса использования текущих людских ресурсов, их знаний и навыков и проблемы перехода на HANA, то благодаря тому, что HANA, с точки зрения разработчика, просто SQL СУБД, оказалось, что после прохождения базовых курсов, разработчики и архитекторы достаточно быстро осваивают новую технологию.

Надо отметить, что статья опубликована полгода назад и за это время в стремительно развивающейся HANA произошли существенные изменения. Ключевым моментом стал официальный релиз SAP Business Suite on HANA в мае этого года, то есть то, что в статье описано как относительно далекое будущее стало реальностью. А именно, теперь можно переводить существующие решения на базе SAP ERP с традиционных реляционных СУБД на HANA.

В целом сейчас доступны три основных сценария:

1. BW on HANA

2. Business suite on HANA

3. HANA Standalone в качестве хранилища данных, с загрузкой в режиме онлайн при помощи SLT или при помощи Business Objects Data Services и с технической точки зрения клиент вправе рассмотреть любой подходящий ему вариант.

Вторым немаловажным моментом, бурно развивающимся параллельно технологическим достижениям, является политика лицензирования.Не секрет, что до последнего времени стоимость лицензий на HANA, например, для BW была весьма высока и лицензирование велось от объема RAM, в результате для больших БД, даже с учетом сжатия, цена получалась весьма внушительная. Однако с выходом Business Suite on HANA ситуация резко изменилась - в тот же день было объявлено о лицензировании HANA по той же цене, что и СУБД Oracle - 15% от стоимости лицензий, вне зависимости от объема данных! А в мае и июне прошло еще несколько маркетинговых акций, предлагающих похожую модель лицензирования и для BW! Для многих компаний это резко снизило стоимость лицензий и таким образом упростило обоснование экономической целесообразности, о которой ране шла речь.

Этот пример иллюстрирует комплексность задачи по построению архитектуры на SAP HANA. Необходимо одновременно учитывать и технические аспекты, и требования бизнес-заказчика и такие нетехнические моменты, как нюансы лицензионной политики, иначе грамотно выстроенное техническое решение рискует оказаться экономически неэффективным.

С учетом относительной молодости продукта и наличия массы нюансов, я бы рекомендовал привлекать к проекту перевода на HANA специалистов SAP или официальных партнеров.

Каглик Дмитрий
16.07.2013, 13:30
Каглик Дмитрий:
Хотелось бы уточнить, что такое "событие 940"? В моей системе ECC6  EHP4 SP11 такого нет...
Олег Точенюк
16.07.2013, 00:07
Олег Точенюк:
Пытался читать, но похоже статья переведена переводчиком, который ничерта не понимает в том что переводит, порадовала "долларовая цена", а какая еще цена должна быть у Роберт А. Джексона работающего в проекте для ВМС США? Хотя я просто может чего-то упустил и США уже присоединились к таможенному союзу и отменили доллары. Далее переводы видов движений, 561 - неожиданная прибыль, тоже сильно порадовало, потому что как потом будет объяснено почему разорван баланс, я даже не знаю, вряд ли прокатит фраза, ой это неожиданная прибыль была :-), так как по умолчанию корреспонденция для данного вида движения связана в дебете с внебалансовым счетом. Хотя у автора или это переводчик решил, что 561 вид движения это запас который обрабатывается как якобы бесплатный?!? Вообще-то для бесплатной поставки есть специальный 511 вид движения.
 
Теперь вопросы к автору, он как-то шустро обращается с видами движений, радуют его замечания по поводу как влияют на цену виды движения 9* и Z*, которые находятся в пользовательской области видов движения и что у кого в системе работает с данными видами движения не знает никто. Далее управление ценой V или S, это вообще какой-то цирк, т.е. что тип цены привязан к виду материала, автор похоже не знает, так же как и не знает когда и для чего SAP рекомендует использование стандартной цены. Из транзакции изменения цены автор почему-то знает только MR21, а вот МR22 ему похоже не известна, кстати рассказывая про 103 вид движения, аналогично автор похоже не знает про 107 вид движения и т.д.
 
В общем очень неоднозначная статья и может лучше все таки почитать стандартный курс, у кого есть :-) а то как-то можете местами сильно запутаться.
Олег Точенюк
24.05.2013, 11:28
Олег Точенюк:
Рисунки не загружаются и не видны в тексте статьи
Татьяна Шевченко
15.05.2013, 17:38
Татьяна Шевченко:

Отдельно хочу отметить следующее: существует принципиальная разница по отражению курсовых разниц по оценке иностранной валюты и разниц от пересчета отчетности в валюту представления. Курсовые разницы от оценки иностранной валюты признаются в отчете о прибылях и убытках и влияют на финансовый результат. Разницы от пересчета отчетности в валюту представления на финансовый результат не влияют и отображаются в качестве отдельного компонента капитала. В примере, приведенном в статье, я бы создала балансирующий счет к каждой группе счетов отчета о прибыли и убытках и баланса; а для счетов доходов и расходов оценки, которые указываются при настройках счетов для пересчета (Рис.15 «Выбор счетов для пересчета сальдо»), указала счет капитала – Дополнительный капитал от разниц пересчета в валюту представления. Тогда проводка выглядела бы так:
Дт Балансирующий счет дебиторской задолженности…………………………………………..0 GBP…0 USD…4 EUR
Кт Дополнительный капитал от разниц пересчета в валюту представления………0 GBP…0 USD…4 EUR

(предположим, что средний курс за месяц: 1 USD = 1,27 EUR)
Дт  Дополнительный капитал от разниц пересчета в валюту представления……..0 GBP…0 USD…1,6 EUR
Кт  Балансирующий счет доходов от реализации…………………………………………………….0 GBP…0 USD…1,6 EUR
Дт Балансирующий счет доходов от курсовых разниц…………………………………………….0 GBP…0 USD…0,3 EUR
Кт  Дополнительный капитал от разниц пересчета в валюту представления……….0 GBP…0 USD…0,3 EUR

Поскольку доходы от реализации были отражены в функциональной валюте 80 USD, то разница от пересчета составила : 80*1,25 – 80*1,27 = 1,6 EUR. В функциональной валюте (и в основном регистре) никаких изменений стоимости не происходит – доходы от реализации остаются в первоначально признанном размере – 50 GBP*1,6 = 80 USD.
Доходы от курсовых разниц были отражены в размере 10 USD и 13 EUR (по курсу на конец периода при оценке иностранной валюты, Рисунок 18). По среднему же курсу пересчета иностранной валюты (1 USD = 1,27 EUR), 10 USD должны быть представлены как 12,70 EUR.

Общее представление примера в валюте концерна на 31.января:
Дебиторская задолженность……………………………………………………………………………………………………..100 EUR
Балансирующий счет дебиторской задолженности (при оценке иностранной валюты)……..13 EUR
Балансирующий счет дебиторской задолженности (при пересчете иностранной валюты)…..4 EUR
---------------------------------------------
Итого: Дебиторская задолженность на 31.01                                               50 GBP
50 GBP * курс 1 GBP = 1,8 USD          90 USD
90 USD * курс 1 USD = 1,3 EUR        117 EUR

Доходы от реализации…………………………………………………………………………………………………………………100 EUR                                                                                             
Балансирующий счет доходов от реализации (при пересчете иностранной валюты)…………1,60 EUR
---------------------------------------------
Итого: Доходы от реализации на 31.01                                                       50 GBP
50 GBP * курс 1 GBP = 1,6 USD          80 USD
80 USD * 1 USD = 1,27 EUR          101,60 EUR

Доходы от курсовых разниц (при оценке иностранной валюты)…………………………..……………………13 EUR
Балансирующий счет доходов от реализации (при пересчете иностранной валюты)………….0,30- EUR
---------------------------------------------
Итого: Доходы от курсовых разниц на 31.01                                                 0 GBP
50 GBP * курс 1 GBP = 1,6 USD  - 50 GBP * курс 1 GBP = 1,8 USD          10 USD
10 USD * 1 USD = 1,27 EUR            12,70 EUR

Дополнительный капитал от разниц пересчета в валюту представления……….0 GBP…0 USD…2,70 EUR

Рисунок 22

Пересчет иностранной валюты – баланс и отчет о прибылях и убытках

Олег Башкатов
25.03.2013, 01:10
Олег Башкатов:
ничего меня не мучает - не волнуйтесь.
 
в комментарии с мини-словарём (Вы наверное, заметили, но сказать-то что-то должны) уже было указано авторство.
 
Рад за Вас, за Вашу работу и за Ваше хобби, а также за их взаимоотношения. Мне бы так... :-)
 
А что такое PSS ?
это какое-то расширение файла для нового скриптового языка? или просто очередная грубость?
 
PS. Возможно, незаметно, но Ваши комментарии/мнения, меня не оскорбляют; я их встречаю с радостью. Комментируйте, что хотите и сколько хотите. Более того, я даже настаиваю, чтобы Вы комментировали (только 3ими лицами не надо прикрываться). Если я где-то обидел или зацепил, то имейте ввиду, что я не хотел этого делать.
 
Вот у меня к Вам вопрос по MR11. За весь Ваш многолетний опыт как часто Вы её[транзакцию] использовали?
Это были единичные случаи или обычная практика?
 
PPS. При попытке обоснования мнения, встретил старый добрый матерок...эх...
Олег Точенюк
24.03.2013, 23:22
Олег Точенюк:
... что Вас мучает, вот этого не пойму, Вы считаете себя великим саповодом в логистике в целом и в ММ в частности? Я не претендую на уровень ваших знаний. Я вообще SAP ERP не знаю, так отдельные моменты, которые делал и не больше, но это вряд ли более 5%-10%, от того что может система. Так что не переживайте, растите, учитесь, а я лично постараюсь больше не комментировать лично ваши опусы, только просьба в переводных статьях указывать свое авторство, дабы так сказать исключить и не усугуБлять. Мои можете комментировать, не возражаю.
 
PS: Что касается работы, то мне нравится то, чем я занимаюсь, и мне нравится, не все конечно, но в целом как это сделано в SAP ERP, поэтому не вижу никакой проблемы в том, что мое хобби совпало с моей работой и могу себе позволить получать от этого удовольствие.
 
PSS: Что касается ПМ/ПС меня не тра@ает ваше мнение, а с господином Дублиным я и без ваши 5 копеек разберусь, его в отличии от вас, чужое, отличное от его мнение, не оскорбляет.
 
----
Ну и администрации, просьба не удалять мой комментарий, мне за свои слова не стыдно, кто что подумает мне все равно :-) у меня есть свое мнение и 5 копеек и я этого не стесняюсь.
Олег Башкатов
24.03.2013, 12:07
Олег Башкатов:
Олег Витальевич,
 
откройте транзакцию sterm и убедитесь, что входящий счёт - это разрешенный синоним к термину "поступление счёта-фактуры" и его можно трактовать как Invoice Receipt.
 
Поэтому Ваше утверждение: "противоречение возникает при использовании сокращения ВС вместо ПС" - очередная безосновательная ложь (т.е. не истина). Вернее, в качестве основания выступает только Ваше специфическое рассуждение.
 
И еще: овладейте Вы терминологией SAP, а не Вашей собственной. То, что Вы называете "событием" имеет вполне нормальный термин - операция.
В OBYC и в истории заказа на поставку так и отображается.
 
И то, что Вы называете "противореЧЕНИЕМ" в данном случае, максимум, можно назвать (следуя Вашей же логики) несопоставимостью.
 
Но опять же в случае MR11: у нас 2 каких-то штуки породили проводки.
Первую штуку я перевел как поступление материала.
вторую штуку: входящий счёт.
Противоречия нет никакого; смысл сохранился и суть ясна.
 
PS.
Сочувствую Вам, что Вам заняться нечем в 11 часов вечера в субботу; кроме как давать комментарии к моему комментарию.
Олег Точенюк
23.03.2013, 23:06
Олег Точенюк:
Ну тут как-то противоречение возникает при использовании сокращения ВС вместо ПС, потому что первое сокращение ПМ - поступление материала, тогда логично, что второе сокращение ПС - поступление счета, как событие. Сокращение ВС - если читать как входящий счет, в таком случае ПМ нужно было бы сокращать как-то типа ДМ -  документ материала или ТН - товарная накладная. В общем все таки ПМ/ПС наверное более точно будет.