In this blog I would like to describe some techniques that can be useful if you have specific requirements when transferring values from SD billing into FI. Besides configuration steps, customer-exit EXIT_SAPLV60B_008 (belonging to enhancement SDVFX008) is to be implemented.
The integration between SD and FI happening through account determination is flexible and most of the requirements can be implemented through SD customizing using 2 core areas: pricing and financial account determination. Both are behaving as source of data which prepares necessary values to be sent to FI module.
· The price is determined through a condition technique which is defined in the pricing procedure and in pricing condition type setup (transactions: V/06 – condition type definition; V/07 – access sequence definition; V/08 – pricing procedure definition)
· GL account determination for pricing conditions which are relevant for FI postings (transaction VKOA to assign GL accounts)
The purpose of the article is not to go through IMG steps to setup pricing procedure and condition type and respective GL account determination, this will stay beyond. Instead, we will look into implementation of development exits which can be a solution for requirements that can not be customized through IMG.
I will use an example requirement when condition value should be posted only in group currency 3 (LC3), i.e. postings in LC1, LC2 should stay zero, while LC3 should keep the actual value. This is happening for estimated costs conditions (KW00, VPRS) in standard, but if you have a regular price or freight or discount condition that you should post in such way – then pricing/account determination customizing is not enough, because your condition will be carrying postings in all currencies. However, the exit implementation that will be used can be
So, we have a requirement to have condition in SD pricing procedure maintained in billing and transferred into accounting, but postings should be only done in LC3 group currency (LC1, LC2 – are zeroes). Additionally, value should not affect net value in SD billing, and should appear only in FI.
Looking at this requirement from FI prospective, it makes sense to investigate substitution rules (transaction GGB1) as a possible solution. However, as we are receiving the values from SD module, let’s imply the interface between SD and FI to control this.
The solution will consist of 3 pars:
· SD customizing
· FI customizing
· Development: implementation of SD customer-exit
SD customizing
1. Pricing condition type configuration (tcode V/06)
Create a new pricing condition type that we will use in pricing calculation in SD (in my case – ZJTC created as discount with fixed base). Condition type configuration depends on background of your requirements and refers to standard approach in pricing customizing in SD.
The specific maintenance here is the condition category (field T685A-KNTYP). Using custom category we can make solution more flexible and scalable: if in future you would need to apply same logic to other pricing condition type, you can combine them under same Condition type. This would avoid listing conditions that should be processed specifically in custom tables, etc. Instead, you will know that Customer reserve category is responsible for this.
If needed – create access sequence (tcode V/07) and maintain it in pricing condition type.
![1.png]()
2. Pricing procedure configuration (tcode V/08)
Update pricing procedure with new condition type (in my case - ZVABRI). Important note: condition should be marked as statistical. In this case it will not change net value and will not be posted into CO-PA as normal sales pricing condition.
![2.png]()
3. Pricing procedure determination (tcode OVKK)
Based on sales area, document and customer pricing procedure keys, maintain the necessary record in customizing table in tcode OVKK to setup pricing procedure determination:
.
![3.png]()
4. Revenue G/L account determination (tcode VKOA)
Maintain records in tcode VKOA to specify what G/L account should be determined with the respect to sequence you are using. As we configured condition type as non-accruals, we do not need to maintain provision account. Only G/L account is required in this step.
![4.png]()
FI customizing
Assignment of SD conditions to CO-PA values (tcode KE4I)
To make a link between SD pricing conditions and CO-PA fields, add a record in tcode KE4I and specify new pricing condition type we created in SD part and link it to appropriate value field in CO document:
![5.png]()
Development
Interface transferring SD values into FI in logistics billings customization is complete. At this moment, we made configuration of pricing conditions that are calculated in the billing and the G/L accounts which will be updated based on account determination logic. However, with current setup new condition will not book any value in FI because it is marked as statistical in the pricing procedure. In this case SAP skips it and does not transfer its value into accounting.
To change this, customer-exit EXIT_SAPLV60B_008 (enhancement SDVFX008) would be needed. Here 2 transfer structures XACCIT and XACCCR should be changed as they actually keep figures that will be posted into FI document (table BSEG). Originally in standard logic ACCIT and ACCCR are populated in form ACCOUNTING_ITEM_LINE of program LV60BF00, but we can change the figures in this customer-exit.
In the exit, following parts of the logic should be implemented:
1. 1. Check what pricing conditions are having customer reserve condition category (field XACCIT- KNTYP)
2. 2. For those conditions which match search criteria in XACCIT – add new line in table XACCIT to include it into accounting document (original line stays as is: it is statistical condition, thus it will not be posted).
3. 3. For those lines which were added into XACCIT – add respective records into table XACCCR to show what exact figures should be posted into accounting document.
Reading table XACCIT by condition type (field KNTYP) to determine needed lines with customer reserve type is not so complex. In my case, I will get only one record standing for condition ZJTC. Changing XACCIT and XACCR may be tricky; therefore, here is more detailed explanation on how to perform these steps.
Updating table XACCIT
To add record in XACCIT properly it will be very convenient if you already have KW00 or VPRS condition also transferred into accounting. You can check how these lines are populated by standard SAP logic and build a new line to be added for your custom condition in similar manner. At this moment, a new line should be appended to XACCIT incrementing position number (XACCIT-POSNR). In my example item with position # 0000001025 (on the snapshot) stands for pricing condition type KW00 (which has most similar logic in terms of posting group currencies that we need to capture)
Item with position # 0000001026 stands for new pricing condition ZJTC that we configure.
![6.png]()
Here I added one more line which in final solution should get value from POSNR# 0000001026. New line ID is 27, copy of line 25. POSNR is the next coming in counter, 0000001027. Important note: New line should not be added in very end of the table, as last line should be always 0000000001.
![7.png]()
When inserting new line in XACCIT, you can actually copy it from ZJTC line and change following fields:
XACCIT-POSNR – get last position number in the table (not counting last 0000001) and increment to next ID number
XACCIT-KSTAT - should be blank
XACCIT-HKONT – G/L account determined from customizing. If needed – you can change it here with custom logic, otherwise keep it as it arrived from ZJTC configuration
XACCIT-PRCTR – profit center. Again, can be changed at this moment if custom logic should be applied.
XACCIT-KNTYP – should be changed to ‘b’ . In case LC3 should be the only to update, this works great.
Other fields of the line can be changed, if needed, but as they arrive from customizing in pricing and GL account determination, they should be better changed through customizing.
Updating table XACCCR
In this table group currency figures are stored. If you check it now, you will find line 26 (stands for condition KW00) and line 27 (stands for new condition ZJTC). Line 27 will not be posted into FI because it is marked as statistical (flag is in XACCIT-KSTAT).
![8.png]()
You can add new record in this table manner as in XACCIT, line ID is 28. Be careful here, you would also need to change POSNR because it should refer be same as referenced XACCIT-POSNR (0000001027 in my case). Here following fields are critical to check:
XACCCR-WRBTR – the value to be posted into accounting
XACCR- CURTP – group currency key. If you check other sales conditions, you will see 4 lines per condition: one for each group currency key. That’s why in accounting document regular sales conditions are posted in all group currencies. When adding new record, specify group currency in which posting should be done and keep only it. I add record for LC3 posting, thus I skip group keys 00, 10, 30 (standing for Document currency, LC1, LC2) and only add group currency 31 (for LC3)
![9.png]()
I extracted both tables content in the files so that you could check them to see exactly how lines where populated (find them in attached text files). Please refer to position IDs I was mentioning in the text to find them.
Once done, here is the accounting document generated. New line added into ACCIT and ACCCR is highlighted. Calculation of variance adjustment is also correct, we do not need to run it explicitly in the exit.
![10.png]()
SUMMARY
To fulfill the requirement – get pricing condition, which is maintained in billing and is posted only in group currency LC3 – we proceed with standard customizing of pricing procedure and GL account determination. Condition category in pricing condition type is changed to Customer reserved, as we are attaching further development logic to this category and make solution easily scalable.
To change the values transferred from SD to FI, customer-exit EXIT_SAPLV60B_008 is to be used where with custom logic we add entries in tables XACCIT and XACCCR to transfer additional lines into accounting document. Once reading XACCIT to find records with customer reserved condition category, we then add records into tables XACCIT and XACCCR to add them into posting.
