Handling of installation facts
This document describes how facts are handled during the replication of CRM processes into IS-U.
General remarks
Contract related operands versus product related operands
Contract related operands get inactive time slices in ETTIFN during move out. This means that the system "remembers" the old situation and when the move- out is reversed than the old situation is rebuilt again by using inactive time slice from ETTIFN and reactivating it.
For product related operands table ETTIFN doesn't play this big role. During move-out the time slice in ETTIFN gets an end date (which is the move-out date), but no inactive time slices will be created and therefore no reactivation takes place. That's the case because during cancelling of move-out the MDT is processed and the time slices are created according to the settings in MDT.
When an operand is marked as contract AND product related than the product relation has higher priority and hence such an operand is treated like an operand which is only marked as product related.
It is recommended to set all operands used in the Master data templates (MDTs) as product related. This ensures that the maintenance of it is only possible during MDT processing and not in IS-U directly which can help to avoid data base inconsistencies.
Furthermore, contract related operands are not considered from all processes (for i.e. product change process) during the processing of MDTs using the master data generator (MDG).
In case product related and contract related operands are used within the MDT, the last processed operation is MDT processing. In case a move-out reversal is executed at first the contract related operands are restored directly at DB level but afterwards might be changed again due to MDT processing.
Generation period
The generation period must not be necessarily the contract validity time. It depends on the process which time slice is (re)generated processing the MDTs. This is important when a date is determined over a virtual attribute in the MDT. When the start or end date is outside of the date range of the generation period - they will be not considered and the generation period will be taken at all.
External Attributes in MDT
An MDT is assigned to an utilities product. All parameters from the utility product are marked as external (see tab header data). That’s important as some processes only consider external parameters assigned to an attribute in MDT. When a parameter is assigned to an attribute within the MDT it gets a green status.
Determination of full generation
In some processes the generation isn’t triggered in standard as it is not needed. In this case the system always checks if a full generation should be done.
This is done by taking the values for the external attributes of MDT from the database and comparing those values with the values sent from CRM container.
If they are the same the system decides that nothing is to be changed/generated. Only in case there is a difference a full replication is triggered and then the MDT is called.
If prices are replicated from CRM, always a full generation is triggered.
To influence the container BAdI ECRM_CRM_UPLOAD with method IF_EX_ECRM_CRM_UPLOAD~ECRM_UPLOAD_FILL_CONTAINER can be used.
Handling of installation facts during replication in several processes
The description is valid for operands marked as product related. In case of contract related operands the handling can differ.
New Contract – Move-in
The MDT is always triggered and facts are generated starting with contract start date.
Generation period: Contract start date until 31.12.9999
Contract end – Move-out
Per default the MDT isn’t triggered (except the price replication is used) and the facts are just cut off to the contract end date.
When a full generation is determined the generation period is:
Contract start date until contract end date
Product change
The facts were changed in two steps:
1) The existing time slice is limited to the product change date – 1 day
2) The new time slice is generated starting with the product change date
Generation Period: Date of product change until 31.12.9999
Product change cancel
The facts were changed in two steps:
1) The new installation fact time slice which has been created during the product change is deleted.
2) Starting from this date the fact is re-generated according to the settings of MDT which is used from the old product.
Generation period: Date of product change until 31.12.9999
One important thing is to mark the operands as product related, otherwise they will not be considered correctly (also during the deletion process).
Cancel contract start
All operands which are created by using the external attributes as parameter in the MDT are deleted. All operands were the attributes are defined as constant just remain as they are.
The installation history is not changed (see KBA 1998263).
RGEN cases
Basically the RGEN case is treated 100% equally between CRM and IS-U, no matter where the process is started, no matter how much additional attributes are sent from CRM.
The system determines the database value for all external attributes of MDT and puts those in a container. The container sent from CRM is totally ignored.
The product attributes should be available in the container as long as they are well defined in MDT and also assigned to the product in CRM. This means all external attributes of the used MDT should be available.
To influence the container BAdI ECRM_CRM_UPLOAD with method IF_EX_ECRM_CRM_UPLOAD~ECRM_FILL_CONTAINER_RGEN can be used.
Basically there are the following RGEN scenarios:
- Move out date is extended (e.g. 15.10. to 31.10.)
- Move out date is extended to 31.12.9999 (move out reversal)
- Move-in date is shifted prior to the previous move-in date (e.g. 15.10. to 01.10.)
To influence the processing BAdI ECRM_CRM_UPLOAD with methods IF_EX_ECRM_CRM_UPLOAD~MOVEOUTDATE_CHANGED or IF_EX_ECRM_CRM_UPLOAD~MOVEINDATE_CHANGED can be used to define Follow up actions after the processes were executed.
Change move-in date
If the move-in date is changed to the future the data already exists and so the date is just shifted to the new move-in date an no data in installation history nor installation facts are changed.
If the move-in date is changed in the past than the data starting from new move-in date has to be generated using MDT processing.
Generation period: New move-in date until old move-in date – 1 day
Change move-out date
In case move-out date is changed to the future: See process cancel contract end.
In case move-out date is changed to the past, time slices are just cut off to the new move-out date as all data already exist.
Cancel contract end
A Cancel Contract End is nothing more than a change of move-out date to 31.12.9999.
In general the system keeps the already existing data and generates starting with move-out date + 1 until 31.12.9999.
Generation period: Old Move-out date + 1 day until 31.12.9999
Contract correct or Contract change
The facts were adapted with the new values starting with (new) contract start date. Facts already created (wrongly) will not be deleted but just remain as they are.