Добрый день! Помогите, пожалуйста решить проблему!

Анализирую данные в отчете по кубику OIC_C03 и вижу, например, что прямой документ (не сторно!) со сторнирующим видом движения - 262 попадает как минус по отпуску, а хотелось бы его данные увидеть в поступлении. Понятно, что делается это в соответствии с таблицей T156 по полю XSTBW.
Вопрос: а как стандартными средствами (без расширений) можно получить реальную картину по данным с учетом сторнирующих движений.
Случаи ведь могут быть разные:
1. Прямой документ - со сторнирующим ВД, сторно документ - с несторнирующим ВД.
2. М.б. цепочка: документ - сторно документ - сторно сторно документа и т.д. много раз.
Как в бизнес-контенте решается эта проблема?

Спасибо!!

Никто не знает???

Видимо, придется экстрактор расширять?!

Сторно на сторно и еще раз сторно.
Очень странная задача. Зачем по бизнес-логике поступления проводить обратными видами движения с минусом?
Или ваша конечная цель - исключение фиктивных оборотов?
Для начала можно попробовать завести признак - знак показателя "+"/"-" и на стороне BW строить логику отчета с учетом видов движений, знаков и т.п.
Расширять стандартный экстрактор хитроумной логикой под сиюминутные цели - неблагодарная задача.

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

Пример:
1. 262 ВД - сторнирующий, идет в BW минусом по отпуску. А если документ в этим видом движения в исходной системе был прямым, то это уже должен быть приход. Данных для анализа такой ситуации в BW нет, экстрактор их просто не передает.

Конечно! Поэтому и хотелось бы узнать, как можно выстроить правильную логику по сторнирующим документам стандартными средствами. Может нужно что-то настроить в SBIW? Коды транзакций тоже не дают возможности решить эту проблему.

Написать свой "правильный" экстрактор или сломать стандартный.
p.s. Больше всего не понимаю дурацкой панацеи с бизнес контентом, носятся вокруг него как вокруг золотой курицы. Посмотри как сделано в контенте, переделай под свои нужды и нет проблемы.

Видно так и придется сделать. Поскольку BI - львы мне другого выхода не предложили, будем думать, что его и нет.
Спасибо всем!

Имхо, первым делом пристально проверить, что возращает экстрактор для 262-го прямого и непрямого, действительно ли записи качественно идентичны. Если это так, и нет времени рыться в глубинах экстратора, то на экзите проставлять свою "галочку" в какое-нибудь неиспользуемое поле структуры для учета на стороне BW. Если же есть время и смелость, то можно проверить вариант с подменой значения в каком-то "серьезном" поле, например, Дб/Кр или знак суммы.

Увы, идентичны. Поле ROCANCEL - Индикатор: сторнирование записи данных заполняется в экстракторе не в зависимости от того прямой или сторнирующий документ (табл. MSEG). а в зависимости от настройки вида движения (для нашего случая 262): сторнирующий ВД (табл. T156 поле XSTBW) или нет.

А вот и нет. ROCANCEL это поле для организации дельты. А дельта там : минус старое значение, плюс новое значение
ROCANCEL заполняется X для записей BeforeImage и пусто для записей AfterImage

До дельты пока дело не дошло. В тестовую систему выгрузили данные, какие реально уже есть.
ROCANCEL заполнен как X для сторнирующих ВД.
Или нет? Тогда в соответствии с чем?

Да, точно, в фуле тоже весь процесс изменений идет. Так а в чем собственно проблема? Вам нужно не вычитать отпуск, а увеличивать приход? А вариант вставить в трансформацию еще и разбор видов движений не подходит? Только какой же это приход если это сторно отпуска? Сейчас направление зависит от процесскея. Если у вас логика иная, то придется переделывать контент.

Это именно приход, но используется для прихода сторнирующий ВД для отпуска.
261-й - отпуск, а пользователи решили сделать приход 262 - м. Ну, захотелось! Система позволяет. А в экстрактор идет сторно по отпуску.




Анализ в правилах обновления (у нас верси 3.5) вида движения ничего не даст, т.к. не ВД определяет сторно документ, а наличие в нем ссылки на сторнируемый номер документа. В экстрактор эта ссылка не идет и ничего похожего, что можно было проанализировать на эту тему похоже тоже.
Да, наверное, придется переделывать контент. Просто не верится, что такая очевидная вещь не была предусмотрена в контенте.

Контент делали индусы, привыкайте.

Layta, обязательно сообщите о своих успехах по доработке экстрактора.
Вообще я бы предложил сделать ABAP-отчет, где можно гибко обработать всю цепочку "сторно на сторно", а тете Глаше запретить оформлять приходы обратным движеним отпуска. Обычно после месяца-двух после разработки ABAP-отчета становится понятно о степени его востребованности. А так вы поломаете логистические экстракторы, отчет запустят пару раз, зажмурят глаза и больше о нем ни разу не вспомнят.