Риск в SAP и независимый эталон: доказательства и переход между версиями
Как отделить документацию продукта, конфигурацию системы и синтетический расчёт; как сопоставлять риск-результаты при переходе, не смешивая методику, данные и изменения портфеля.
3 мин чтения·База знаний
Ревизия 1Применимость к указанным контекстамЧастичное покрытиеКонтекст: CTX-S4-ONPREMдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Риск в SAP и независимый эталон: доказательства и переход между версиями#
Описание функции SAP, настройки конкретного ландшафта, результат выполнения и независимая математическая модель - разные типы свидетельств. Их нельзя подменять друг другом. Ссылка на Help подтверждает только то, что документация описывает возможность в указанном продукте и релизе; сама по себе она не доказывает, что компонент установлен, настроен или дал конкретный результат.
Документация продукта фиксирует поддерживаемые функции и описанный контекст версии. Сохраняйте URL, издание, релиз и дату проверки.
Настройка системы задаёт области оценки, фильтры, иерархии, типы процедур, источники данных, валюты и правила агрегирования. Для неё нужны проверяемые system-specific настройки.
Результат выполнения относится к конкретному запуску: портфелю, дате, market-data set, параметрам, журналу, предупреждениям и итогам. Это подтверждение только данного прогона.
Независимый эталон рассчитывает небольшой заранее определённый пример по явно записанным формулам. Он полезен для проверки реализации и инвариантов, но не доказывает поведение SAP.
Для каждого утверждения укажите уровень свидетельства и то, что осталось неизвестным. В этом проекте источники риск-статей преимущественно имеют статус metadata_only, синтетические проверки запускаются локально, а SAP runtime не настроен. Поэтому нет подтверждения установленного решения, выполненной конфигурации или SAP-расчёта.
Сравнение старой и новой системы имеет смысл только после приведения к общей базе. Для обоих снимков зафиксируйте идентификатор запуска, системную версию, портфель и границу юридического лица, дату оценки, горизонт, метрику, валюту, источники и версии рыночных данных, правила неттинга, процедуру и версию модели.
Заранее сохраните таблицу соответствия объектов. Неизвестное соответствие оставляйте как пропуск или новое/удалённое состояние; не склеивайте позиции по похожему названию. Для сопоставимых строк разложите разницу на компоненты: изменение состава, изменение исходных величин, конвертацию, метод переоценки, параметры, конфигурацию и округление. Суммы в разных валютах, датах, горизонтах или метриках не следует вычитать друг из друга.
Результат перехода удобно разделить на четыре списка: совпавшие позиции, изменившиеся значения, отсутствующие в целевой системе и добавленные в ней. Для каждого изменения задайте владельца, классификацию причины, величину и согласованное действие. Порог существенности определяется процедурой контроля организации; универсального допустимого процента здесь нет.
В лаборатории compare_risk_snapshots требует совпадающих даты, валюты, метрики, горизонта и портфельной области; для переименованных ключей нужна явная связь один-к-одному. Функция показывает построчные изменения, но не утверждает, что методики двух SAP-версий эквивалентны и не сводит изменения к одному портфельному итогу.
Для независимого эталона храните входы, формулы, единицы, исходный код и его хеш, ожидаемые значения, результаты граничных случаев и правила округления. Используйте независимое вычисление, чтобы ожидаемый результат не копировал ту же ошибку, что и проверяемая функция. Мутационные проверки должны доказывать, что тесты замечают неверный знак, исключённый фактор, изменённое ограничение или сдвиг одной строки.
Перед сравнением систем раздельно проверьте: полноту выборки и ключей, согласованность market data, договорную границу неттинга, единицы и курсы, метрику и горизонт, параметры процедур и конфигурационные изменения. Лишь затем трактуйте остаточные расхождения как возможное различие результата расчёта. Совпадающие итоги не гарантируют совпадения состава: положительные и отрицательные отклонения могут взаимно погаситься.
Документация SAP S/4HANA On-Premise описывает несколько методов исторической симуляции и оценки результатов Market Risk Analyzer; в NPV Analysis перечислены доступные категории рыночных ключевых показателей для указанного выпуска. Выбор процедуры и настройка определяют способ расчёта. Это не является свидетельством фактической настройки проекта или результатом данного репозитория.
Материал частично покрывает RISK-15 и RISK-16. Он не является руководством по конверсии конкретного SAP-ландшафта. Для сопоставления входных данных см. статью о качестве данных риска, а для границ синтетической проверки - воспроизводимые проверки без SAP runtime.
SAP risk evidence and version transition: product, configuration, and reference model#
SAP feature documentation, configuration in a landscape, an execution result, and an independent mathematical model are different kinds of evidence. One cannot substitute for another. A Help link shows only that documentation describes a capability in a specified product and release; it does not prove that a component is installed, configured, or produced a particular result.
Product documentation records supported functions and release context. Retain the URL, edition, release, and review date.
System configuration defines evaluation areas, filters, hierarchies, procedure types, data sources, currencies, and aggregation rules. It requires verifiable system-specific settings.
Execution result belongs to one run: portfolio, date, market-data set, parameters, log, warnings, and output. It evidences that run only.
Independent reference calculates a small, predefined example using explicit formulas. It can check an implementation and invariants, but does not prove SAP behavior.
Label each claim with its evidence level and what remains unknown. In this project, most risk sources have metadata_only status, synthetic checks run locally, and SAP runtime is not configured. Therefore there is no evidence of an installed solution, executed configuration, or SAP risk result.
Compare old and new systems only after aligning their basis. For each snapshot, record run ID, system version, portfolio and legal-entity boundary, valuation date, horizon, measure, currency, sources and versions of market data, netting rules, procedure, and model version.
Save an object-mapping table before comparison. Leave unknown mappings as missing or added/removed states; do not merge positions because their labels look similar. For comparable rows, decompose the difference into composition, source values, conversion, valuation method, parameters, configuration, and rounding. Do not subtract amounts with different currencies, dates, horizons, or measures.
Classify results into matched positions, changed values, missing target positions, and positions added in the target. Assign an owner, reason, amount, and action to each material change. Materiality thresholds belong to the organization's control procedure; there is no universal acceptable percentage here.
In the lab, compare_risk_snapshots requires matching date, currency, measure, horizon, and portfolio scope; renamed keys need an explicit one-to-one mapping. It reports line-level changes but does not claim SAP methodology equivalence or collapse everything into one portfolio total.
For an independent reference, retain inputs, formulas, units, code and its hash, expected values, boundary cases, and rounding rules. Use a separate calculation for expected outputs so the oracle does not repeat the implementation's error. Mutation checks should demonstrate that tests detect a wrong sign, omitted factor, removed bound, or shifted row.
Before comparing systems, separately check population and keys, market-data consistency, contractual netting boundary, units and rates, measure and horizon, procedure parameters, and configuration changes. Only then can a residual difference be interpreted as a possible calculation difference. Matching totals do not guarantee matching composition: positive and negative variances can cancel.
SAP S/4HANA On-Premise documentation describes several historical simulation methods and result evaluation in Market Risk Analyzer; the NPV Analysis overview lists market-risk key-figure categories for the specified release. Procedure choice and configuration determine calculation behavior. This is not evidence of an actual project configuration or a result from this repository.