Проверка негативных и повторных финансовых операций#

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

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

Негативные сценарии#

Закрытый или недопустимый период#

Используйте дату, период или ledger, которые не допускает сценарий. Ошибка должна объясняться выбранным правилом периода. Дата не должна незаметно переноситься, а непредусмотренная запись не должна оставаться.

Неполная финансовая идентичность#

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

Дублирующий ключ#

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

Отсутствующий получатель распределения#

Удалите допустимого получателя или сделайте веса неполными. Операция либо отклоняется, либо следует явно описанному правилу; остаток не теряется и не уходит молча произвольному объекту.

Недостаточная доступность бюджета#

Превысьте доступный остаток, не меняя остальные входы. Ожидаемая реакция определяется настройкой контроля: предупреждение, допуск по tolerance или жёсткий отказ. Проверьте диагностику и фактический остаток.

Ошибка после частичной обработки#

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

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

Повтор после таймаута#

Таймаут не означает, что операция не завершилась. Сначала запросите статус по correlation ID, бизнес-ключу или документу результата. Затем разделите три случая:

1. Операция не применена. Повтор допустим по контракту с ограниченным числом попыток.
2. Операция применена, ответ потерян. Повтор должен вернуть исходный результат или позволить найти созданный объект, не создавая второй финансовый эффект.
3. Состояние неизвестно. Приостановите автоматический повтор и выполните сверку; не трактуйте неопределённость как отказ.

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

Транспортный ответ, запись входящего сообщения и подтверждение бизнес-проведения являются разными наблюдаемыми состояниями. Сверяйте документ, суммы по валютам, компанию и период. См. также контракт RFC, BAPI и IDoc и проверки HTTP API.

Два параллельных изменения одного объекта#

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

Не смешивайте защиту от параллельных изменений и защиту от повторной команды. Блокировка управляет конфликтом одновременного доступа к объекту, но сама по себе не распознаёт повтор после потери ответа. Версия объекта или optimistic concurrency может выявить устаревшее обновление, но не подтверждает выполнение ранее принятого финансового действия.

Для ABAP учитывайте границы SAP LUW и database LUW, а также синхронное или асинхронное обновление. Регистрация обновления, возврат из вызывающего кода и фактически сохранённый бизнес-объект не всегда совпадают по времени. Проверяйте документ и итоговое состояние после точки фиксации и при ошибке обновления. Подробности lock object и Update Task разобраны в статье ABAP: блокировки, SAP LUW и Update Task.

Минимальный протокол проверки#

1. Зафиксируйте версию SAP, интерфейс, бизнес-ключ, применимые настройки и начальный снимок.
2. Выполните один положительный случай и по одному случаю для каждого применимого отказа из матрицы.
3. Повторите запрос после обычного ответа и после искусственно потерянного ответа; сравните финансовый эффект.
4. Запустите две конкурентные команды и проверьте конфликт, порядок, сохранность инварианта и повторное чтение.
5. Сверьте созданные документы, суммы по валютам и периодам, а также объяснимость каждого отклонения.
6. Сохраните входы, версии настроек, безопасные идентификаторы, ожидаемый результат, команду, фактический итог и ограничения.

Локальная модель на синтетических данных может проверить арифметику, инварианты и алгоритм повторной обработки, но не доказывает SAP enqueue, Update Task, AVC или фактическую проводку. Источники SAP в этой статье сохранены как metadata_only; конкурентные финансовые операции и ошибки в SAP runtime не запускались.

A financial-operation test must confirm not only the expected response but also the absence of unwanted effects: a second posting, a lost update, a partially applied amount, or a hidden control bypass. Tie each test to a specific product, version, interface, transaction boundary, and configuration.

For every case, record the initial state, business key, request, expected technical response, expected business state, forbidden side effects, and reconciliation method. If a rule depends on configuration, record the applicable setting first. Do not turn an assumption about SAP behavior into a test oracle.

Negative scenarios#

Closed or invalid period#

Use a date, period, or ledger that the scenario does not allow. The error should be explained by the selected period rule. The date must not be silently shifted, and an unintended record must not remain.

Incomplete financial identity#

Remove a required company, fiscal year, currency, or part of a key. The request should be rejected before an irreversible effect. Do not substitute a similar but non-equivalent field without an explicit rule.

Duplicate key#

Submit the same business operation again with the same key. The first outcome should be findable by key; a second financial effect must not be created when the contract promises idempotent replay.

Missing allocation receiver#

Remove an eligible receiver or make weights incomplete. The operation should be rejected or follow an explicit rule; the remainder must not be lost or silently assigned to an arbitrary object.

Insufficient available budget#

Exceed the available amount without changing other inputs. Expected behavior comes from the control configuration: warning, tolerance, or hard rejection. Check the diagnostic result and actual remaining balance.

Failure after partial processing#

Trigger a failure after preparing part of the related updates. Check the transaction boundary: what committed, what rolled back, and whether recovery avoids a double effect. Financial tests should also check currency, sign, precision, rounding, and reconciliation period. For a rejected request, expect useful diagnostics and no financial effect, not merely any error code. Allow an exception only when the product contract defines it in advance and the expected state records it.

Retry after timeout#

A timeout does not mean the operation failed. First query its status by correlation ID, business key, or result document. Then distinguish three cases:

1. The operation was not applied. A retry is permitted by the contract within a bounded attempt count.
2. The operation was applied but the response was lost. A retry returns the original outcome or lets the caller find the created object without creating another financial effect.
3. The state is unknown. Pause automatic retries and reconcile; do not treat uncertainty as failure.

Compare replay of the original request with a new legitimate operation for the same amount. A replay uses the original idempotency identifier or business request identity; a new operation needs a new business key. Reusing the same key with a different payload should produce a defined conflict rather than silently changing the stored outcome.

A transport response, an inbound-message record, and confirmation of business posting are distinct observable states. Reconcile the document, amounts by currency, company, and period. See also the RFC, BAPI, and IDoc contract guide and HTTP API checks.

Two concurrent changes to one object#

Create an identical starting state and launch two changes so both read it before the other commits. The expected contract may serialize changes, reject the competing operation, or require a reread and revalidation. In every case, the result must preserve the invariant and make the winning operation explainable. Record the business lock key, its scope, and when it is released.

Do not confuse protection from concurrent changes with protection from repeated commands. A lock controls conflicting simultaneous access to an object, but does not by itself recognize a retry after a lost response. An object version or optimistic concurrency can detect a stale update, but does not confirm whether a previously accepted financial operation completed.

For ABAP, account for SAP LUW and database LUW boundaries and synchronous versus asynchronous update. Update registration, return from the caller, and the saved business object may occur at different times. Verify the document and final state after the commit point and when an update error occurs. The ABAP locks, SAP LUW, and Update Task article explains lock objects and Update Task in more detail.

Minimum validation protocol#

1. Record SAP version, interface, business key, applicable settings, and initial snapshot.
2. Run one positive case and one case for each applicable rejection in the matrix.
3. Replay requests after a normal response and after a simulated lost response; compare the financial effect.
4. Run two concurrent commands and check conflict, ordering, invariant preservation, and reread behavior.
5. Reconcile created documents and amounts by currency and period, and verify each rejection is explainable.
6. Retain inputs, setting versions, safe identifiers, expected outcome, command, actual result, and limitations.

A local synthetic-data model can check arithmetic, invariants, and retry algorithms, but cannot prove SAP enqueue, Update Task, AVC, or actual posting behavior. SAP sources in this article are retained as metadata_only; concurrent financial operations and errors were not run in SAP runtime.