Ansicht
Dokumentation

CL_XTAX_CALCULATE_TAX_DOC_BUFF - Buffering for RFC_CALCULATE_TAXES_DOC

CL_XTAX_CALCULATE_TAX_DOC_BUFF - Buffering for RFC_CALCULATE_TAXES_DOC

CPI1466 during Backup   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Funktionalität

This text does not need to be translated. It is only for USA and Canada.

What is it?

If a RFC (Remote Function Call) Tax Engine Call for a tax calculation shall be made the buffering mechanism checks whether the same call was made before by comparing the input parameters. If the same call was made before, the RFC Tax Engine Call would not be made and the output parameters from the last call would be returned instead of calling the Tax Engine via RFC once again. The assumption is that the Tax Engine returns for identical calls (input parameters) the same (output parameters)! This mechanism was introduced with note 1300470 and enhanced with note 1649777. Note 1300470 already significantly reduced the overall response time e.g. in FI transactions such as FB01, FB60 by more than 80 %. Note 1300470 (method 1) is working with the item number (POS_NO, ITEM_NO) as key to administer the memory entries. Note 1649777 (method 2) fills the buffer without using this key and builds a hash key based on the input data to find a matching entry for each item because the item number is not stable (identical calls are made with different item no for the same item) or many similar calls are made without item no such as function module CALCULATE_TAX_FROM_NET_AMOUNT (item no 0) e.g. before calling a BAPI.

With note 1705380 we introduced logging capabilities to leverage log points to be able to analyze why certain entries are buffered and why certain entries are not taken from the buffer and a RFC Tax Engine Call is made instead. Thus, this can be analyzed without debugging (check attachment of note 1705380). All those notes are to be applied before analyzing the RFC Tax Engine Call through transaction SAAB!

When you post individual documents, identical RFC Tax Engine Calls are buffered for the tax calculation in order to prevent superfluous RFC Tax Engine Calls. However, this did not work if you wanted buffering to be executed across several SAP sessions, for example, across SRM scenarios, which first calculated the tax using the ERP when the shopping basket was entered and then calculated the tax once again when the shopping basket was posted to the ERP following the approval of a shopping basket. This kind of buffering of RFC Tax Engine Calls for tax calculation per application server (ABAP Shared Objects) across several sessions was introduced with note 2012778, you have to activate it by calling a method (see e.g. 2013594 for SRM).

Method 1 is available with 4.6C upwards and method 2 and the other features are available with SAP_APPL=60000 upwards.

How to use?

For testing you can use

SET/GET Parameter EXTAX_BUFFERING_OFF=X (buffering off) for a user or you can generally turn it off by setting LPARA=0 (see 2)) for RFC Tax Engine Tax Calculation Calls.

1) Method 1 is the default and is always used if note 1300470 is in place, no customizing required.

2) If you want to switch to method 2 or customize the buffer size you can do so:

In view V_T001I (transaction SM30) you can maintain the method and the size of the buffer (Party=EXTXB1 for method 1 or EXTXB2 for method 2, LPARA=1, 2, 3, etc.). Method 1 uses the POS_NO as key as before to administer the buffer and this is the default method which is used even if you do not maintain V_T001I entry, method 2 is accessing the buffer with a hash key derived from the input. If LPARA= 0, then the buffering is not active. If LPARA = 1, then buffer size is 1000 items, if LPARA = 2, then buffer size is 2000 items, and so forth. LPARA and PARTY are the technical field names, the field label of these fields are "Length" and "Par.type". The default buffer size is 99999 items. If the internal buffer size is exceeding the buffer size, the buffer gets cleared. It gets cleared as well when system name, company code, client or document number of the header are different from previous calls.

3) If you want to analyze the buffering or want the system ignore the document number e.g. because SD makes tax calculation calls without document number and for the final RFC Tax Engine Calls with document number leading to more RFC Tax Engine Calls you can avoid this and you can do the analysis of the buffering in the following way. It was introduced with note 1705380:

