Документ SAP не проводится или отражается неверно: порядок проверки#

Если сообщение говорит, что проводка не удалась, сначала выясните её фактическое состояние. Ввод, удержание, парковка, отправка на согласование, принятие интерфейсом и окончательное проведение - разные этапы. Технический сбой вызывающей стороны может появиться уже после создания бухгалтерского документа. Поэтому не повторяйте команду, пока не исключили успешное или частичное выполнение.

Этот маршрут помогает сузить причину для FI-документа. Он не заменяет проверку конкретного бизнес-процесса, настройки целевой системы или текстов сообщений. Для общей диагностики см. симптомы и диагностические признаки SAP, для зависимостей - настройки SAP. Детальные правила ввода и дат разобраны в статьях про даты и периоды FI, тип документа, ключи и поля и валидации и замещения.

1. Установите этап и состояние документа#

Сохраните действие, сообщение целиком, приложение или интерфейс, дату и время, пользователя, источник и безопасный ключ бизнес-объекта. Затем проверьте статус именно в системе, которая владеет бухгалтерским документом:

Не сохранён или остановлен на вводе: записи с окончательным номером документа может ещё не быть.
Удержан, припаркован или ждёт согласования: работа сохранена или передана дальше, но это не обязательно означает обновление главной книги.
Отправлен через интерфейс, статус неизвестен: найдите запрос или сообщение по correlation ID и проверьте целевой объект и прикладной журнал.
Проведён: найдите документ и сравните фактические реквизиты и строки с исходным запросом.
Выполнен частично: выясните, какие документы или позиции созданы, прежде чем продолжать остальные операции.

Названия и доступные статусы зависят от приложения и выпуска. Статус «ошибка» в вызывающей системе не доказывает, что SAP не создал документ. Если проводка уже существует, относитесь к случаю как к исправлению проведённого документа, а не как к безопасному повтору.

2. Сверьте даты и целевой период#

Разделите дату первичного документа, дату проводки и системную дату ввода. По документации SAP S/4HANA On-Premise дата проводки используется для определения периода и финансового года; для целевого периода должны быть выполнены предпосылки, в том числе задан финансовый год и открыт период.

Проверьте в таком порядке:

Правильно ли указана дата проводки для требуемого бухгалтерского отражения?
Какой финансовый год и период соответствуют этой дате по варианту финансового года компании?
Открыт ли период для требуемой операции, типа счёта, компании и, где применимо, ledger или специального периода?
Есть ли ограничения даты, специальные периоды или отдельные правила для соответствующего источника проводки?

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

3. Зафиксируйте компанию и остальные измерения#

Сравнивайте попытку с успешным документом только при совпадающем организационном и процессном контексте. Запишите company code, ledger или ledger group, валюту и тип валюты, финансовый год, тип документа, счёт и account type, а также источник проводки. Для связанных процессов добавьте контрагента, налоговые данные, cost/profit center, order, asset, bank или другие присвоения, если они участвуют в операции.

Проверьте, что реквизиты:

существуют и действуют на требуемую дату в целевой редакции и клиенте;
связаны с правильной компанией, планом счетов, областью учёта или компонентом;
подходят выбранному типу документа и типу счёта;
передаются источником без потери, неверного знака, валюты, единицы или идентификатора;
разрешены в бизнес-процессе и доступны пользователю или интерфейсу.

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

4. Проверьте поля, правила и derivation#

Для каждой строки сопоставьте фактические поля с ожидаемыми: счёт, дебет/кредит, сумма, валюта, налог, assignment и необходимые CO, AA или иные аналитики. В On-Premise тип документа ограничивает некоторые параметры документа, а posting key относится к позиции и влияет на тип счёта, направление дебет/кредит и обработку полей. Field status может сделать поле обязательным, необязательным или скрытым. Проверяйте эти настройки вместе для реального счёта и экрана ввода, а не отдельно по одному полю.

Если значение отсутствует или неожиданно подставлено, выясните, сработало ли одно из следующих условий:

реквизит был обязательным в данном контексте или скрыт правилами ввода;
master data или организационное присвоение отсутствовало, было заблокировано либо не действовало на дату;
валидация запретила комбинацию полей или остановила проведение;
замещение или derivation изменили исходное значение;
процесс использовал account determination или extension logic, которые зависят от контекста.

Для validation/substitution запишите контекст, событие, условие, активность правила, затронутое поле и фактическое значение до и после обработки. Доступные поля и моменты вызова зависят от приложения, релиза и редакции. Не отключайте правило и не ослабляйте его контроль, пока не установлены его владелец, область действия и бизнес-обоснование.

