Чем отличаются черновой, припаркованный и проведённый документ, какие изменения допустимы после проводки и как сохраняется история исправления.
4 мин чтения·База знаний
Ревизия 2Применимость к указанным контекстамЧастичное покрытиеКонтекст: CTX-S4-ONPREMдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Понятия «сохранить», «припарковать», «провести» и «сторнировать» обозначают разные действия. У SAP нет одной универсальной машины состояний для документов всех приложений: доступные статусы и переходы зависят от вида документа, компонента и процесса.
Сохранённый, припаркованный и проведённый документ#
Незавершённую бухгалтерскую запись можно удержать или припарковать, если конкретный сценарий это поддерживает. Удержание обычно сохраняет текущую работу с минимальными проверками и без учётного обновления. Припаркованную запись можно открыть повторно, дополнить или исправить, а затем отправить на проверку или проведение. Пока документ не проведён, обычные обороты и остатки G/L не должны считаться обновлёнными как после окончательной проводки.
SAP Help для парковки счетов-фактур описывает журналирование изменений, последующее редактирование, симуляцию и проведение. Там же отмечено, что для таких припаркованных документов проверки и подстановки выполняются при проведении, а не при сохранении. Это процессный пример для счетов-фактур, его нельзя автоматически переносить на каждый FI-интерфейс или другой SAP-компонент.
После успешного проведения создаётся бухгалтерский документ и обновляются соответствующие данные учёта. Ошибка массового или фонового запуска может иметь отдельный статус обработки, отличный от статуса документа. При повторной обработке сначала выясните, был ли документ уже проведён, возникла ли корректирующая запись и безопасен ли повтор запуска. Не повторяйте операцию только потому, что в вызывающем приложении осталась ошибка.
Проведённый документ не является полностью неизменяемым во всех полях, но SAP защищает поля, изменение которых могло бы нарушить сверяемость. В документации On-Premise среди таких полей названы сумма, счёт, ключ проводки, финансовый год и сумма налога. Изменение доступно только при соблюдении условий SAP и настроенных правил компании.
Разделяйте исправление описательного атрибута от исправления бухгалтерского содержания. Если требуется изменить сумму, счёт или сторону проводки, сначала выясните, разрешён ли такой шаг источником и процессом. Часто требуется сторнировать исходную проводку и создать корректную заново, сохранив ссылку между исходным и исправляющим документами.
Сторно предназначено для отмены ошибочно проведённой записи. Оно создаёт отдельный документ с обратными суммами, а не стирает исходный из истории. Причину и дату сторно следует сохранять вместе с идентификатором сторнируемого документа и созданного документа сторно.
Допустимость сторно зависит от связей исходной записи. В SAP Help для G/L-документов S/4HANA 2023 описано, что очищенные позиции сначала требуют сброса clearing; некоторые документы, созданные SD или MM, нужно отменять функцией исходного компонента, потому что сторно только из FI не отменит все связанные значения. Эта документация не подтверждает тот же набор ограничений для каждого выпуска и каждой разновидности документа.
Обычно сторно относится к тому же периоду, что и исходный документ. Если период закрыт, документация предусматривает дату в открытом периоде. Выбор допустимого периода и причины сторно зависит от настроек, закрытия периода и локальных правил учёта. Не подменяйте корректировку прошлой датой без проверки разрешённого открытого периода.
SAP описывает отображение изменений припаркованных и проведённых документов. Для массового сторно SAP Help описывает предварительный просмотр документов и флажок Simulation перед запуском. В конкретных сценариях ошибки posting run могут переходить между состояниями «новый», «в процессе», «исправлен», «сторнирован» или удалён, но эти статусы относятся к журналу ошибок процесса, а не являются общим жизненным циклом всех FI-документов.
Для каждой попытки фиксируйте:
ключ документа: система, company code, финансовый год и номер;
идентификатор запуска и исходный статус до повторной обработки;
обнаруженные ошибки и выполненные ручные исправления;
существующие связанные документы, clearing и ссылки на первичный процесс;
причину, дату и статус сторно, если оно выполнялось;
результат симуляции или фактического запуска и созданные номера документов.
Практический порядок: остановить автоматический повтор, сверить факт проводки в системе-источнике, открыть журнал изменений и обработки, проверить clearing и связанные документы, выбрать предусмотренный процесс исправления, затем повторно выполнить только непроведённую операцию. После результата сравнить исходный и новый ключи, суммы, статусы и историю ссылок.
Материал опирается на прочитанные страницы SAP Help для S/4HANA On-Premise. Точный релиз указан только для сторно G/L: SAP S/4HANA On-Premise 2023.latest; остальные снимки не устанавливают релиз. Частные снимки и точные выдержки сохранены в реестре; конкретная конфигурация, интерфейс и SAP runtime не проверялись.
The terms “save,” “park,” “post,” and “reverse” describe different actions. SAP does not have one universal document state machine across all applications: available statuses and transitions depend on document type, component, and process.
An incomplete accounting entry can be held or parked when the specific scenario supports it. Holding usually saves current work with minimal checks and without accounting updates. A parked entry can be reopened, completed, or corrected, then submitted for review or posting. Until posting, ordinary G/L balances and turnover should not be treated as updated as they are after a final posting.
SAP Help for invoice parking describes logging changes, later editing, simulation, and posting. It also states that, for those parked invoices, validation and substitution take place at posting rather than at save. This is a process example for invoices and should not automatically be applied to every FI interface or other SAP component.
After successful posting, an accounting document is created and the corresponding accounting data is updated. An error in a mass or background run can have its own processing status, separate from the document status. Before retrying, determine whether the document was already posted, whether a correcting entry exists, and whether the retry is safe. Do not repeat an operation merely because an error remains in the calling application.
A posted document is not necessarily immutable in every field, but SAP protects fields whose change could compromise reconciliation. On-Premise documentation lists amount, account, posting key, fiscal year, and tax amount among protected fields. Changes are allowed only when SAP conditions and company-specific rules permit them.
Separate a descriptive-attribute change from a change to accounting substance. If an amount, account, or debit/credit side needs correction, first determine whether a direct change is allowed by the source and process. Often, the procedure is to reverse the original posting and create a corrected one, retaining a link between the original and correcting documents.
Reversal is used to cancel an incorrect posted entry. It creates a separate document with opposite amounts instead of erasing the original from history. Retain the reversal reason and date together with identifiers for the reversed document and the reversal document created.
Reversal eligibility depends on links to the original entry. SAP Help for S/4HANA 2023 G/L documents states that cleared items must first have clearing reset; some documents created by SD or MM must be reversed using the source component's function because reversal from FI alone does not undo all related values. This documentation does not establish the same restrictions for every release and document type.
Usually, the reversal is posted in the same period as the source document. If that period is closed, the documentation provides for a date in an open period. Choosing an allowed period and reversal reason depends on configuration, period close, and local accounting rules. Do not use a past date without checking that the posting period is open.
SAP describes displaying changes to parked and posted documents. For mass reversal, SAP Help documents a Display before Reversal option and a Simulation checkbox before execution. In specific scenarios, posting-run error records can transition through states such as new, in process, corrected, reversed, or deleted, but these statuses belong to the process error log and are not a general FI-document lifecycle.
For each attempt, retain:
document key: source system, company code, fiscal year, and number;
run identifier and original status before retry;
errors found and manual corrections performed;
existing related documents, clearing, and links to the originating process;
reversal reason, date, and status when applicable;
simulation or actual-run result and any document numbers created.
Practical sequence: stop automatic retry, verify whether posting occurred in the source system, inspect the change and processing logs, check clearing and related documents, select the correction path defined for the process, and retry only the operation that has not already posted. After processing, compare the original and new keys, amounts, statuses, and history links.
This article uses read SAP Help pages for S/4HANA On-Premise. The cited G/L reversal page identifies version 2023.latest; the other captured pages do not establish exact releases. Bounded private snapshots and exact excerpts are retained in the knowledge registry. Specific configuration, interface behavior, and SAP runtime were not checked.