Hierarchy
⤷
⤷
Basic Data
| Data Element | XINCPAYMENT_AS_SEP_UNIT |
| Short Description | IS-M: Incoming Payment via tRFC as Separate Transaction |
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 | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | tRFC SepTr |
| Medium | 15 | tRFC SepTrans. |
| Long | 20 | tRFC Sep. Transac. |
| Heading | 1 | S |
Documentation
Definition
This indicator allows you to control whether tRFC calls (transactional RFCs) for continued processing of the payment in Media Sales and Distribution take place with the optional parameter AS SEPARATE UNIT for incoming payments in Contract Accounts Receivable and Payable.
We recommend that you use this option in smaller installations or in the initial phase after going live.
When incoming payments or additional payments are posted for renewal subscriptions from Contract Accounts Receivable and Payable (FI-CA) in stack processing, a Commit is performed for a block after n documents (for example, in the case of check locks, after 20 documents). The data in IS-M/SD is updated for each document by means of a tRFC at event 0030. However, the tRFC is in fact executed for all the documents in a block at the same time, due to the Commit handling procedure. These documents are then regarded as an LUW.
If you select this indicator, each incoming payment document is updated individually in IS-M/SD. The disadvantage of this procedure is that a much larger volume of data is transferred by the tRFC.
If you do not select this indicator, the volume of data transferred by the tRFC is smaller. However, the data in a block is not then regarded as one LUW.
This can lead to problems, particularly in error processing; for example, if an error occurs while processing a block. If this is the case, the system performs a rollback and all the documents in this block are listed in transaction SM58 for postediting with the same error message.
History
| Last changed by/on | SAP | 20050224 |
| SAP Release Created in | 473 |