Rebate Acccural Accounts

Dear SAP SD Experts ,
1. In case of Rebate Accurals we have the Account determination as follows.
for Material Rebate:      Account key ERB and Accural Key ERU.
In the Account determination What I find is G/L Accounts Have been hit with ERU accural keys
But what Happened to ERB ---there is no posting in G/l Accounts.
Please explain this ?
2.
and Next Question is in VKOA What is the Purpose of the Provisional accounts G/L
What I can see is the G/L Account is debited and Provitional Account Creditted.?
Regards,
A S
Edited by: SAP Consultant on Nov 29, 2008 2:54 PM

Dear SAINATH,
What I can see i will Just Elaborate:
BO02 (Rebate material)      Assignment Account Key  (ERB)                        Accural (ERU).
In the T-code: VKOA:
Chart of Acc+ Condi Type+ Custo Acc Grp+ Mat Ac Grp)
+ ERB   =  45022800
2nd
Chart of Acc+ Condi Type+ Custo Acc Grp+ Mat Ac Grp)
+ ERU     =       14780010 (G/L )     &    14780040 (Prov. G/L)
In VF02 Condition Type BO02 double click
Shows that ERB = 14780010 (G/L )
&               ERU = 14780040 (Prov. G/L)
Accounting document : (G/L) Debit  and (Prov. G/L) Credit entry
Now My Qyestion is ERB is assigned to different G/L Accounts Why there is no entry in the Accounting document for G/L 45022800.
Please explain
regards,
A S