First step is to run RFC traces by using transaction ST05 with and without buffering (SET/GET parameter: EXTAX_BUFFERING_OFF) to see what difference the RFC Tax Engine Call buffering makes.

Second step is to apply this enhancement/correction which provides additional logging capabilities by leveraging LOGPOINT functions
(http://help.sap.com/abapdocu_70/en/ABAPLOG-POINT.htm), see note 1649777 - you have to maintain V_T001I accordingly and you have to set the SET/GET parameter EXTAX_BUFFERING_LOG = X to activate this logging. This is not for free (performance) and should only be activated to analyze the buffering mechanism. In transaction SAAB you will see the following entries then after activating the logpoint for checkpoint group CL_XTAX_CALCULATE_TAX_DOC_BUFF:
a) GET or PUT entries show part of the content when GET or PUT methods are processed. If a tax engine call has to be made, it shows why and logs the first field which is different (input/buffer). You really have to drill down to see the details.
b) TOTAL or BUFFER entries show how many calls have been made and how many were fetched from the buffer without calling the tax engine.
c) IF you maintain entry EXTXB0 (party) in transaction SM30, V_T001I, the document number does not get compared anymore for the buffering mechanism. Additionally method SET_CLEAR (class CL_XTAX_CALCULATE_TAX_DOC_BUFF) has been introduced to be able to suppress the clearing of the buffer (I_CLEAR <> 1) when method 1 or 2 is used but the buffer should be cleared by the application then by using method clear and parameter FORCE = 1 to avoid memory issues.
d) After analyzing the buffering mechanism with this logpoint function, please deactivate the logpoint for checkpoint group mentioned above and remove SET/GET parameter EXTAX_BUFFERING_LOG.

A step by step description how to analyze the buffering mechanism is attached to note 1705380.

4) Cross session buffering (ABAP Shared Objects) per application server

There is no customizing to use this function. It was introduced with note 2012778.You have to call method CL_XTAX_CALCULATE_TAX_DOC_BUFF=>SET_PARAMETER like for the SRM scenario (see e.g. note 2013594) by means of the Shared parameter (see shared objects at ). With this, the system automatically switches to buffering method 2 and the document number does not get compared for the buffering mechanism anymore like 3c) but without customizing. The application example in SRM is that you enter items and taxes are calculated for the shopping basket. If the shopping basket gets approved by another user later on (another session) the shopping basket gets posted and transferred to FI and the taxes would be calculated again for the same items. For the SRM scenario the number of RFC Tax Engine Calls was reduced by more than 60%. The cross session buffering avoids the RFC Tax Engine Calls and returns the output parameters from the last call. You can administer the ABAP Shared Memory with transaction SHMA, area name CL_XTAX_CALCULATE_TAX_DOC_AREA.

With note 2053364 entries are deleted for RFC Tax Engine Call Tax Calculations from memory during posting. When you use the memory to save the results of RFC Tax Engine Call Tax Calculations via external tax system (see SAP Note 2012778, only shared objects), the system does not release the required memory until transaction SLMA indicates it should be released or it is released explicitly through transaction SLMA. In some cases, the memory may run out. With note 2053364 you can now configure the system - by calling transaction SM30 for the view V_T001I and adding the entry EXTXB4 - to release the respective items of a document from memory when the respective document is posted. Specifically, this occurs when the data is transferred to the tax system for update, which means tax calculation for the document should be complete. The respective occupied memory is then released, which means memory requirements do not grow continuously. If other pending document items of other documents were identical, then this would result in additional RFC Tax Engine Call after deletion from memory. However, this is improbable within the typical time window during which the memory is occupied for transaction SLMA.

With note 2191227 you can override the number of items to be buffered which you configured for the buffering method, see paragraph 2) above, which is the default for cross session buffering, by maintaining view V_T001I, entry EXTXB6. If maintained and the buffer size is not explicitly set by the SET_PARAMETER method, LPARA gets multiplied by 1000000 to determine the number of items to be buffered e.g. 1 and the buffer size is 1000000. If LPARA= 0, then this cross session buffering is not active. Please keep in mind that the buffer size should usually be maintained and handled by the Shared Objects transactions and functions anyway.

