Hierarchy
EA-FIN (Software Component) EA-FIN⤷
RE-FX-CN (Application Component) Real Estate Contract⤷
RE_CD_CD (Package) RE: Conditions
Basic Data
| Data Element | RECDCFPOSTINGFROM |
| Short Description | First Posting From |
Data Type
| Category of Dictionary Type | D | Domain |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | RECADATE | |
| Data Type | DATS | Date field (YYYYMMDD) stored as char(8) |
| Length | 8 | |
| Decimal Places | 0 | |
| Output Length | 10 | |
| Value Table |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | POSTING_START_DATE | |
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | 1st Postg |
| Medium | 15 | 1st Posting Frm |
| Long | 20 | First Posting From |
| Heading | 10 | 1st Postg |
Documentation
Definition
Use
This date is relevant for legacy data transfer. The date can be entered in the "Term Data" of the contract, in the "General Data" of the rental object, or in the conditions. The date in the condition is given priority over the date in the contract term data, assuming that one is entered.
The date of first posting is used to ensure that contracts and rental objects are properly mapped with regard to the related dates in accounting after a legacy data transfer. In the new system, it is necessary to prevent postings from being made again for the period in which postings were already made in the legacy system. On the other hand, it has to be possible to subsequently enter data that did not exist in the legacy system at the time of the legacy data transfer, but that relates to a period before the legacy data transfer. This data consists especially of retroactive changes to conditions, for instance due to a rent adjustment that takes effect retroactively.
You control how far in the past retroactive changes are possible using the Cash Flow From date. This date specifies the point in time starting from which cash flow records can be created as planned records for postings. The date of first posting (which should be greater than or equal to the Cash Flow From date) specifies the date in the new system starting from which the system should post based on the cash flow.
The Date of First Posting is interpreted for contracts once at the time the contract is activated in the new system; for rental objects it is interpreted at the time they are created (through release of account assignment). At this point in time, the system stores all cash flow records before the date of the first posting and designates them as having already been posted (pseudo actual records). The assumption is that these records were already posted in the legacy system. After their activation, the system treats the pseudo actual records the same as normal actual records. After the time of the activation, the date of first posting is written to the database and can no longer be changed.
Later on, changes that affect time periods in the past could still be necessary. These changes should actually have been handled in the legacy system, but they are now entered in the new system. These changes result in a change to the cash flow in the time period before the Date of First Posting: the cash flow is recalculated. During this recalculation, the system treats the pseudo actual records like normal actual records. Retroactive changes to conditions for periods with pseudo actual records lead to follow-up postings, just as with normal actual records. These follow-up postings represent the amount of the difference between the postings already made (represented by the pseudo actual records) and the necessary postings (according to the condition).
Dependencies
Example
In the legacy system, a monthly condition was entered that is valid from January 1, 2005 in the amount of EUR 100. It was posted until the legacy data transfer (December 31, 2011). At the time of the legacy data transfer, you decide that condition changes are only allowed retroactively back to January 2011.
The condition start date is set to January 1, 2005; the Cash Flow From date to January 1, 2011; the Date of First Posting to April 1, 2011.
After the contract is activated, the following cash flow results:
01/01/2011-01/31/2011 100 euro marked as posted (pseudo actual record)
02/01/2011-02/28/2011 100 euros marked as posted (pseudo actual record)
03/01/2011-03/31/2011 100 euros marked as posted (pseudo actual record)
04/01/2011-04/30/2011 100 euros to be posted (planned record)
05/01/2011-05/31/2011 100 euros to be posted (planned record)
06/01/2011-06/30/2011 100 euros to be posted (planned record)
etc.
After periodic posting for April 2011, the cash flow is as follows:
01/01/2011-01/31/2011 100 euro marked as posted (pseudo actual record)
02/01/2011-02/28/2011 100 euros marked as posted (pseudo actual record)
03/01/2011-03/31/2011 100 euros marked as posted (pseudo actual record)
04/01/2011-04/30/2011 100 euros posted (actual record)
05/01/2011-05/31/2011 100 euros to be posted (planned record)
06/01/2011-06/30/2011 100 euros to be posted (planned record)
etc.
Then the rent is increased retroactively to EUR 105 starting from February 2011 through a retroactive index adjustment. The resulting cash flow is as follows:
01/01/2011-01/31/2011 100 euro marked as posted (pseudo actual record)
02/01/2011-02/28/2011 100 euros marked as posted (pseudo actual record)
02/01/2011-02/28/2011 5 euros to be posted (planned record)
03/01/2011-03/31/2011 100 euros marked as posted (pseudo actual record)
03/01/2011-03/31/2011 5 euros to be posted (planned record)
04/01/2011-04/30/2011 100 euros posted (actual record)
04/01/2011-04/30/2011 5 euros to be posted (planned record)
05/01/2011-05/31/2011 105 euros to be posted (planned record)
06/01/2011-06/30/2011 105 euros to be posted (planned record)
etc.
The system also follows the same logic when a condition is deleted that was transferred from the legacy system: it keeps the pseudo actual records (as well as the normal actual records). The actual records and the pseudo actual records represent the postings made in the current system (actual records) or in the legacy system (pseudo actual records) when the condition was still valid. Since the condition has now been deleted, offsetting postings must be generated so that accounting can then be properly corrected. Therefore appropriate follow-up postings need to be generated.
On the other hand, if a new condition is added (new condition type, new condition purpose or new calculation object), then the planned records for this condition in the period from "Cash Flow From" to "Date of First Posting" are designated as posted (pseudo actual records), since in this case the postings are not follow-up postings. Not until there is a change for this newly created condition are the resulting follow-up postings added as planned records. If you want to create planned records (not pseudo actual records) retroactively for a new condition, you therefore have to set the date of first posting accordingly within the condition.
Example:
Contract term data:
Cash Flow From 01/01/11
First Posting From 04/01/2011
A new retrocactive condition is added to the above contract starting from January 01, 2011. The condition should be posted starting from April 01, 2011 (Date of 1st Posting).
The following cash flow results:
01/01/2011-01/31/2011 100 euro marked as posted (pseudo actual record)
02/01/2011-02/28/2011 100 euros marked as posted (pseudo actual record)
03/01/2011-03/31/2011 100 euros marked as posted (pseudo actual record)
04/01/2011-04/30/2011 100 euros to be posted (planned record)
05/01/2011-05/31/2011 100 euros to be posted (planned record)
06/01/2011-06/30/2011 100 euros to be posted (planned record) etc.
However, if you want to have the system create planned records for this condition starting on January 01, 2011, then you have to explicitly set the date of first posting to January 01, 2011 when you create the condition.
The following cash flow results:
01/01/11-01/31/2011 100 euros to be posted (planned record)
02/01/2011-02/28/2011 100 euros to be posted (planned record)
03/01/2011-03/31/2011 100 euros to be posted (planned record)
04/01/2011-04/30/2011 100 euros to be posted (planned record)
05/01/2011-05/31/2011 100 euros to be posted (planned record)
06/01/2011-06/30/2011 100 euros to be posted (planned record) etc.
History
| Last changed by/on | SAP | 20130529 |
| SAP Release Created in | 600 |
