Анализ собственного кода перед переходом на S/4HANA
Как сформировать область Z-кода, использовать данные UPL/SCMON и ATC, связать findings с Simplification Items и ранжировать изменения по риску финансового процесса.
6 мин чтения·База знаний
Ревизия 1Применимость к указанным контекстамЧастичное покрытиеКонтекст: CTX-S4-ONPREMКонтекст: CTX-S4-PRIVATEдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Анализ собственного кода перед S/4HANA conversion отвечает на разные вопросы: что существует, что действительно используется, какие изменения SAP затрагивают код, и какой бизнес-процесс пострадает, если исправление отложить. Один список ATC findings не отвечает на все четыре.
Определите исходную и целевую версии, систему или системы разработки, production-клиенты, используемые компоненты, конверсионный сценарий и целевой вариант ATC. Сформируйте инвентарь не только Z-программ: включите классы, функции, enhancements, модификации, формы, интерфейсы, фоновые задания и внешние расширения, если они принадлежат проекту.
Для каждого объекта по возможности запишите владельца, пакет, транспорт/версию, связанный процесс, вызывающие и вызываемые объекты, внешние зависимости, production-критичность и стратегию: сохранить, адаптировать, заменить стандартной функцией, перепроектировать, удалить после подтверждения или оставить изолированным.
Неполный инвентарь и неполный набор production-систем делают анализ usage и зависимостей неполным. Зафиксируйте, какие клиенты, серверы, job schedules, интерфейсы и инструменты сбора кода не попали в область проверки.
Используйте usage data как свидетельство, а не как доказательство отсутствия ценности#
Для Custom Code Migration Guide SAP описывает данные использования UPL/SCMON и снимки usage, которые подключаются к проекту. Они помогают определить область кода. При использовании таких данных анализируемая область может включать объекты, которые были использованы, статически связаны с использованными объектами, а также объекты без usage-сигнала, например типы данных или таблицы.
Запишите период и способ сбора, охват систем и клиентов, агрегирование снимка и события бизнеса внутри периода. Короткое окно или неполный охват может не увидеть годовое закрытие, редкий платёж, восстановление, интерфейс, аварийный режим или запуск из другой системы. Отсутствие вызова в снимке не доказывает, что код безопасно удалить.
Если планируется deletion transport, требуйте решения владельца процесса, проверки статических и динамических зависимостей, поиска вызовов через настройки/генерируемый код, оценки внешних потребителей, архива исходника и повторной проверки целевого scope. Код со слабым сигналом использования переводите в ручное рассмотрение, а не автоматически в удаление.
Запускайте разные анализы на их собственные вопросы#
SAP Readiness Check даёт высокоуровневую картину категорий изменений в custom code и может группировать результаты по Simplification Item и типу исправления. Оценки quick fix зависят от способа сбора; обзор не является исчерпывающей компиляцией, тестом выполнения или готовой трудоёмкостью.
Custom Code Migration app/project помогает определить scope, выполнить S/4HANA custom-code checks и связать findings с usage data. Проверяйте целевой продукт и релиз проекта, выбранные варианты, снапшоты и статус каждого результата.
ATC со связанными проверками и Simplification Database выявляет статические проблемы и ссылки на изменившиеся объекты SAP. Для конверсии используйте target-specific вариант проверки из актуального руководства, а не вариант для другого релиза или общий lint-набор.
Ручная трассировка зависимостей и functional review нужны там, где вызов формируется динамически, проходит через настройки или внешнюю интеграцию, либо статический анализ не устанавливает бизнес-смысл.
Эти результаты дополняют, но не подменяют друг друга. ATC finding с объектом SAP указывает на место анализа, не доказывая, что конкретный процесс вызывает ошибку; отсутствие finding не доказывает финансовую корректность поведения.
Для каждого finding сохраните версию ATC, variant, check ID, target release, объект и include, присвоенный SAP Simplification Item/Note, статус, владельца и доказательство применимости. Откройте связанную Simplification Note: проверьте предусловия, релевантный объект, объяснение изменения, действия до/после конверсии и ограничения по версии.
Затем проследите путь от изменённого SAP-объекта до Z-кода и финансовой операции. Например, изменение таблицы или поля может повлиять на извлечение аналитики, но не обязательно на проводку; изменение API или семантики документа может затронуть создание, сторно или закрытие периода. Используйте lineage/интерфейс и реальные сценарии процесса для проверки связи.
Разведите одно исходное изменение и несколько технических findings, которые оно породило, чтобы не считать усилие и риск несколько раз. И наоборот, не объединяйте независимые исправления только потому, что они находятся в одном пакете.
Блокирующие: синтаксис, критичные несовместимости или предусловия, из-за которых целевая проверка, активация или конверсия остановится.
Риск финансовой корректности: сумма, валюта, дата/период, account assignment, ledger, open item, налог, сторно, расчёт или документная ссылка могут измениться.
Эксплуатационный риск: критичная интеграция, массовое задание, производительность HANA-запроса, восстановление или закрытие может перестать работать либо выйти за согласованный SLA.
Неиспользуемое или неизвестное: возможный кандидат на исключение после проверки периода usage, зависимостей, владельца и бизнес-цикла; неопределённость сама по себе остаётся задачей анализа.
Улучшение: рефакторинг или переход на предпочтительный extension/API, который не требуется для выбранной конверсии, но имеет отдельную ценность и оценку.
Для каждой работы оцените критичность процесса, число и виды пользователей, exposure сумм, частоту, объём, связанные объекты, готовность корректного API/замены, объём ручной проверки, окно изменения и стоимость отказа. Не сортируйте только по количеству ATC findings, числу строк кода или доступности quick fix.
Регистр исправлений должен связывать finding, process owner, developer, целевую заметку, ожидаемое изменение, транспорт, тестовые сценарии, доказательство, зависимые команды и решение о переносе/удалении. Статус «поправлено» требует проверки target-version и регрессии, не только изменения исходника.
Для каждого исправления подготовьте воспроизводимый исходный пример и ожидаемое поведение. Запустите нужный ATC-набор и ручные проверки в целевом или центральном check system; разрешения и exemption документируйте с владельцем и обоснованием, а не используйте как замену исправлению.
Для финансового кода включите затронутые операции: проводку, сторно, повторную обработку, валюту и дату, ledger/назначения, open/cleared item, интерфейс, массовую обработку и этап закрытия. После конверсии проверьте результат на целевом релизе, сравните соответствующие документы и суммы и повторите функциональный regression. Статическая чистота ATC не равна доказательству результативности.
Отделяйте подтверждённую адаптацию от будущего улучшения. Обязательные исправления для конверсии имеют ссылку на применимое изменение SAP и приемку. Рефакторинг, недоступный/неиспользуемый объект и redesign clean-core ведите отдельным решением, чтобы не менять неявно scope перехода.
Этот материал частично покрывает MIG-08. SAP Custom Code Migration Guides относятся к S/4HANA 2025 для On-Premise и Private Edition; Readiness Check источник описывает high-level анализ для upgrade-сценариев; возможности app проверяются по официальной документации соответствующего релиза. Источники имеют статус metadata_only; код заказчика, usage snapshot, ATC results, исправления и SAP runtime не проверялись.
Custom code analysis before an S/4HANA conversion answers different questions: what exists, what is actually used, which SAP changes affect the code, and which business process is at risk if a fix is delayed. One ATC findings list does not answer all four.
Record the source and target releases, development and production systems/clients, active components, conversion scenario, and target ATC variant. Inventory more than Z programs: include classes, function modules, enhancements, modifications, forms, interfaces, background jobs, and external extensions owned by the project.
For each object, record its owner, package, transport/version, related process, callers and callees, external dependencies, production criticality, and strategy where possible: retain, adapt, replace with standard functionality, redesign, remove after approval, or isolate.
An incomplete inventory or partial production-system set makes usage and dependency analysis incomplete. Record which clients, servers, job schedules, interfaces, and code-collection tools were outside the analysis scope.
Use usage data as evidence, not proof of no business value#
For custom-code migration, SAP describes UPL/SCMON usage data and usage snapshots that can be added to a migration project. They help define the code scope. With this data, the analysis scope can include used objects, objects statically referenced by used objects, and objects without usage signals such as data types or database tables.
Record the collection period and method, system and client coverage, snapshot aggregation, and business events that occurred during that period. A short window or incomplete scope can miss year-end close, an infrequent payment, recovery, an interface, an emergency process, or a call from another system. Absence from a snapshot does not prove that code is safe to delete.
If a deletion transport is planned, require process-owner approval, static and dynamic dependency review, checks for calls through configuration or generated code, external-consumer assessment, source archive, and renewed scope review. Route objects with weak usage evidence to manual review instead of automatically deleting them.
SAP Readiness Check gives a high-level view of custom-code change categories and can group results by Simplification Item and remediation type. Quick-fix estimates depend on the data-collection approach; the overview is not a complete compilation, execution test, or ready-made effort estimate.
Custom Code Migration app/project helps define the scope, run S/4HANA custom-code checks, and associate usage data with findings. Verify the project's target product and release, chosen variants, snapshots, and finding status.
ATC and related checks with the Simplification Database find static issues and references to changed SAP objects. For conversion, use the target-specific check variant in the current guide, not a variant for another release or a generic lint set.
Manual dependency tracing and functional review are needed where calls are dynamic, pass through configuration or external integrations, or static analysis cannot determine business meaning.
These results complement each other but do not replace one another. An ATC finding on an SAP object identifies a place to investigate; it does not prove that a specific process will fail. No finding does not prove financial correctness.
For each finding, retain the ATC version, variant, check ID, target release, object and include, assigned SAP Simplification Item or Note, status, owner, and applicability evidence. Open the linked Simplification Note and review prerequisites, affected object, change description, actions before/after conversion, and version limits.
Then trace the change from the SAP object to Z-code and the finance operation. A changed table or field may affect analytics extraction without affecting posting; an API or document-semantics change may affect creation, reversal, or period close. Use lineage, interface contracts, and real process scenarios to confirm the link.
Group multiple technical findings from one underlying SAP change so effort and risk are not counted repeatedly. Conversely, do not combine independent fixes just because they are in one package.
Blocking: syntax, critical incompatibilities, or prerequisites that stop target checks, activation, or conversion.
Financial correctness risk: amounts, currencies, dates/periods, account assignment, ledgers, open items, tax, reversal, settlement, or document links may change.
Operational risk: a critical integration, mass job, HANA query performance, recovery process, or close may fail or exceed its agreed service level.
Unused or unknown: a potential removal candidate only after period coverage, dependencies, ownership, and business-cycle approval. Uncertainty itself remains an analysis task.
Improvement: refactoring or moving to a preferred extension/API that is not required for this conversion but has a separate value and estimate.
For each item, consider process criticality, number and type of users, financial exposure, frequency, volume, dependent objects, availability of a valid replacement API, manual review effort, change window, and failure cost. Do not sort only by ATC finding count, lines of code, or quick-fix availability.
The remediation register should link each finding to the process owner and developer, target note, expected change, transport, test cases, evidence, dependent teams, and decision to migrate or remove. A "fixed" status requires target-version checks and regression evidence, not only a source-code change.
Verify remediation before and after the transition#
For each fix, prepare a reproducible source example and expected behavior. Run the necessary ATC set and manual checks on the target release or central check system; document exemptions, owners, and rationale instead of using an exemption as a substitute for a fix.
For finance code, include affected operations: posting, reversal, reprocessing, currency and date, ledger/assignments, open or cleared items, interface, mass processing, and close. After conversion, check on the target release, compare corresponding documents and amounts, and repeat functional regression. Static ATC cleanliness is not proof of correct results.
Separate confirmed conversion adaptations from future improvement. Required fixes link to the applicable SAP change and acceptance evidence. Refactoring, unused objects, and clean-core redesign remain separate decisions so the transition scope does not change implicitly.
This partially covers MIG-08. SAP Custom Code Migration Guides refer to S/4HANA 2025 for On-Premise and Private Edition; the Readiness Check source describes high-level analysis for upgrade scenarios; app capabilities must be checked against the relevant product release. Sources are metadata_only; customer code, usage snapshots, ATC results, remediation, and SAP runtime were not examined.