Вы находитесь на странице: 1из 5

Rebates calculation Rebates details There are several predefined rebates types in system.

RTL1 Info growth Rebate percentage on total sales, manually calculated. Calculated once a year. FI entry is posted as one entry to each vendor account. Reason: paid by supplier to get scanning information ( share and compare category information against other vendor with same category) RTL2 Distribution Rebate - percentage on total sales amount per month monthly, Purch.org./ Vendor/Site based condition, only for the warehouse delivery. Cover our cost to distribute from WH to stores. RTL3 Settlement Rebate - percentage on total sales, vendor based condition, monthly calculated. Cover a less settlement period than the normal 60 days. RTL4 Rebate Vendor - percentage on total sales, vendor based condition, monthly calculated. Is a rebate based on CTA negotiations. RTL5 Invoice Rebate Value - fixed amount monthly, vendor based condition. Covers market levy. RTL6 Damage Rebate - percentage on total sales, vendor based condition, monthly calculated. Covers damage incurred if the vendor does not take back the damages. RTL8 Growth Rebate Value percentage on total sales, vendor based condition, manually calculated. Represent the growth value, % on slabs, from a previous year growth. Calculated once a year an FI manually entered RTL9 Brand Contribution - fixed amount monthly, vendor based condition. Cover marketing cost. RT10 Promo Contribution - fixed amount monthly, vendor based condition. Cover promo cost

Rebates updates The base for rebates updates and calculation is vendor CTA. Based on CTA, every year a summary excel sheet is updated for each vendor with all rebates and conditions In system, only monthly processed conditions are updated.

In SAP an agreement is created based on CTA/above details. For each vendor all rebates are added on same agreement, system has one agreement per vendor per period. The agreement is based on a fixed period, mentioned in CTA. Transaction MEB1 Agreement type Agreements are created per purchase organization and group For each agreement required data are: vendor code, currency, agreement period All conditions, currently defined are added one by one.

For each rebate a condition table exists.

or

CTA conditions are added based on key combination defined for each rebate. Rebates are based on % or fixed amount A review /change of condition types can be done with MEB2/MEB3

Rebates calculation Rebates calculation and FI entries are processed using report ZREBATE.

The report selects all entries from vendor account for the period where the date entered in selection screen belongs. For example if date entered is 31.5.12 all entries posted on period 05/2012 are selected. If there are no document entries in a period, report calculates only fixed amount rebates, if any. The selection includes invoices, returns and claims Report identifies if rebates are posted for a period and does not calculate again. IF no date is entered system use the current date as reference Specifications for the report are below: 1. Select period 2. Format the names of the sessions with month and year 3. Get the purchase org. of the company code entered on the selection screen 4. a. Fetch the rebate agreement from table KONA for the selected vendor where agreement type is Z001 for the purchase org of the company code and agreement status is open. b. Check if there are more than one rebate agreements per vendor c. Fetch from KONH table for the agreements selected, where application is VB and condition type between RTL2 and RTL9 and RT10. d. Fetch the corresponding record from the item table KONP and consolidate into an internal table e. Based on the condition type, calculate each rebate. 5. For each vendor, a. Fetch the vendor name from LFA1 b. Fetch the currency code from LFM1 c. Consolidate data into internal table 6. Fetch the open items from table BSIK for the vendor and company code, month and year where document type is RE (Invoice Gross) or RA (Sub.cred.memo stlmt). Fetch the corresponding documents from table BSEG and based on the value of the company code, site, currency key , debit or credit compute R0004, R0007, R0034, R0035. 7. Fetch the cleared items from table BSAK for the vendor and company code, month and year where document type is RE (Invoice Gross) or RA (Sub.cred.memo stlmt). Fetch the corresponding documents from table BSEG and based on the value of the company code, site, currency key , debit or credit compute R0004, R0007,R0009, R0010, R0034, R0035. 8. For all the accounting documents fetched in step 7 and 8, check if the document currency matches the vendor currency. Also fetch the site and the profit center for these documents from BSEG.

Company Code 3000 6000 7000 5100 9200 9. 10. 11. 12. 13. 14. 15.

Profit centre 3211 611101 720101 5130 911101

Create session for Settlement Rebate R0034 using transaction code F-41 Create session for Incentive Rebate R0035 using transaction code F-41 Create session for Distribution Allowance R0004 using transaction code F-41 Create session for Damage Allowance R0007 using transaction code F-41 Create session for Marketing Allowance R0031 using transaction code F-41 Create session for Brand Contribution R0009 using transaction code F-41 Create session for Promotion Contribution R0010 using transaction code F-41

If the report is run twice for same period and vendor, 2 bdcs will be created but only one will be posted. Second one will return the incorrect value. Report will create one set of BDCs for each rebate. The set contains all FI entries. The BDCs are manually processed.

FI documents details For each rebate a Debit entry is posted in vendor account. Credit entry is posted in expense account as follows. RT10 RTL1 RTL2 RTL3 RTL4 RTL5 RTL6 RTL8 RTL9 Promo Contribution Info growth Rebate Distribution Rebate Settlement Rebate Rebate Vendor Invoice Rebate Value Damage Rebate Growth Rebate Value Brand Contribution 101264 101240 101280 101230 101245 101264 101245 101240 101264

The line item does not contain any reference to rebate type except the text field, this makes difficult to extract the data for further reports. The posting key is not a valid reference as can be used by other functions. Suggest to include it in a text field in BSEG line item.

Вам также может понравиться