Similar Messages

  • Clearing Rebate GL account- Accrual & settlement

    Hi,
    Require your help for the clearing of Rebate Accrual account. We have the following set of entries:
    Initially when you accrue rebates, the following entry is passed
    Accrued Expense a/c Dr.
    Accrued B/S a/c Cr.
    Then when you actually pay to customer then the journal entry that is passed is:
    Customer Cr.
    Accrued Expense a/c Dr.
    Accrued B/S a/c Dr.
    Accrued Expense a/c Cr.
    How the accrual B/S GL account isis cleared - at the time of settlement (how) or automatic clearing (how - what parameters). Please revert
    Thanks
    Amit

    Hi
    You can create automatic clearing setting for this GL account giving the unique parameters for the line items.
    Regards,
    Lakshmanan Krishnan

  • How to fix rebate accrual accounts not clearing when rebate paid?

    Automatic clearing of the rebate accrual accounts fails. The credits are created by the rebate accrual functionality. When the rebate payment is made, it should clear against the accrued items. It does not. This might be due to missing account assignment.
    what config. I should be making and where? Thanks.

    Hi Cathy
    in pricing procedure check these settings "7 in Sub total Key" , "23/24 in requirement " and "ERB for account key" , & " ERU for accrual psotings".
    may be if these settings are maintained fine it should work ,
    Cheers

  • Need clarification on Rebate condition account keys

    Hi Guys,
    I need some clarification on Rebate condition account keys .Question is why rebate condition type has two account keys eg.ERB & ERU and why not we make it seperately as other conditions .APPreciate your comments on this .
    Thanks and regards
    Amar

    ERB: is the account key for Rebate Rate
    ERU: *is the account key for the Accrual Rate*
    As you know both these Account Keys are assigned to the Rebate Condition Type in the pricing procedure. All the Rebate &
    Accruals are posted in the separate G/L Account for the Rebates. So, ERB for rebate this account key posted to revenue a/c
    ERU is price this is posted amount to accrual a/c
    To further explain it.
    ERB acct key which is used to record the sales deductions amount.
    System will keep the track of billing documents relevant for rebate processing. System automatically posts the accruals so that accounting has an overview of the accumulate value for the rebate..the value will posted in the G/L account based on ERU.
    Hope it can assist you.
    Thanks & Regards
    JP

  • Rebate Settlement Accounting Postings

    Hello
    I am configuring extended rebate agreements.  In order to handle the rebate accruals, i have set up G/L account and provision account, maintained my price procedure with appropriate account key and accrual key.  Accruals work fine as follows
    DEBIT G/L ACCT 420050
    CREDIT ACCRUAL 122555
    My issue is with settlement...partial or final.  I am using t-code rbt_enh_v7 to create the settlement docs.  I want the accounting to be like this
    DEBIT ACCRUAL 122555
    CREDIT PAYER CUSTOMER
    If i set the agreements to always correct, my accounting on both partial and final settlements is
    DEBIT ACCRUAL 122555
    CREDIT G/L 420050
    DEBIT G/L 420050
    CREDIT PAYER CUSTOMER
    If  i set my agreements to never correct, then i effect the partial settlement where
    DEBIT G/L 420050
    CREDIT PAYER CUSTOMER
    And then the accruals are reversed with the final settlement.
    Is there any way to set configuration so that when i settle, i simply debit accrual and credit customer without first reversing to the expense account or am i locked into this method of accounting with rebates?
    Best regards

    Hi Thomas,
    Can you specify the example with amount?
    To me:
    "If i set the agreements to always correct, my accounting on both partial and final settlements is 
    DEBIT ACCRUAL 122555
    CREDIT G/L 420050
    DEBIT G/L 420050
    CREDIT PAYER CUSTOMER"
    this serves your purpose since the same GL account is getting debited and credited so effect should be nil and net entry is what you want.
    Regards,
    Naveen Aggarwal

  • Rebate processing & assign provision account

    Hi
    When configure rebate processing ,account determination for rebates / assign G/L account / accounting key  step we maintain table like below.
    application/condtype/chartAcc/salsOrg/Actkey/GL acc/provision acc.
    Here I have a doubt.what is the purpose of assign the provision account number
    thanks&regards
    sagar

    Hi Sagar,
    The provision account number is where the rebate amount from the invoices is posted to during the rebate period. It is posted with an approximate percentage as the precise percentage will only be known, when the agreement is settled. At the time of the settlement the actual sales is summed up and depending on the agreement details a percentage is found to calculate the final rebate amount. The credit note for the settlement will clear the provision account for the amount posted during the rebate period.
    best regards
    Michael

  • Rebate settlement clearing issue

    Hi,
    We are using rebate agrement and for each billing doc an accrual doc is generated
    Sales ded Dr                   XXXX
    TO Rebate Accrual CR   XXXX
    assume 100 docs are posted during the period as above
    on year end fon inal settlement summation of above 100 accruals are reversed by system as under
    Rebate Accrual DR     XXXX
    To sales deduction     XXXX
    We have following issues:
    - system do not clear open items in Rebate accrual account
    - difficult to perform auto GL clear as cannot update assignment field with rebate agreement number.
    Need your help
    - is there process to perform auto clear or get assignmetn updated with agreement number.
    Regards,
    At

    Hi,
    I want to perform auto clearing as you said but i don't see any criteria to clear this.
    Also cusotmer cannot be used as we are having multiple rebate for an customer.
    Regards,
    At

  • Rebate Agreement accruals invoice reports

    Hi Team,
    As per my client requirement we need to prepare the below  rebate agreement accruals invoice report.
    Rebate agreement
    Rebate recipent
    Customer
    Invoice date
    Invoice
    Invoice Item Number
    Rebate Material
    Rebate material net quantity
    Invoice price
    Rebate accural  condition ( % or $)
    Total Rebate amount
    GST
    20000
    123456 (payer)
    1000
    01.01.2014
    987654321
    110
    ABC
    20
    10.00 $
    $ 10.00
    $ 10.00
    20000
    123456 (payer)
    1000
    01.01.2014
    987654321
    140
    ZYX
    5
    5.00 $
    $ 0/50
    $2.50
    We have prepared the report using rebate tables and achieved the results but we missed below one logic here.i.e.
    Business want to maintain the rebate accruals condition records for few customers accounts in the rebate agreement although it’s not related to rebate receipts account.
    Example: rebate agreement: 20000
    Rebate receipt: 123456 (Payer account)
    Rebate condition records
         1)    Customer & material combination – customer # 1000 and material # ABC – 5.0 % - appearing the reports –Status : Working appearing the reports Customer # 1000 Payer is -123456
    2)       Customer # 9999 and material # ZXY – 5.0% - Not appearing the report – Status: Failed
    Customer # 9999 is Payer – 88888 – both accounts are don’t have any PF relationship with rebate receipts # 123456
    When Rebate Condition records are maintaining for Rebate receipt related to customer (SP) account & material combination level in this scenario – Reports working fine .However, few scenarios like business need to maintain rebate accrual condition records for other payer customer accounts in the same agreement in this scenario – Reports is not pulling the invoice accruals due to logic missing our early logic given based on the rebate recipient customer level. I am excepting a technical logic with functional details in this.
    Could you please help me.
    Cheers,
    Jackon Robert

    Hi Omer,
    Proposal:
    Setup your rebate condition as amount = 0 and accruals = $
    The system will do the accounting movements for the accruals as usual
    When doing the final settlement in SD, nothing will be credited to the customer as the rebate condition is zero BUT the accruals will be reversed (as usual when doing the final settlement).
    That should work because it is standard SAP logic.
    On the other hand, it is a pity not to be able to credit the customer if you already have the rebate agreement created in the system.
    Are you 100% positive about this legal issue in your business environment?
    I did a few rebate projects in FMCG and it is standard practice to send credit memo to the rebate recipient: The Customer (Payer in SAP).
    Nobody ever said it was a problem, because practically speaking it is just one more credit note to the same customer that was invoiced beforehand!
    Best Regards,
    Franck Lumpe
    Freelance SAP Consultant

  • Account determination in SAP?

    hii experts,
    Account determination is major concern in SAP.
    Whether account determination will be done only SAP MM consultant or any other module responsibilities in account determination?
    Becas SAP has more business scenario , each will have account determination ??
    So how ..
    Thanks

    Both FI and MM can do the account determination. FI does the account determination through OMWB and MM does it through OBYC.
    Automatic Account Determination
    This is perhaps the part that causes the most heartache for the FI Configurer.   For some reason, although it is an integration area, the FI team always ends up with responsibility for it.  To do a good job you need a reasonable understanding of :
    the business processes in the source modules
    the FI account postings that they should be generating (what sort of account should be debited or credited etc)
    the organisation structure and its relationships between the source modules
    the reporting requirements that are expected from the General Ledger or Profit Centre Accounting
    your chart of accounts
    Sounds daunting doesn't it ?  Here is a suggested approach ...
    The IMG section under GL / business transactions / integration will take you through all the necessary account determination for the automatic postings that the system may need to post.  You may not need all of these.You could maintain on an as needed basis.  As the project teams test or prototype their expanding functionality, the SAP system will look for the accounts to which it should post.  The error message and the SAP documentation and configuration does not always explain clearly which piece of account determination is used for which type of functionality, so it is sometimes difficult to be pro-active. 
    Being reactive has the benefit that hopefully each side (eg: MM and FI) can develop an understanding of what the business transaction is and therefore where it should be posting. Otherwise the MM person may not even be aware that he has generated a certain type of posting ! (You'd be amazed at some of the lack of ownership from a logistics consultant for the financial postings that they generate).
    I will be explaining each account determination area simply and clearly with posting examples
    SD to FI Account Determination (aka revenue account determination).  This and MM seem to confuse people the most.
    More later - This may take a while to complete........
    In the meantime, some general warnings:
    Whenever you change the field status settings for an account, ensure that you have verified that any automatic postings will be able to meet the requirements. EG: do not make business area mandatory if your system may make a posting which cannot determine and post the business area.
    Consider specifying that accounts that are posted to automatically can only be posted to automatically.  This will simplify reconciliation between the source module and the GL account should you need to do this.
    SD-FI Account Determination and Postings
    This is known in the IMG as "revenue account determination", but it covers a lot more than that (discounts, taxes etc).  This is what determines how the financial impact of your SD Billing document is posted into the FI General Ledger.
    The integration is controlled both in SD and in FI.
    In SD there is a awesome area of configuration called the pricing procedures.   The pricing procedure determines the final price quoted to the customer for a particular product.  This could be a complicated calculation taking into account the base price, any special prices or discounts that may apply to that scenario, taxes, freight charges etc.  These prices or charges are called 'condition types'.  This condition technique is used in a number of areas of SAP.
    For now all we need to know is that each condition type is assigned to an account key (or in the case of rebates two account keys).  You can assign multiple condition types to the same account key. There are a number of account keys that are pre-defined in the system. For example:
    ERF freight revenues
    ERL revenues
    ERS sales deductions
    EVV cash settlement
    MWS sales tax
    Now we start getting to the integration by mapping the account keys to GL accounts.  But it is not as simple as that. It can be as flexible (ie: as complex) as you want. Start off with the most simple approach.  Generally if one is using a good sales / revenue reporting tool (eg: CO-PA) then one does not need a lot of flexibility and variety in the GL accounts that are posted to.  The level of detail that you need in GL should be determined by your financial statement reporting requirements - you may end up with only one Revenue account - it is a good bet!
    So, taking the simple approach we would ignore most of the configuration possibilities : procedures, access sequences, condition tables etc  (Yes it is that 'condition technique' kicking in again.  Once you have worked through it once in one area and encounter it in another then hopefully you will be comfortable in knowing that most of the standard configuration can be left as is. )  
    We have to decide which access sequences we want to use (Five access sequences are defined in the standard SAP R/3 System). To keep it simple, let us assume we just use one - for example: the access sequence "chart of accounts/sales org./account keys".
    The chart of accounts part is standard in all account determinations, so let us look at the rest.  This access sequence allows us to specify different GL accounts for different Sales Organisations. 
    So if we had a billing document line item where the customer had some special deductions for one of the products he purchased, we could map accounts by Sales Organisation.  To make it even simpler a document is within one Sales Organisation so we have an overall mapping as follows:
    SD Line Item  Condition type SD Amount Account Key Sales Organisation GL Account
    1  Sales deduction for being such a nice guy $10 ERS 1000 800010 - Sales deductions for 1000
    Sales deduction for special promotion on particular product $15 ERS
    Base Revenue $200 ERL 800000 - Revenue for Sales Org 1000
      Total for item 1 $175  
    2 Base Revenue $100 ERL 1000 800000 - Revenue for Sales Org 1000
      Total for item 2 $ 100  
    Document Total $ 275  
    So the invoice that the customer gets (and that you can view in SD) will look something like:
    Item (Note this is the SD Invoice line item) Amount
    Item 1:  $175
    Item 2:  $100
    Total owing , 30 days terms etc:  $275
    The GL document posting that the system will make to FI will look something like this though:
    FI Line Item  Debit / Credit  Account Amount
    1 Debit (PK=01) Customer (AR Account) $ 275
    2 Credit (PK=50) Revenue (GL Account) -$ 300
    3 Debit (PK=40) Sales Deduction (GL Account) $25
    Balancing to 0 as all GL documents must....
    $0
    Note : There is no direct relation between an SD Line item and an FI Line Item - they are different things.
    Other considerations:
    Remember that if you are using business areas, then depending on your configuration there, the system may create additional FI line items if it needs to post to different business areas.  This may be even more of a reason why you do not need additional GL accounts.  If your Sales Organisations already map to different business areas, you could use the GL accounts for all Sales Organisations.
    Different access sequences will allow a broader variety of GL accounts (for example: by customer account) group. I strongly suggest having a good understanding of the reporting requirements expected to be supported from the General Ledger vs the SIS (Sales Information System)  or CO-PA (Profitability Analysis) or (CO-PCA) Profit Centre modules before you create too many GL accounts.  At the risk of repeating myself, the SD to FI account determination should only be as detailed as your statutory reporting requirements.   The reporting from other tools like Profitability Analysis are so much more flexible and powerful, you may never look at the General Ledger for internal profit reporting again except to do a reconciliation check.

  • Rebate Error- Sales Volume not current for  agreement.

    Hi
    I am doing Rebates. "The error I am getting is Sales Volume for the agreement (xx) is not current". In the rebate agreement, condition - payment data - the accruals, rebates are not getting updated. It shows zeros.
    I checked accounting documents: The accruals GLS are updated with the rebate amount. Other rebate GL account is not getting posted.
    Any suggestions on how to fix the problem ?

    Dear Sunil A
    You have got this error means some steps are there to be fallowed first please tell me what you have checked by the by please check this link also
    Problem with Rebate Agreement Sales Volume

  • Purchase Rebate Error

    Hi,
    While executing the Purchase Rebate scenario, in Transaction code MEB4 for posting the interim Rebate to Accounts I am getting an error "Tax code is not defined;check your entry".
    Please advise.
    Thanks
    Christine

    GO to SPRO-MM-Purchasing-Subsequent (End-of-Period Rebate) Settlement-Control of the "Subsequent Settlement" Process - Vendor Billing Document: Document Types
    Select the following billing type
    BM10     Fin.Set.Rebate,Plant
    BM11     Fin.Set.Rebate, POrg
    BM30     Part.Set.Rebate,Plnt
    BM31     Part.Set.Rebate,POrg
    double click on it and at the ente of the screen you will see control 2
    here you need to enter the tax code

  • Balance sheet account

    Dear Guru's
    Could anyone explain how the balance sheet account is set to the customers in SD. I was setting up the revenue accounts in VKOA and then I wondered how to assigned the balance sheet accounts. Some details much appreciated.. thanks
    Regards,
    Jin

    hello, friend.
    actually, the G/L accounts are given to SD by FI.  FI configures these accounts.  we coordinate with FI with the following account requirements:
    1.  revenue
    2.  discounts (customer, material, customer/material, etc.)
    3.  surcharges (e.g. freight, pallet, etc.)
    4.  other sales deductions and returns
    5.  rebate accrual accounts
    6.  other settlement accounts
    7.  other reconciliation accounts
    we assign these in VKOA.  but sometimes, special situations require other assignments (such as recon accounts assignments in billing types).
    we also coordinate with FI on account group assignments.  for example, you may want revenues from domestic customers posted to account 100101, and international customers to 100102.  we do this by defining account assignment groups which are used in VKOA.
    hope this helped you.
    regards.

  • Export Under Rebate Pricing Procedure Configuration

    Hi SD professionals,
    My Client have practice of export under rebate  in which they used to export the goods by utilizing balances available in RG23A/RG23C.
    They charge excise with regular excise rates &  but this duties are not charged to the customer & charged to rebate receivable account/excise expenses.
    FI requirement is accounting entry required is:
    Customer account.....Dr. Rs.100
    Rebate receivable .....Dr. Rs.10.3
    Sales Cr. ...........            Cr. Rs.100
    Excise Paid/Payable.... Cr. Rs.10.3
    Customer account.....Dr. Rs.100
    Excise Not Availed Expenses .....Dr. Rs.10.3(Expense Account)
    Sales Cr. ...........            Cr. Rs.100
    Excise Paid/Payable.... Cr. Rs.10.3
    The above entries are for billing document & excise invoice would be as per regular practice.
    How can we configure this in pricing procedure for export under rebate?
    I had tried through statistical condition type but not serving any purpose.
    Please suggest config or workarounds.
    Regards,
    Balaji Parsewar

    Hi Kishan,
    For Exports under rebate you do not create a bond since excise will have to be paid and then claimed back. You will have to generate an ARE-1 document, complete the formalities and then claim the refund.
    As regards to your query on the pricing procedure, for exports under rebate, the excise and cess should not be statistical in nature, since they need to be paid.
    prasanna

  • Rebate take on balances to be cleared

    When the client went live with SAP, they uploaded the legacy rebate balances. These balances now need to be cleared. What is the correct process to do this?

    One option is to do a manual FI journal to reverse the rebate accrual and create a credit memo to post to A/R and Rebate Deduction account.
    Hope this helps.
    Regards

  • Sd/FI integration Please experts

    Hi Friends
    question related to SD- FI integration.
    From SD what is 1) integration with Accouting 2)Revenue recognation
    From sales SD two are different things, but from FI point of view lot more.
    Very hard to understand from SD , Please any one from FI can guide us ?
    Any documentation or functional explonation will help us.
    Please help experts.
    Thanks
    Kris

    Kris,
    In SD there is a awesome area of configuration called the pricing procedures.   The pricing procedure determines the final price quoted to the customer for a particular product.  This could be a complicated calculation taking into account the base price, any special prices or discounts that may apply to that scenario, taxes, freight charges etc.  These prices or charges are called 'condition types'.  This condition technique is used in a number of areas of SAP.
    For now all we need to know is that each condition type is assigned to an account key (or in the case of rebates two account keys).  You can assign multiple condition types to the same account key. There are a number of account keys that are pre-defined in the system. For example:
    ERF freight revenues
    ERL revenues
    ERS sales deductions
    EVV cash settlement
    MWS sales tax
    Now we start getting to the integration by mapping the account keys to GL accounts.  But it is not as simple as that. It can be as flexible (ie: as complex) as you want. Start off with the most simple approach.  Generally if one is using a good sales / revenue reporting tool (eg: CO-PA) then one does not need a lot of flexibility and variety in the GL accounts that are posted to.  The level of detail that you need in GL should be determined by your financial statement reporting requirements - you may end up with only one Revenue account - it is a good bet!
    Hope this helps you. Let me know if you need aything else.
    Rgds
    Manish

Maybe you are looking for

  • Error while entering the Fiscal Year/Period Variable

    I keep getting the following error message when I try to input or select the Variable on the report that has been executed on the Portal. Everything is fine when done through Bex. <b> Please enter value in permitted format for variable Fiscal Year/Pe

  • MouseEvents on JPopupMenu and JMenuItem

    Hi I am trying to get the mouse events from JPopupMenu and JMenuItem , but nothing happens I display the popup once a button is pressed , the popup is displayed but once I click it there is no response can some one help I am attaching the code import

  • GP - CAF : How to capture data from impersonalized form.

    Hi All,           I have a requirement where in I have submit the data offline using an Adobe form and this data should be fed to an RFC any no if times. I have created a interactive callable object (Impersonalized form) using a form template. I'm ab

  • Oracle Redhat 64 bit install does not find right video chip or drivers

    Dear Experts, There is a nice server that I want to install Redhat 5, update 5 on. I downloaded, from Oracle edelivery, the Linux 64 bit, Redhat 5, Update 5, and wrote it to bootable CD. "V20658-01.zip","611558646","0C35737CD35BC26C212D205DF064CE2A",

  • FRAMES in JSP

    How can i put my detail-records in a frame so the user can scroll through details whilst the master is shown above.