Добрый день, коллеги, может быть дилетантский вопрос, но хочу для себя уяснить: как используется признак recordmode при обновлении данных из источника данных в DSO.
Конкретный пример - есть источник данных, экстракция данных происходит на основе Z- таблицы, настроена дельта на основе определенного поля, на стороне BW есть инфопакеты инициализация дельты и дельта -процедура. Так вот меня как организовать ETL процесс таким образом используя recordmode, чтобы при удалении или обновлении записи в исходной системе, пришла дельта с этими записями и по признаку recordmode произошло либо удаление либо обновление записи по ключу в DSO?

Дополнение: на стороне источника данных: 1) Поле определяющее дельту - "Цифровой указатель" 2) Новый Статус для измененных записей. (AIE/AIM дельта процесс).

Если выставлено:То это работать не будет.
Допустим есть Ваша Z-таблица:
№ заказа Кол-во, тн.
10001_____100
10002_____100
10003_____100
В нее, к примеру, были добавлены, изменены и удалены записи и таблица приняла следующий вид:
№ заказа Кол-во, тн.
10001_____100
10003_____200
10004_____400
Если судить по Вашим настройкам дельты, то перенесется одна запись:
№ заказа Кол-во, тн.
10004_____400
Посмотрите вот эту статью. Как мне кажется она решит Вашу проблему.

О чем идет речь в статье в принципе понятно... Для конкретной реализации задачи может метод и хорош...
Тогда к делу, все мои поиски и расспросы в на форуме по тематики загрузки данных дельтой в конечном итоге были направлены на то, чтобы понять можно ли осуществить загрузку дельты стандартными средствами и реализовать свой процесс загрузки...
На данный момент передо мной стоит задача организовать ETL -процесс, экстракция производится из исходной системы SAP R/3 в которой создан источник данных на основе функционального модуля, логика сбора данных ФМ из десятка таблиц довольна сложна, на выходе набор данных по определенной структуре данных, которые возвращает ФМ по определенным критериям среди них календарый год/месяц. Так вот я хочу и считаю наиболее правильным решением организовать загрузку с использованием родовой -дельты (если этот подход не верен подскажи как поступить лучше?). В качестве поля по которому производится экстракция является идентификатор записи (не особо приниципиально какой именно...), который однозначной выделял запись среди других за любой период времени(по которому происходила бы экстракция). В чем состоит особенность моей задачи - данные определенной записи (поля её собираются из десятка таблиц) могут изменяться в течении хоть и фиксированного, но довольно большого промежутка времени (скажем в течении одного года), поэтому чтобы не перезагружать все данные в BW за этот промежуток времени, хочу разобраться как можно более правильно организовать загрузку, чтобы можно было подтягивать информацию о вновь созданных (вроде тут проблем нет - с дельтой придут записи с теми идентификаторами которые еще не загружался в BW), измененных (вроде как здесь тоже проблем нет, придут записи с новым идентификатором и в DSO перезаписываются по ключу), но НЕ ЗНАЮ КАК поступить с удаленными записями, каким образом экстрактор должен возвращать информацию от том, что запись была удалена и как в конечном счете обработать это удаление в провайдере данных? Поэтому хотелось разобраться с признаком recordmode.
Подскажите может я принципиально чего -то недопонимаю и как можно организовать ETL-процесс описанный выше с загрузкой дельты!? Ну и собственно выбор инфо-провайдера тоже обсуждается...

я не понял из вашего описания - у вас есть информация об удаленных записях на стороне R/3? или в исходных таблицах записи не сторнируются, а просто удаляются без следа?

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

Если экстрактор использует дельту, то у него есть соответстующая ДЕЛЬТА-процедура.
Широко используются следующие процедуры для обновления ДЕЛЬТА-записей в Инфопровайдерах :
ABR - Полная дельта с меткой уд. через дельта-очередь (ПригДляКуб)
AIE - After-Images через экстрактор (FI-GL/AP/AR)
AIM - After-Images через дельта-очередь (z.B. FI-AP/AR)
ADD - Аддитивное извлечение через экстрактор (напр., инф.-стр.LIS)
Область RECORDMODE определяет как будут обновлены записи в процессе ДЕЛЬТЫ.
Поле RECORDMODE имеет значения:
- After-Image
X - Before-Image
A - Добавить
D - Удаление (только ключ)
N - New-Image
R - Reverse-Image
Y - Update-Image (значение из обновления)
Приведу пример для Вашей ДЕЛЬТА-процеды:
Загрузили Вы в DSO следующий документ:
RECORD____DOCUMENT______RECORDMODE_____SUMMA______WAERS
__102________1001______________N______________1000________RUR
Затем вы поменяли сумму в исходной системе на 500 RUR. Следовательно в BW перенесется одна запись:
RECORD____DOCUMENT______RECORDMODE_____SUMMA______WAERS
__204________1001______________ _______________500________RUR
В итоге после загрузки ДЕЛЬТЫ получим следующую запись:
DOCUMENT______SUMMA______WAERS
___1001___________500________RUR

Спасибо, с AIЕ дельта - процессом разобрался . Не очень соображу в каких ситуациях целесообразнее использовать конкретный дельта- процесс, пример в статье к сожалению не дал четкого понимаю http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/5080c337-81e5-2c10-97af-8929424f3a4b?QuickLink=index&overridelayout=true?
И еще вопрос: правильно ли я понимаю что дельта процесс можно задать в исходной системе в таблице ROOSOURCE ("проапдейтить" поле Delta)? А при тиражировании источника данных на стороне BW в таблице RSDS так же будут содержаться данные о дельта-процессе?

Обычно для каждого приложения используется своя ДЕЛЬТА-процедура: AIE/AIM для FI-стандартных экстракторов, ADD для логистики и т.д. Это связано с особенностями сбора дельт для каждого приложения.
Можно. Я даже больше скажу, в трансформации можно менять значение поля RECORDMODE.