Добрый день.
Подскажите, пожалуйста, как анализировать на предмет критичности полученный в тр.S_ALR_87012342 отчет с имеющимися пропусками?
На нескольких ресурсах было найдено описание причин появления пропусков в нумерации документов,
но не очень понятно, что делать с найденными номерами?
Их необходимо как-то до-провести?

в теме код транзакции верный.
в пояснении закралась ошибка - из буфера вставлена другая (уже отредактировано)...
вопрос именно про Пропуски в нумерации документов.

Самого интересует подобный вопрос, а также каковы причины пропусков номеров. Не подскажите в чём причина? Кеширование?

В тр. SNRO укажите параметр "Число номеров в буфере = 1".

Правильно я понимаю, что это способ избежать возникновения пропусков в будущем?
А что делать с уже полученными пропусками?

У меня в системе в тр.SNRO для объекта RF_BELEG (Диапазоны номеров для бухгалтерских документов) указан параметр=Нет буферизации. Разве это не более жесткое условие, чем предложенное вами?

С технической точки зрения, это сбой при обновлении данных в таблицах во время выполнения проводок.
...
GAPS in the FI document number range are usually caused by failed transaction updates.
When you post a document SAP will take a number from the number range object and assign it to the document however the document is not written immediately to the database so you have to wait while the record it written to the database.
If the posting fails to write to the database then you have what is termed a 'failed transaction update' - SAP does not reset the number range so a gap appears. ...

Программа RFVBER00 показывает список прерванных обновлений.
И есть еще программа RFBNUM00, которая показывает пропуски в разрезе регистров (тр.из темы - только для ведущего регистра).

KRT_N, спасибо за объяснение.

В условиях нашего законодательства (Украины и России) это некритично я так понимаю. А европейцы наверное сдают какие-то Журналы документов из SAP в свои налоговые органы. Всёравно остаётся вопрос: что они делают с пропусками?

Да, вопрос остается. Что делать с пропусками так пока и не решено.
Для начала список прерванных обновлений (по сути модели документов, которые пользователь намеревался провести, но они не сохранились в системе) был предоставлен для анализа самим пользователям.
С одной стороны, возможно данные пропуски и не критичны. Но с другой стороны, зачем же в концептуальных проектах внедрения проверку пропусков документов тр.s_alr_87012342 указывать как обязательную процедуру закрытия периода (дня/месяца), если потом неизвестно, как эти пропуски обрабатывать?

у меня аналогичная проблема Европейцы прописали в глобальном теплейте эту процедуру и теперь непонятно, что с ней делать