Hierarchy
⤷ PSM-FM (Application Component) Funds Management
⤷ FMFG_BLCORE_E (Package) Core of the Budgetary Ledger
Basic Data
Data Element | NO_PREDECESSOR |
Short Description | Correct Entries Without Predecessors |
Data Type
Category of Dictionary Type | D | Domain |
Type of Object Referenced | No Information | |
Domain / Name of Reference Type | XFELD | |
Data Type | CHAR | Character String |
Length | 1 | |
Decimal Places | 0 | |
Output Length | 1 | |
Value Table |
Further Characteristics
Search Help: Name | ||
Search Help: Parameters | ||
Parameter ID | ||
Default Component name | NO_PREDECESSOR | |
Change document | ||
No Input History | ||
Basic direction is set to LTR | ||
No BIDI Filtering |
Field Label
Length | Field Label | |
Short | 10 | No Preds |
Medium | 20 | Correct w/o Preds |
Long | 40 | Correct Entries Without Predecessors |
Heading | 25 | Correct w/o Predecessors |
Documentation
Definition
To correct Funds Management (FM) entries without a predecessor document
Use
Only use this feature for exceptional cases and with great care. If this option is selected, the Budgetary Ledger (BL) correction program will process those documents for which no FM predecessor entries are found. This could happen if the predecessor entries were not generated in FM or the transaction numbers (field TRANR) in table FMIOI and FMIFIIT do not match, say, as a result of FM reposting.
In theory, for every posting in FM, the FM original entry (successor) and the FM reduction entry (predecessor) should have identical values stored in TRANR. However, it could happen that this does not hold true.
The default behavior of the BL correction program is to issue an error message in the Application Log and to not process documents with such FM data problem. However, if selected, this option causes the BL correction program to issue only a warning; it continues to process these documents.
Keep in mind that correcting these documents without FM predecessor entries may not be the complete equation since those FM predecessor entries have not been considered. As a result, you may have to correct the predecessor documents without matching FM successor entries. To do this, you can use the other complementary option "Correct Entries Without Successors".
See below for an example of a case where this option "Correct Entries Without Predecessors" may be used.
Dependencies
Example
You have a purchase requisition (PR) document PR1 for $100. Then you create a purchase order (PO) document PO1 referencing this PR. Table FMIOI may be updated with these entries:
For the posting of the PR1:
REFBN REFBT BTART STUNR TRANR FKBTR
PR1 010 0100 3000000000000001 3000000000000001 -100
For the posting of the PO1:
REFBN REFBT BTART STUNR TRANR FKBTR
PR1 010 0200 3000000000000002 3000000000000002 +100
PO1 020 0100 3000000000000003 3000000000000003 -100
Notice that the two entries generated by the PO1 posting have different TRANR. Normally, they should have the same TRANR. So if you do not select the option to correct entries without predecessors, you get an error from the BL correction program complaining that it could find the predecessor for the PO1. If you so desire, you can still correct this PO1 using this option and the following entry will be used by the BL correction program:
REFBN REFBT BTART STUNR TRANR FKBTR
PO1 020 0100 3000000000000003 3000000000000003 -100
As you can see, you have only corrected half of the picture because the PR1 reduction entry was not picked up. To have a complete picture, you have to run the BL correction program for the PR1 using the other option to correct entries without successors. The following entry will then be processed.
REFBN REFBT BTART STUNR TRANR FKBTR
PR1 010 0200 3000000000000002 3000000000000002 +100
History
Last changed by/on | SAP | 20040322 |
SAP Release Created in | 500 |