Receivables and Payables as First-Level Objects
The following question needs to be investigated: Why do receivables and payables appear as first-level objects although they have received their assignment from another object?
In general, the system considers such receivables and payables (as well as partial amounts of these) as objects on the first level of the derivation hierarchy that have received their profit center assignments directly and not from another object (such as a cost center).
Furthermore, the system also considers receivables and payables as first-level objects in the following cases:
All objects that impart the assignment are closed in the hierarchy.
The analysis of the origin of the assignment has failed.
All objects that impart the assignment are closed in the hierarchy
Partial amounts are also shown as first-level objects when all of the objects that impart the assignment are closed in the hierarchy.
After the system has determined the objects from which a receivable or payable has received its assignment, the system analyzes whether the object that imparts the assignment is included in the reorganization or whether it has already been closed:
When the object is already closed and the object that imparted the assignment as well as all objects in the hierarchy are also closed, the receivable or payable is treated as a first-level object. The object owner then needs to decide on the profit center to which this part of the receivable or payable needs to be assigned.
If the object that imparts the assignment is closed but the object from which it received this assignment - or any object in the hierarchy - is open, the object is included in the reorganization. In this way, the part of the receivable or payable is reorganized in accordance with the object.
Example
A payable has received its profit center assignment from an internal order. If the internal order is already closed, it is not included in the reorganization. Although the payable itself is still open, it is not included in the reorganization in this case. Since the internal order does not appear in any object list and the object owner consequently cannot enter a new profit center, a new profit center has to be entered for the payable. For this reason, the payable appears as a first-level object.
Example
However, if the payable has received its assignment from a delivered, unassigned purchase order item, the purchase order item itself is not included in the reorganization. However, if the object that imparted the assignment, the material, is included in the reorganization, the object owner enters a new profit center in the object list of the material. This profit center is then used for the payable as well. In this way, the payable does not appear on the first level.
Note
A receivable or payable is only included in the reorganization when the object from which it receives its assignment meets the restrictions defined in the reorganization plan.
Since the analysis of whether or not objects that impart assignments are included in the reorganization has a very long runtime, it is only run when the object lists are generated for first-level receivables and payables but not during reassignment. Consequently, receivables and payables that receive their assignments from objects that are closed cannot be reassigned until the analysis has been run.
Recommendation
For this reason, we recommend generating object lists for first-level objects every now and again.
To force execution of the above analysis and thereby prevent receivables and payables from being left out of the reorganization, the system checks - at the very latest when transferring the last receivable or payable - whether an object list needs to be generated again on the first level.
The analysis of the origin of the assignment has failed
Receivables and payables also appear as first-level objects when the analysis of the origin of the assignment (by means of simulating document splitting) has failed. In this case, it is no longer possible to determine the object from which the profit center was derived. This generally applies in the following cases in particular:
Inherited Assignments and Default Assignments
The receivable or payable has received a part of its assignment by inheriting it or as a default assignment and not as a result of rule-based document splitting (whereby a causal relationship dictates the assignment). In this case, it is not useful to reorganize the object in the same way as a higher-level object. The system therefore portrays this part of the receivable or payable as a first-level object.
Invoice References
The receivable or payable is posted with an invoice reference to another receivable or payable (such as a residual item or a partial payment). In the following cases, the object is portrayed as a first-level object:
The related document cannot be found or could not be analyzed.
A complicated document chain was posted, and, as a consequence, the original invoice containing the objects that impart the assignment cannot be found.
NoteFor performance reasons, the document chain is only traced back one step.
End of the note.Document Summarization
Document splitting is simulated using the posting data stored in the document. When document summarization is activated, selected fields are not stored in the document and are consequently not available in the simulation. If, for example, you have made settings in Customizing for the reference transaction RMRP so that the field
Purchase Order Item
(BSEG-EBELP) is summarized, it is not stored in the document upon invoice receipt. (You make this setting in Customizing forGeneral Ledger Accounting (New)
under
Periodic Tasks
Integration
Materials Management
Perform Document Summarization for Materials Management
). In this way, the reference to the purchase order item can no longer be established for a payable. In this case, the payable is made a first-level object.First Generation of Payables After Closing the Prior Period
When payables that are posted by invoicing are generated, invoicing has to be simulated entirely. Due to validation within invoicing, errors can occur in the simulation when the prior period is already closed. If an error occurs, the payable appears on the first level.
RecommendationAs a general rule, we recommend generating first-level object lists (for payables also) before opening the reorganization period.
End of the recommendation.Resetting Clearing
As a result of passive document splitting, a receivable or payable with an invoice reference (such as a residual posting) has received its assignments from a receivable or payable that has already been cleared. When clearing is reset (without reversal), the residual item loses the invoice reference to the receivable or payable that had formerly been cleared. In this case, the origin of the assignment is invalid. For this reason, the receivable or payable appears on the first level.
Errors that occur during simulation of document splitting are listed in the log for the object type Receivables
or Payables
.
Note: A receivable or payable is only ever simulated once. If simulation of the receivable or payable has failed for a reorganization, it also appears on the first level in all subsequent reorganizations.