Please keep mind that the Shared Objects buffering keeps the data in memory across sessions for a longer time. If you change the external tax engine (configuration, coding, new support packages, etc.) you should also reset the Shared Objects memory (area name CL_XTAX_CALCULATE_TAX_DOC_AREA). Otherwise you might get different output parameters for the same input parameters than before causing inconsistencies because the previous results would still be returned from the ABAP Shared Objects memory but the results for a RFC Tax Engine Call might be different now.

5) Buffering (ABAP Shared Objects) per application server for RFC Tax Engine Jurisdiction Calls

This is similar to the RFC Tax Engine Call buffering for tax calculations but must not be confused with this. It is a separate buffering for the RFC Tax Engine Calls for tax jurisdictions. This was introduced with note 1762268 (SAP_ABA) and 2025548 (FI) and can be activated for specific scenarios like the SRM scenario above by calling a method (example note 2014824 for SRM) or you generally activate this by setting the field buffering to 'X' in table TTXC with transaction SE16 for the relevant entry. You can administer this shared memory with transaction SHMA for area CL_TAX_JURISDICTION_CODE_AREA1. This buffering is available with release 7.31 (SAP_ABA) upwards.

Example: Access is made for the country US, ZIP code 60601, street 303 East Wacker Drive, and Chicago city (RFC Tax Engine Call). The RFC Tax Engine Call returns two entries. During the next identical search (country US, ZIP code 60601, street 303 East Wacker Drive, Chicago city), the two entries found the first time are retrieved from the SAP memory and returned, and no RFC Tax Engine Call is done. Without using the buffering another RFC Tax Engine Call for tax jurisdictions would be made.

Please keep mind that the Shared Objects buffering keeps the data in memory across sessions for a longer time. If you change the external tax engine (configuration, coding, new support packages, etc.) you should also reset the Shared Objects memory (area name CL_TAX_JURISDICTION_CODE_AREA1). Otherwise you might get different output parameters for the same input parameters than before causing inconsistencies because the previous results would still be returned from the Shared Objects memory but the results for a RFC Tax Engine Call might be different now.

6) How much memory is allocated?

To answer this question we created note 2137507 but this does not work for 5) because for this transaction SHMA can be used.

You follow note 1705380 and set SET/GET parameter EXTAX_BUFFERING_LOG to 'L'. The length of the actual entry is determined and logged (logpoint, PUT) then.

If you set SET/GET parameter EXTAX_BUFFERING_LOG to 'T', the memory allocated overall will be determined and logged directly after calling the RFC Tax Engine Call for update.

Instead of maintaining V_T001I, entry EXTXB entries you can also maintain ZXTXB entries in the customer name space, see note 2368987. Thus, these Z entries are not removed by the next upgrade, see also table T001I. These entries override the EXTXB entries - they are used instead if found. If you maintain for EXTXB0 and EXTXB4 or the corresponding Z entries LPARA=99 or ISOCD='99', the corresponding functions will be deactivated. Otherwise you would not have the option to deactivate them without modifying the system if the SAP Standards comes with it.

The following settings will be made generally available in SAP Standard and will become SAP Standard default settings with note 2362940: Entry EXTXB2 (party), LPARA=40, to switch to buffering method 2 (see 2) and increase the buffer size to 40000, Entry EXTXB0 (party) to ignore the document number (see 4), Entry EXTXB6 (party), LPARA=10, to set the default buffer size for the Cross session buffering to 10000000, see 4).

Beziehungen

Beispiel

Hinweise

Weiterführende Informationen






CL_GUI_FRONTEND_SERVICES - Frontend Services   PERFORM Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 14109 Date: 20240328 Time: 225629     sap01-206 ( 377 ms )