Да, да, да.... я в курсе... нельзя... но убедить заказчика оказалось нереально... Надо менять поля KBLNR, KBLPOS, EBELN, EBELP. Короче говоря, заказчики хотят, чтобы проведенный уже документ ссылался на другой документ - не на тот, по которому он был проведен (исправляем ошибки не совсем удачного старта продуктива). Пожалуйста, гуру и иже с ними, подскажите, если кто в курсе - как корректно (если о корректности вообще может здесь идти речь) провести эти изменения... Какие таблицы надо затронуть, чтобы не обрушить все связки BSIK, BSAK... Короче говоря, Кто знает всю цепочку. Заранее всем спасибо...

офф: с этим вообще хоть кто нибудь сталкивался?...

Может проще сразу затрелиться?
Если серьезно, то вопрос такой - может лучше пойти по пути массового сторнирования проведенных документов и проводки их заново по-правильному?
Иначе, я думаю, неконсистентность вам гарантирована.

Ох... уже подумываю, пистолет не продашь?:(... Других путей они не воспринимают... Уже предлагал... Чего мы только не предлагали...

Судя по полям EBELN, EBELP, эти документы не напрямую в FI появились, а к документам ММ, созданным со ссылкой на закупочный заказ.
Значит, нужно апдейтить еще mseg, историю заказа и т.п.
В общем, я бы просто не взял на себя отвественность написать такое ТЗ - тут можно c очень высокой вероятностью систему окончательно угробить.
Понимаю, что ничем не радую, но лучше заранее осознавать все последствия...

Тебе ТЗ показать? "По кнопке "обновить" обновить значение этих полей в таблицах BSEG BSIK и BSAK"... ВСЁ!Я ИДИЁТ, УБЕЙТЕ МИНЯ КТО-НИБУДЬ! (ну кроме внешнего оформления)... Так что ответственность легко и просто возложили на меня....

Со сложными системами всегда так - чем меньше знаешь о том, как все работает, тем проще кажется решение проблемы.
Видимо, тот кто писал ТЗ, о последствиях не думал вообще.

Пример (исхожу из того, что мы говорим по документ, созданный к счету-фактуре).

Апдейтим bseg, меняем ссылку с заказа 1 на заказ 2. После этого таки пытаемся провести правильную фактуру к заказу 1. А система ругается - все количество уже отфактурировано! Потому как историю заказа не проапдейтили.

LKU прав.
Судя по ссылкам документы в FI не первичны, а созданы на основании логистических инвойсов.
В таком случае, как у вас, я бы отказался выполнять ТЗ.
Если люди совершенно не хотят работать руками (сторно всей цепочки и перепроведение документов (или документы в закрытом периоде уже? но и это не проблема)), то можно автоматизировать процесс. Если выяснить отличительные особенности некоррестых документов.
Тогда через FI док. смотрим на лог. инвойс, по vbfa раскручиваем всю цепочку, сторнируем, перепроводим. Программно, естественно.

Кстати, о птичках, какая у вас система, гибкая главная книга активирована? Я совсем не разбираюсь в FI, но вроде в гибкой главной книге при проводке документа FI кроме таблиц bseg и bs*k еще и в таблицах спецрегистров строки появляются...

эээхххх.... спасибо за описание возможных траблов... о части подводных камней я даже не догадывался... написал ещё раз постановщику... описал возможные проблемы... буду смотреть на результат... но чем дальше, тем ближе рука к пистолету:(...

LKU опять прав
Регистры проверить просто:
запустите транзакцию GCAN.
Если статистика будет не пустой - можно стреляться. Там же и таблички выводятся, где данные лежат.

статистика не пустая... "ба-бах"?

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

Все равно как минимум нужно проверить наличие отсутствия в спецрегистрах полей, которые хотим менять

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

Чует мое сердце, ТЗ вам FI’щик писал.

Я чего-то не могу себе представить ситуацию, когда необходимо обновить данные этих полей в BSEG (вы их что в момент проводки в OPEN FI убили?) Если я правильно помню, все эти поля находятся в COBL => все таблицы содержащие его в себе вам обновлять, а если ошибка еще раньше COBL’а, то еще пару десятков таблиц.

Так же еще есть различия в формировании обратных документов в MM и SD (к примеру сторно с.ф. сбыта формируется из прямого документа простой подстановкой обратных знаков Д<->К, а сторно документов ММ формируется по полной схеме прямого документа с использованием обратной операции. Прямой ММ документ может иметь N1 FI документ, а обратный N2 FI документа).
Это я к тому, что придется обновлять всю цепь, иначе можете еще большую неконсистентность создать. При проводке ММ документа, много информации берется из заказа.

Мой совет, перешлите это ТЗ начальнику группы логистики с копией народному умельцу и посоветуйте им на этот счет пообщаться