5. Сопоставьте сообщение с конкретным слоем#

Ищите точный текст и идентификатор сообщения, если он показан целевой системой, затем проверяйте журнал именно того этапа, где возник отказ. Валидация ввода, authorization check, настройка FI, интерфейсный mapping, очередь, фоновый job и ABAP runtime оставляют разные диагностические следы.

Что наблюдается	Следующий безопасный шаг
Ошибка появляется при вводе отдельного поля	Сверить значение, формат, обязательность, статус поля и связанную master data
Ошибка появляется после полного ввода или симуляции	Сверить дату/период, баланс дебета и кредита, тип документа, account type, правило и присвоения
Пользователь не может выполнить действие	Проверить точный authorization failure для этого пользователя, объекта и оргзначений; не запрашивать широкую роль наугад
Ошибка пришла из интерфейса, фонового запуска или workflow	Сверить технический ID запроса, статус очереди/задания, прикладной результат и наличие FI-документа
Документ существует, но строки не соответствуют исходному событию	Проследить mapping и derivation от источника, затем проверить документ, ledger и каждую существенную строку

Общие приёмы работы с сообщениями и журналами описаны в REF‑06. Не выводите единственную первопричину только из формулировки сообщения: несколько условий могут приводить к похожему симптому.

6. Ограничьте гипотезу и исправление#

Для каждой гипотезы зафиксируйте условие и данные, которые её подтверждают. Сравнивайте одну неуспешную попытку с успешной при одинаковом приложении, источнике, компании, дате и наборе строк. Меняйте за один опыт только одно контролируемое условие в тестовой среде, используя безопасные данные.

Не используйте такие действия как универсальное исправление:

массово открывать периоды;
удалять validation или substitution;
менять тип документа, счет или автоматическое определение без владельца процесса;
добавлять пользователю широкие полномочия;
повторять запрос или пакет до выяснения, был ли документ уже создан.

После обоснованного изменения проверьте основной сценарий, релевантную границу и ожидаемый отказ. Сохраните изменение настройки или кода, разрешение владельца и результаты проверки.

7. Подтвердите финансовый результат#

После успешного проведения найдите документ по полному ключу и проверьте:

правильную company code, финансовый год, номер и дату проводки;
выбранный ledger или ledgers и период;
каждую существенную строку, account assignment и сторону дебет/кредит;
валюту, суммы, налог и баланс документа;
связь с исходным документом или запросом и отсутствие дубликата;
ожидаемое обновление открытой позиции, главной книги или связанного процесса.

Если проведённая запись неверна, выберите утверждённую процедуру коррекции, сторно или повторного проведения для соответствующего бизнес-объекта. Сохраняйте ссылку от исходного документа к исправляющим и не удаляйте бухгалтерскую историю, пытаясь «починить» сообщение.

Границы применимости#

Подробные примеры настроек и ввода в этой статье относятся к SAP S/4HANA On-Premise 2025 FPS01. Один и тот же термин или экран не гарантирует одинакового набора проверок в ECC, Private Edition, Public Edition и BTP. Используйте документацию и доступные инструменты для точного релиза и процесса. Источники зарегистрированы как metadata_only; конкретную систему, настройки, проводку, полномочия и SAP runtime проект не проверял.

SAP document posting fails or posts incorrectly: a diagnostic sequence#

When a message says that posting failed, first establish its actual state. Entry, hold, parking, approval, interface acceptance, and final posting are separate steps. A technical failure in the calling system may occur after an accounting document has already been created. Do not retry the command until you have ruled out successful or partial execution.

This sequence helps narrow down an FI document problem. It does not replace checking the specific business process, target-system configuration, or message text. For general diagnosis, see SAP symptoms and diagnostic signals; for dependencies, see SAP configuration settings. Detailed entry and date rules are covered in FI dates and periods, document types, posting keys, and fields, and validations and substitutions.

1. Establish the step and document state#

Record the action, full message, app or interface, date and time, user, source, and a safe business-object key. Then check the status in the system that owns the accounting document:

Not saved or stopped during entry: there may not yet be a document with a final number.
Held, parked, or awaiting approval: work may have been saved or forwarded, but this does not necessarily update the General Ledger.
Sent through an interface with an unknown result: find the request or message using its correlation ID and check the target object and application log.
Posted: find the document and compare its actual header and line items with the source request.
Partially completed: find out which documents or items were created before continuing the remaining operations.

Available names and statuses depend on the application and release. An "error" status in the calling system does not prove that SAP did not create a document. If a posting already exists, treat this as a correction of a posted document rather than a safe retry.

2. Compare dates and the target period#

