Как проверять нулевую и отрицательную базу, знаки tracing factors, округление и повторяемость, не выдавая учебный алгоритм за поведение SAP.
3 мин чтения·База знаний
Ревизия 1Применимость к указанным контекстамЧастичное покрытиеКонтекст: CTX-S4-ONPREMдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Распределение становится трудным для проверки не в обычном случае, а когда база пуста, отдельные tracing factors отрицательны, итог округляется или запуск повторяется после частичного успеха. Разбирайте такие ситуации с точными входными данными и выбранным правилом получателя.
Для variable portions сумма долей обычно определяется по reference base. Если база всех получателей равна нулю, деление на неё математически не определено. Диагностическая реализация должна завершать такой расчёт явным результатом «нулевая база», а не придумывать равные доли и не маскировать проблему. В SAP заранее проверьте доступность базы, отбор периода, получателей и настроенный receiver rule; обработка зависит от allocation context и конфигурации.
При фиксированных процентах, долях или суммах другая логика: значение задаётся правилом и может не зависеть от переменной базы. Для фиксированного процента сумма менее 100% может оставить часть значения у отправителя; поэтому «нулевая база» не должна автоматически трактоваться как нулевая сумма во всех видах распределения.
Отрицательный tracing factor возможен, когда фактор берётся из фактических данных, например количеств или статистических показателей. В документации SAP описаны варианты масштабирования отрицательных факторов. Выбор может изменить состав получателей и результат, а в итерационном расчёте смешанные знаки способны привести к несходимости.
Не применяйте abs() автоматически: такая нормализация стирает исходный знак и может изменить смысл сторно, возврата или отрицательного показателя. Зафиксируйте исходные значения, сумму факторов, вариант scaling и все исключённые/обнулённые факторы. Если отрицательные затраты распределяются по бизнес-правилу, ожидаемые знаки отправителя и получателей должны быть проверены отдельно.
Для учебной контрольной модели используйте decimal arithmetic и округляйте в валютной точности. Если округлённые доли не дают исходную сумму, остаток можно детерминированно назначить получателю с наибольшим остатком дробной части; при равенстве используйте устойчивый ключ получателя. Это рекомендация для воспроизводимого справочного алгоритма, а не утверждение о внутреннем алгоритме SAP.
Пример: сумма 10.00 распределяется между тремя равными долями. Точные доли равны 3.333..., а округлённые до центов дают 9.99. Контрольная модель может назначить недостающий цент получателю с наибольшим остатком по устойчивому порядку ключей. Сверьте, что сумма получателей равна сумме отправителя, и отдельно документируйте правило округления.
Test run и live run имеют разные последствия. Test run не создаёт реальные проводки; завершённый live run нельзя безопасно повторять без выяснения фактического результата. Используйте журнал и поддерживаемый SAP reversal run, затем только после сверки повторяйте расчёт. Идемпотентность справочного кода не означает, что повторный запуск SAP-проводки безопасен.
allocation context, цикл, сегмент, период, правило sender/receiver и состояние запуска.
исходная сумма, валюта и точные tracing factors до преобразования.
выбранный источник базы, фильтры, знак общей базы и обработка нулевых получателей.
scaling для отрицательных факторов, точность и правило округления.
test/live/reversal run, журнал, уже созданные документы и итоговая сумма по обеим сторонам.
Числовой пример выше является синтетической контрольной моделью, а не SAP runtime-тестом. Источники SAP Help относятся к S/4HANA On-Premise 2025 FPS01; отдельная страница запуска описывает операции test, actual и reversal. Источники зарегистрированы как metadata_only; конкретный алгоритм округления и поведение системы в нулевой базе не проверялись.
Allocations are hardest to verify outside the ordinary case: when the base is empty, some tracing factors are negative, totals are rounded, or a run is repeated after partial success. Analyze such cases using exact input data and the selected receiver rule.
For variable portions, the shares are generally determined from a reference base. If the base for all receivers is zero, division by that base is mathematically undefined. A diagnostic reference implementation should return an explicit "zero base" result instead of inventing equal shares or hiding the problem. In SAP, first check base availability, period selection, receivers, and configured receiver rule; handling depends on allocation context and configuration.
Fixed percentages, portions, or amounts follow different logic: the rule supplies the value, which may not depend on a variable base. With fixed percentages, a total below 100 percent may leave part of the value with the sender. Therefore, a zero base must not automatically be interpreted as a zero allocation for every method.
Negative tracing factors can occur when factors are read from actual data such as quantities or statistical indicators. SAP documentation describes options for scaling negative factors. The choice can change the receiver set and result, while mixed signs can also prevent iterative calculations from converging.
Do not automatically apply abs(): that removes the original sign and may change the meaning of a reversal, return, or negative indicator. Record original values, the total factor, selected scaling option, and all excluded or zeroed factors. If negative costs are allocated under a business rule, validate expected sender and receiver signs separately.
For a teaching reference model, use decimal arithmetic and round to the currency's precision. If rounded shares do not equal the original total, a residual can be assigned deterministically to the receiver with the largest fractional remainder; use a stable receiver key to break ties. This is a recommendation for reproducible reference algorithms, not a claim about SAP's internal algorithm.
Example: allocate 10.00 over three equal shares. Each exact share is 3.333..., while rounding to cents produces 9.99. A reference model can assign the missing cent to the receiver with the largest remainder using a stable key order. Check that receiver totals equal the sender total and document the rounding rule separately.
Test and live runs have different effects. A test run does not create actual postings; a completed live run should not be repeated safely without determining its actual outcome. Use the log and supported SAP reversal run, then repeat the calculation only after reconciliation. Idempotency in reference code does not mean an SAP posting run is safe to repeat.
Allocation context, cycle, segment, period, sender/receiver rule, and run state.
Original amount, currency, and exact tracing factors before transformation.
Selected base source, filters, total base sign, and treatment of zero receivers.
Scaling for negative factors, precision, and rounding rule.
Test, live, or reversal run; log; documents already created; and final amounts on both sides.
The numeric example is a synthetic reference model, not an SAP runtime test. SAP Help sources refer to S/4HANA On-Premise 2025 FPS01; the separate run page describes test, actual, and reversal operations. Sources are registered as metadata_only; actual SAP rounding algorithm and zero-base behavior were not checked.