on 04-22-2011 7:18 AM
Dear Gurus,
1. Required clarification in b/w Accural and Amount coming in the condition record of the rebate. Appreciate if explain with example.
2. If I create rebate agreement (Customer / Material) and settle with the credit memo, again if create a second agreement with the same customer and material and after porting invoice go for display of rebate agreement its also show the rebate basis value of last agreement.
Kindly advise.
Regards,
Please select rebate condition type which has calculation type as 'B' - fixed amount.
SPRO path: IMG>SD>Billing>Rebate processing>Condition technique for rebate processing>Define condition types
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Imran,
Please check consulting note 456247. This note explains why the system stores accrual conditions with calculation type 'A' - percentage in customer billing documents although the condition type actually has calculation type 'B' - fixed amount. During the payment, however, the calculation type is as specified in the condition record.
Cause and prerequisites
This is the standard system response.
1. Example:
There is a rebate agreement with calculation type fixed amount on
150 EUR. No matter how many invoices are relevant for this rebate
agreement and which sales volume they represent, the system will
ALWAYS pay 150 EUR at the end (fixed amount). Thus it does not make
sense to defer 150 EUR or a different fixed amount for each invoice
since the payment neither depends on the amount of the invoice nor
on the number of invoices. Instead, it may be useful to create no
automatic accruals at all (accruals value 0.00 in the condition
record) and simply to defer the payment amount manually.
However, if you still want to post accruals although the payment is
independent of the amount and the number of invoices, percentage
accruals seem to be the only sensible variant since these guarantee
at least a certain independence of the number of invoices to which
the sales volume is distributed. If, for example, the rebate
recipient has an expected sales volume of 1500 EUR and should
receive a fixed amount rebate of 150 EUR and if you deferred a fixed
amount of, for example, 50 EUR, you would receive an accural of 150
EUR after three invoices. If, however, the sales volume is
distributed to 10 invoices, 500 EUR would be deferred and if the
sales volume only comes from one invoice, only 50 EUR would be
deferred. Thus a fixed amount accrual does not seem practicable.
However, a percentage accrual is still sensible here as long as the
sales volume is within the expected range. Then it does not matter
with how many invoices the sales volume of 1500 EUR is achieved,
with 1 % accruals, the total of the accruals is always 150 EUR.
Thus for conditions with calculation type 'B' - fixed amount, the
accruals amount is always stored as a percentage. A change of the
system response is not possible without a modification of the
Page 2
standard system.
2. A rebate agreement INdependent of sales volume exists. (The 'Rebate
procedure' flag is set to 'A' in Customizing of the condition type.)
A special feature of this agreement type is that no automatic
accruals are posted in general. In spite of this, the condition is
stored (with the amount zero) to ensure the statistics update. Here
the calculation type has no meaning and is also stored as in a
'normal' agreement.
I hope this information helps.
Kind regards,
Kelly
Amount is nothing but the rate at which we provide rebate to customers. It could be either an absolute value or % which satisfies the key combination of the rebate condn record
System needs to know the amount to be accrued with respect to the rebate agreement if we provide an absolute amount (instead of %) in amount. That will be mentioned in accrual.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Waiting for the gurus reference...
Regards
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
108 | |
12 | |
11 | |
6 | |
5 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.