Как различать идентификатор объекта, его общие данные и организационные присвоения, а также почему блокировка, пометка на удаление и архивирование означают разные состояния.
5 мин чтения·База знаний
Ревизия 3Применимость к указанным контекстамЧастичное покрытиеКонтекст: CTX-S4-ONPREMКонтекст: CTX-S4-PRIVATEдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Основная запись описывает относительно устойчивый объект, который используется в операциях и отчётности: например, счёт главной книги или делового партнёра. Для корректной аналитики недостаточно знать только текущие атрибуты. Нужны устойчивый ключ, область действия каждого атрибута и история изменений, если источник её предоставляет.
Отделяйте идентификатор объекта от правил, которые его формируют, и от организационных расширений. В документации SAP по Business Partner внутренний номер выдаётся последовательно из диапазона, заданного для группы счетов; при внешнем присвоении номер вводит пользователь, а система проверяет его уникальность и принадлежность диапазону. Внешний диапазон может допускать буквенно-цифровые номера, режим присвоения задаётся для группы счетов, а один диапазон может использоваться несколькими группами. Эти правила относятся к описанной в источнике модели S/4HANA и не заменяют проверку настройки конкретной системы.
У счёта главной книги различаются область плана счетов и область конкретного кода компании: изменение в первой применяется ко всем кодам компании, использующим этот счёт. Документация отдельно ограничивает изменение некоторых полей: номер счёта изменить нельзя; тип счёта можно менять только до первой проводки; валюту и налоговую категорию - также только до проводок; для счёта сверки требуется нулевой остаток, а для снятия признака счёта сверки или изменения управления открытыми позициями действуют дополнительные ограничения. Большинство изменений попадает в журнал, но некоторые поля, например текстовые, не регистрируются. Это правила именно счёта G/L, не общая схема для всех основных данных.
В аналитической модели храните исходный идентификатор вместе с системой-источником и типом объекта. Не считайте одинаковые строки ключей из разных систем одной сущностью без проверенного правила сопоставления. Присвоение объекта к company code, ledger, закупочной организации или другому подразделению имеет свою область и может иметь отдельный период действия.
Текущий профиль показывает последние известные атрибуты объекта.
История источника сохраняет предыдущие значения, дату изменения, автора или документ изменения, если эти данные доступны.
Снимок для отчётности фиксирует значения и присвоения, известные на дату формирования результата.
Не подменяйте историю источника собственной реконструкцией. Если доступна только текущая запись, помечайте исторические атрибуты как неизвестные. Для аналитического хранилища заранее определите, какие атрибуты перезаписываются, какие версионируются, а какие относятся к датированному организационному присвоению.
Эти состояния не равнозначны. Блокировка ограничивает использование объекта в определённых операциях или процессах. Индикатор удаления может обозначать кандидата на последующее архивирование и сам по себе не гарантирует физическое удаление. Архивирование и уничтожение данных зависят от ссылок на другие объекты, сроков хранения, настроек и применимых правил.
Для делового партнёра, клиента и поставщика документация SAP описывает отдельный путь после завершения срока хранения и блокировки. Данные могут остаться в базе или попасть в архив; если они остались в базе, их удаляют соответствующими объектами архивирования. Запись Business Partner удаляют после связанных записей клиента и поставщика. Отдельный отчёт ILM_DESTRUCTION уничтожает данные в базе или архиве так, чтобы их нельзя было восстановить. Удаление записи поставщика при этом не обязательно удалит все связанные ссылки: например, записи условий могут продолжать ссылаться на него. Следовательно, блокировка, удаление мастер-записи, архивирование и уничтожение данных - разные состояния и операции.
При загрузке не удаляйте строки из аналитической истории только потому, что объект заблокирован или помечен на удаление. Сохраняйте исходный статус и время его получения, учитывайте период хранения и требования к ссылочной целостности. Физическое удаление из источника не отменяет автоматически исторические факты, где объект уже участвовал.
признак внутреннего или внешнего присвоения номера, если он доступен;
область действия атрибута и его владельца;
действительность и время наблюдения отдельно, если источник их различает;
состояние блокировки, удаления или архивирования как отдельные поля;
версию или ссылку на запись изменения, если источник её передаёт.
Проверяйте уникальность ключа внутри области источника, ссылочную целостность присвоений, непротиворечивость периодов действия и переходы состояний. Сверяйте число активных, заблокированных и помеченных на удаление записей по типу объекта и организационной области. Не трактуйте отсутствие записи в очередном снимке как доказательство удаления: возможны пропуск загрузки, фильтр или задержка репликации.
Материал ограничен тремя документами SAP Help о нумерации Business Partner, изменении счетов G/L и удалении данных партнёров. Страница о нумерации описывает SAP S/4HANA и SAP S/4HANA Cloud Private Edition; остальные рассмотренные страницы относятся к S/4HANA On-Premise. Полный жизненный цикл всех типов основных данных, применимость к другим выпускам и настройка конкретной системы не исследованы; SAP runtime не запускался.
A master record describes a relatively stable object used in transactions and reporting, such as a G/L account or business partner. Correct analytics requires more than current attributes. It needs a stable key, the scope of each attribute, and change history when the source provides it.
Separate an object's identifier from the rules that generate it and from organizational extensions. In SAP Business Partner documentation, an internal number is assigned consecutively from a range defined for the account group. With external assignment, the user enters the number and the system checks uniqueness and range membership. External ranges can allow alphanumeric values; the account group determines which assignment modes are permitted, and a range can be shared by multiple groups. These rules describe the S/4HANA model covered by the source and do not replace checking a specific system's configuration.
A G/L account has a chart-of-accounts area and a company-code-specific area. A change in the first applies to all company codes using that account. SAP documentation restricts changes to certain fields: the account number cannot be changed; the account type can be changed only before the first posting; currency and tax category also require that no posting has occurred. A reconciliation account requires a zero balance, while removing that setting or changing open-item management has additional restrictions. Most changes are logged, but some fields, such as text fields, are not. These rules apply to G/L accounts, not to all master data.
In an analytical model, retain the source identifier together with the source system and object type. Do not treat identical key strings from different systems as the same entity without a verified mapping rule. An assignment to a company code, ledger, purchasing organization, or another unit has its own scope and may have its own validity period.
Current profile shows the latest known object attributes.
Source history retains prior values, change date, author, or change document when available.
Reporting snapshot fixes the values and assignments known when a result was produced.
Do not substitute your own reconstruction for source history. If only the current record is available, mark historical attributes as unknown. For an analytical warehouse, decide in advance which attributes are overwritten, which are versioned, and which belong to a dated organizational assignment.
These states are not equivalent. Blocking restricts use of an object in selected transactions or processes. A deletion indicator can mark an object for possible later archiving; by itself it does not guarantee physical deletion. Archiving and data destruction depend on references to other objects, retention periods, configuration, and applicable rules.
For business partner, customer, and supplier data, SAP documentation describes a specific process after the residence period has elapsed and the data is blocked. The data may remain in the database or be archived; if it remains in the database, it can be deleted with the corresponding archiving objects. The Business Partner record is deleted after the linked customer and supplier records. The separate ILM_DESTRUCTION report destroys database or archive data so it can no longer be retrieved. Deleting a supplier record does not necessarily remove every reference to it; condition records, for example, may still refer to the supplier. Blocking, deleting a master record, archiving, and destroying data are therefore separate states and operations.
During loading, do not remove rows from analytical history only because an object is blocked or marked for deletion. Retain the source state and observation time, and account for retention periods and referential integrity. Physical deletion from the source does not automatically undo historical facts in which the object already participated.
validity and observation time separately when the source distinguishes them;
blocking, deletion, or archiving state as separate fields;
a version or change-record reference when the source provides one.
Check key uniqueness within the source scope, referential integrity of assignments, consistent validity periods, and state transitions. Reconcile active, blocked, and deletion-marked record counts by object type and organizational scope. Do not treat a missing record in the next snapshot as proof of deletion: it could reflect a missed load, a filter, or replication delay.
This material is limited to three SAP Help documents on Business Partner numbering, G/L account changes, and partner-data deletion. The numbering page describes SAP S/4HANA and SAP S/4HANA Cloud Private Edition; the other pages cover S/4HANA On-Premise. The full lifecycle for all master-data types, applicability to other releases, and a specific system's configuration were not researched; no SAP runtime was used.