Два бухгалтера одновременно сторнировали одну фактуру (разница в 7 секунд).


Сейчас при попытке войти в MIR4 вываливается дамп
ДинамОшибка DYNPRO_FIELD_CONVERSION
Краткий текст Conversion error

Кто сталкивался с такой ошибкой? Как это отсторнировать/зачистить?
Администраторы говорят, что это не к ним.
Что вообще в такой ситуации делать?

Спасибо заранее за ответ!

Мне кажется, если нет жестоких экситов на фактуре, которые могли привести к такой ситуации, то надо выставлять сообщение в SAP с приоритетом high или very high.

Но вообще, конечно, скорее всего виноват ваш z-код, где-нибудь в расширениях выполняется явный или не явный DB commit.

LKU, спасибо.

тут у нас полностью стандартная технология. читаю dump - z-ом и не пахнет.
сижу, сочиняю письмо.

Ну дамп, может быть уже следствием задвоения фактур (а может - и нет).
Z-код надо искать в момент сохранения фактур, вот, например, смотрим описание badi INVOICE_UPDATE


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

Добрый день.
Была аналогичная проблема, лет 5 назад пользователь работал в нескольких окнах, и также сумел провести 2 фактуры с разницей в несколько секунд.
Ошибку тогда исправили или с помощью сторно, или выполнив ввод кредитового авизо.
У вас дампит и в транзакциях MIRO, MR8M?
Если да - попробуйте выполнить ввод кредитового авизо, предварительно можно смоделировать проводки.

А вообще, как правильно заметил LKU, лучше обратиться в SAP за пояснением.

DED_MOROZ

спасибо за ответ!
дампит и MIRO и MR8M, как эти номера документов услышит.
*отправили письмо в SAP. ответ выложу тут, как будет.

Посмотрите в SM13, не было ли прерванных обновлений, и в ST22, не было ли дампов.

Бывает, что при прерванном обновлении типа V1 в часть таблиц данные записываются, а в остальные нет - возникает неконсистентность. Из-за этого возможен ввод дублирующих операций, которые в итоге приведут к дампу.

Прерывание обновлений может быть:
- из-за клинчей в СУБД;
- из-за "кривых" расширений;
- из-за ошибок в программном коде от SAP.

Поищите ноты, исправляющие данные коллизии или дающие рекомендации.

Старик, спасибо!
Посмотрел наш программист, дословно не воспроизведу, как он сказал, но смысл в том, что "проверка на возможность записи проверяется в момент первого обращения, если система подзависла - то возможны две записи", как у нас и получилось.
Вчера пришел ответ из SAP:

There is a dump in the PO history because the REMNG was negativ.
There are created 2 cancellation documents for the invoice.

I would like to ask you whether you have alrefy applied the note 1119285?

The report #ZREP_2CANCEL# from note 1119285 (previously stored in 543098) can be used to repair the doubled cancellation within the POs.
First please implement the code changes from note 1119285 to avoid this error in future time.
To correct the existing POs with this problem please implement the report zrep_2cancel.

In order to correct this inconsistence please

1) run report ZREP_2CANCEL from note 543098. you can run it in display mode first and then use X in Update and SAPOSS in User to run this report in update mode

2) in Update mode report will change one document and then display this document number

3) you need to cancel directly in MR8M document updated by report ZREP_2CANCEL (its number is displayed in step 2)

Please check if the follow-on FI doc has been cleared already or not. you should take the clearing FI DOC back (or reverse it) using FI transactions if the follow on FI doc has been cleared.

Сегодня поставим эту ноту, попробую отсторнировать.
Резльтат расскажу.

Ура-ура, победили.

Проблема решается установкой ноты 1119285. В ней содержится отчет zrep_2cancel (запуск через se38).
1) В этом отчете указываем БЕ и год - она находит нам все задвоившиеся документы.
Потом дополнительно к БЕ и году указываем F_UPDATE = X и F_USER = saposs . Программа выдаст номер документа, который необходимо сторнировать.
2) Сторнируем указанный документ MR8M.
3) Проверяем, все ли в порядке с бух.документами (у нас - все ок), если нет - выравниваем FI-проводками.

Всем спасибо за советы, кто столкнется с этой загвоздкой в будущем - спасибо за внимание.