You can use the article hierarchy as a planning hierarchy. When you create a new assignment, this assignment can be used as of a certain point in time in operational processes. For the majority of new article hierarchy elements, however, a plan is created first before they can be used in the applications.
When you create a new assignment, detailed assortment planning is performed first, for example, in which the new article assignments are determined. This assignment can be used in the operational applications after a certain point in time.
Other objects are active straight away without planning and can therefore be used immediately in the operational applications. In the planning cycle, existing elements that have been used in operational applications regularly undergo new planning.
The anticipation of future changes to structures is required in planning processes, such as Retail planning, and in operational applications, as these work with the structures that will be valid in the future. The following examples illustrate this requirement:
a. The OTB is planned and checked per subcategory node. An article is assigned to another subcategory node as of a certain point in time. As this is already known/planned today, the OTB check must take this planned change into account and determine the subcategory node to which the article belongs for the delivery date, before the actual check.
b. A subcategory node is assigned to another category node or split into two subcategory nodes as of a certain point in time in the future. This information is relevant in retail planning. Firstly, this is how you can determine which subcategory nodes of a category node need to be planned, and secondly, the planner needs to be able take into account the fact that the structure will then change.
To map scheduling, every node assignment in the article hierarchy can be assigned a valid-from date or a valid-to date. These periods of the node assignments must not overlap. You can map periods with gaps between them. You can stop the mapping of validity periods with gaps using a customer enhancement without modifications.
When the valid-from date is reached, an assignment can be used operationally in the SAP system. When the valid-to date is reached, a deletion indicator is automatically set for the assignment. The assignments can then finally be deleted using a deletion report. This deletion report can work with a time-based buffer so that the assignments can be kept in the system for a while even after the valid-to date has been reached and after the deletion flag has been set.
Once the valid-to date has been reached and the deletion flat is set, you cannot assign any more articles. The articles that are already assigned have to be reassigned or deleted from the article hierarchy. At higher levels, the subordinate nodes have to be deleted or reassigned. A check is performed to make sure this has been done before the final physical deletion takes place.
The following graphic shows how scheduling behaves in the system for the individual business transactions. The graphic distinguishes between normal business transactions and OTB-relevant business transactions. An OTB-relevant business transaction is, for example, the subcategory (if this level is declared as an OTB level). A distinction is also made between assignments that are already valid, that is operational, and assignments whose validity period is in the future. The statements in the table apply to both node and article assignments.
In the case of scheduled reassignment of article and node assignments, you can change both the valid-from date and the valid-to date of the schedule record. The following applies regarding the check and modification of existing schedule records:
· The schedule record is merged with an existing previous and/or subsequent schedule record if the system does not allow mapping with gaps or if there are no gaps.
· If the schedule record overlaps existing previous and/or subsequent schedule records completely, these schedule records are deleted by the system.
· If the schedule record partly overlaps an existing previous and/or subsequent schedule record, these schedule records are adjusted by the system.
· If the schedule record lies completely within an existing previous and/or subsequent schedule record, it is split by the system.
You can check changes to the validity periods of article/node assignments in article hierarchy maintenance in a customer enhancement (BAdI) without modification.
In the case of scheduled reassignment of generic articles including variants (see Template Handling/Generic Article Handling), the following applies regarding validities:
· If you reassign a (future) generic article, all future schedule records for the generic article and the variants whose valid-from date is later than or equal to the valid-from date of the generic article to be reassigned are taken into account.
· Schedule records for the selected variants or for all variants that are assigned to the same node as or to a different node than the generic article are not taken into consideration.
· If the generic article and all its variants are reassigned, cross-category reassignment is permitted.
· In the case of a cross-category reassignment, the assignments (generic articles and variants) to the new parent node are treated as new assignments, that is, there is no time-based relationship between the assignments to the old and new parent nodes.
· In the case of cross-category reassignment of main assignments, the new assignments take the main assignments with them (valid-to date is infinite). The old assignments lose the “main assignment” attribute when the valid-to date is reached.
· The result is new future schedule records of all variants with the validity of the new future schedule record of the generic article.
In the case of the scheduled creation of article assignments, the following applies to the validity:
· You must always create main assignments with a valid-from date as the current date and a valid-to date as the value 31.12.9999 (infinity).
· You can create secondary assignments (in the case of multiple article assignments) with any valid-from and valid-to dates.
The following deletion logic applies to the scheduled deletion of article/node assignments in article hierarchy maintenance:
· - Deletion of node assignments with only one schedule record
¡ In a planned hierarchy
§ Without article assignments
Deletion is possible at any time (depending on the Customizing settings).
§ With article assignments:
The main assignment can be deleted if there are no secondary assignments and only one schedule record for the main assignment exists.
¡ In an active hierarchy
§ Without article assignments
Only future schedule records can be physically deleted; valid schedule records can be flagged for logical deletion. Non-scheduled node assignments cannot be deleted.
· Deletion of node assignments with several schedule records
¡ Without article assignments
Deletion is possible at any time.
¡ With article assignments:
Only possible if the BAdI for deactivating the standard validity check is active.
The validity of a node assignment must always fall within the validity of the parent node assignment. This is checked in the system.
You can make the validity of an article assignment different from the validity of the parent node assignment. For example, a main assignment can be assigned below a limited, time-based node assignment.