Separate the source document date, posting date, and system entry date. SAP S/4HANA On-Premise documentation says the posting date is used to determine the posting period and fiscal year; the target period must meet the prerequisites, including a defined fiscal year and an open period.

Check in this order:

Is the posting date correct for the required accounting treatment?
Which fiscal year and period correspond to this date under the company's fiscal year variant?
Is the period open for the required operation, account type, company, and, where applicable, ledger or special period?
Are there date limits, special periods, or separate rules for the posting source?

Do not replace the posting date with today's date just to pass a check, and do not open periods more broadly than required. First confirm the intended period with the accounting owner, then compare it with the actual period assignment and the configuration-change log.

3. Capture the company and other dimensions#

Compare an attempt with a successful document only when the organizational and process context matches. Record company code, ledger or ledger group, currency and currency type, fiscal year, document type, account and account type, and posting source. For connected processes, include the business partner, tax data, cost/profit center, order, asset, bank, or other assignments when they participate in the operation.

Check that the values:

exist and are valid on the required date in the target edition and client;
belong to the correct company, chart of accounts, accounting area, or component;
are compatible with the selected document type and account type;
are passed by the source without loss, a wrong sign, currency, unit, or identifier;
are permitted in the business process and available to the user or interface.

Do not treat matching company, account, or period names as proof that the context matches. Verify technical assignments and organizational structure in the target system.

4. Check fields, rules, and derivation#

For every line item, compare actual and expected fields: account, debit/credit, amount, currency, tax, assignment, and required CO, AA, or other analytics. In On-Premise, document type constrains some document parameters, while the posting key applies to an item and affects account type, debit/credit direction, and field processing. Field status can make a field required, optional, or suppressed. Check these settings together for the actual account and entry screen, not as isolated field properties.

If a value is missing or unexpectedly substituted, determine whether:

the field was required or suppressed in this context;
master data or an organizational assignment was missing, blocked, or invalid on the date;
a validation prohibited the field combination or stopped posting;
substitution or derivation changed the original value;
the process used account determination or extension logic that depends on context.

For validation/substitution, record its context, event, condition, active status, affected field, and actual value before and after processing. Available fields and call points depend on the app, release, and edition. Do not disable a rule or weaken its control until its owner, scope, and business justification are established.

5. Match the message to a specific layer#

Search for the exact text and message identifier if the target system shows one, then check the log for the stage where the rejection occurred. Input validation, authorization check, FI configuration, interface mapping, queue, background job, and ABAP runtime leave different diagnostic trails.

Observation	Next safe step
The error appears while entering an individual field	Compare the value, format, required status, field status, and related master data
The error appears after full entry or simulation	Compare date/period, debit-credit balance, document type, account type, rule, and assignments
The user cannot perform the action	Check the exact authorization failure for this user, object, and organizational values; do not guess at a broad role
The error came from an interface, background run, or workflow	Compare the technical request ID, queue/job status, application result, and presence of the FI document
The document exists but its lines do not match the source event	Trace source mapping and derivation, then check the document, ledger, and each material line item

General message and log techniques are covered in REF-06. Do not infer a single root cause from the wording alone: several conditions may produce similar symptoms.

6. Limit the hypothesis and correction#

For each hypothesis, state the condition and evidence that support it. Compare one failed attempt with a successful one using the same app, source, company, date, and line-item set. Change only one controlled condition per test in a test environment, using safe data.

Do not use these actions as universal fixes:

opening periods broadly;
deleting a validation or substitution;
changing document type, account, or automatic account determination without the process owner;
granting broad user permissions;
retrying a request or package before checking whether a document already exists.

After an approved change, test the main scenario, a relevant boundary, and an expected rejection. Preserve the configuration or code change, process-owner approval, and verification results.

7. Confirm the financial result#

After a successful posting, find the document by its complete key and check:

correct company code, fiscal year, number, and posting date;
selected ledger or ledgers and period;
every material line item, account assignment, and debit/credit side;
currency, amounts, tax, and document balance;
link to the original document or request and absence of a duplicate;
expected update to the open item, General Ledger, or connected process.

If the posted entry is wrong, use the approved correction, reversal, or reposting procedure for that business object. Keep a link from the original document to correcting documents, and do not erase accounting history in an attempt to "fix" a message.

Applicability limits#

The detailed configuration and entry examples in this article refer to SAP S/4HANA On-Premise 2025 FPS01. The same term or screen does not guarantee the same checks in ECC, Private Edition, Public Edition, or BTP. Use the documentation and tools for the exact release and process. Sources are recorded as metadata_only; this project did not inspect a specific system, configuration, posting, authorization, or SAP runtime.