Илья.
Изменения остатков в задних числах фиксируются на уровне ETL. На вход поступают все остатки за каждый день с момента изменения в прошлой дате.
Мы отказались от расчёта остатков из проводок, как было в предыдущем решении. Вместо этого проводится контроль между оборотами по счетам, поступающих из структуры остатков и оборотами, собираемыми из проводок. Выполняется загрузка этих данных в куб с противоположными знаком. Агрегация данных в кубе сразу позволяет выявлять расхождения по дням по каждому счёту. Данный куб используется как средство внутреннего контроля Главной книги внутри BW.

>>идентификатором клиента, заказчика, поставщика, материала...
 
Т.е. если мы тут о SAP, то основная запись клиента и материала, вот тот вот набор полей и справочников предлагается перенести в BW систему? И следовательно там вести все эти справочники? Правильно?

То-то я смотрю, имена объектов знакомые ;)
Андрей, не увидел в вашем материале как вы обрабатываете изменения в заднем числе и проводки задним числом.

не знаю зачем, но почти на всех проектах данная возможность заблокирована :(
если нет, то ставлю прод - зеленый, тест - розовый, разработка - сине-зеленый

Мне казалось, что это уже давно известный факт, и всеми используемый )))

Спасибо за обзор.
Всем для информации - данная функциональность доступна с версий:
SAP NetWeaver 7 Enhancement Pack 3 и
SAP NetWeaver 7.3 Enhancement Pack 1

Отдельно хочу отметить следующее: существует принципиальная разница по отражению курсовых разниц по оценке иностранной валюты и разниц от пересчета отчетности в валюту представления. Курсовые разницы от оценки иностранной валюты признаются в отчете о прибылях и убытках и влияют на финансовый результат. Разницы от пересчета отчетности в валюту представления на финансовый результат не влияют и отображаются в качестве отдельного компонента капитала. В примере, приведенном в статье, я бы создала балансирующий счет к каждой группе счетов отчета о прибыли и убытках и баланса; а для счетов доходов и расходов оценки, которые указываются при настройках счетов для пересчета (Рис.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

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

1. Ну базиса когда нормального нет, приходится как понимаю извращаться.
 
2. Не надо трогать имя транзакции ZUSR, это стандартная транзакция генерации пользователей в IDES системах (User maintenance for SAP courses), не знаю почему использовали это имя, но видно как-то исторически что ли повелось.
 
3. Ну и как по мне, не кошерно трогать стандартное меню SAP. Сделайте свое меню в крайнем случае, ну или если кошерно, то через роли добавьте эту транзакцию в ролевое меню и будет всем счастье.

А чем изобретать такой велосипед, не проще было запустить один раз стандартный отчёт RSUSR200 ?

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

Пожалуйста. Согласен с Вами, действительно отличный инструмент. Из личного опыта знаю, что многие разработчики еще не смотрели что это, надеюсь, что статья поможет в его освоении.

Понял. Спасибо. Ставлю себе зачёт :-)

Спасибо, отличная вещь для отладки...

Ну стандартная транзакция ведения условий для закупки MEK1/MEK2/MEK3.

Добрый день Олег. Сами условия где прописывается, на 50 шт 20% скидки например?

Инструмент неплох бы был, но кажется как многое в системе, вышел, а потом про него забыли и забили, так что не очень актуален. Опять же в чистой ERP, есть всего три объекта, которые поддерживаются этой транзакцией, остальное только при наличии CRM.

Продуктив - синий (оригинал)
Тест - фиолетовый
Разработка - зеленый

Добрый день!
 
Очень полезная информация и очень хороший инструмент.
 
Так же возникли пару вопросов:
1. При переносе запроса в тестовую систему, не переноситься сам "Проект" в транзакции eewb, в таком случае как настраивать данные по справочникам (если настраивать справочники в DEV, при переносе выдает ошибку);
2. Как можно изменить тип данных по доменам/элементам данных, созданные с помощью EEWB.
Например, при создании полей (с помощью EEWB) инструмент предлагает "тип данных" только: CHAR, DATS and NUMC.
Для использование в расчетах, выщепредложенные тип данных использовать не получется, т.к. "не цифровые".
P.s.прямое изменение в SE11 не помогло, т.к. при генераций EEWB изначальные настройки возвращаются.
3. При создании таблицы предусмотрено только одно "Ключевое поле", как можно расширить если есть необходимость.
 
Спасибо!

Под эти цели еще можно GuiXT настроить.
При этом GuiXT системы различает не только по кодам систем (три буквы), но еще и по мандантам (или по тому и по другому).
 
Описывал здесь (комментарий внизу)
sapland.ru/articles/spj

Долгое время использовал для продуктива розовый, для теста зеленый, для разработки синий. В настоящее время предпочитаю ставить различные картинки на рабочий стол в ракурсе SSM_CUST. В продуктиве логотип компании, в тесте - картинка со словами тестовая система, в разработке - картинка с инструментами.