Issue in Rebate Settlement

[Former Member]

Do all materials for settlement should belong to same sales org and dist channel? If 5 materials and one is maintained in different sales org and dist channel, would that cause any error? Thanks for your support.

Message was edited by: G Lakshmipathi

Please use the subject effectively

[former_member131691]

Hi

The standard partner determination for rebate settlements are as follows :   

SP  Sold-to Party   Determined from Rebate Agreement = Rebate Recipient

BP  Bill-to Party   Determined from customer master SP Sold-to-party    

PY  Payer           Determined from Rebate Agreement = Rebate Recipient

SH  Ship-to Party   Determined from customer master SP Sold-to-party    

In addition, please review note number 75778 point 2C as follows:       

In all rebate credit memos created for a rebate agreement. the         

rebate recipient is used as the sold-to party, as the payer as         

well as as the ship-to party. The system behavior in respect of        

these three partner functions is predefined and cannot be              

influenced further. For example, the system does not perform any       

determination of an alternative payer from the customer master         

record of the sold-to party. You have to take this behavior into account

when you maintain the rebate recipient.

Hope this helps further

Kind regards

Brian

[Former Member]

Thanks Brian.

My ship to party has different customer number in partner function tab customer master. But error is "SH  15000 not maintained in sales area" when settling rebate.

CUSOMER MASTER (Partner function tab)

SP                               15000

Rebate recipient(PY)   15000

SH                                15100 

Please help.

[former_member131691]

Hi

What is the exact technical error message you are receiving from VBo2 ?

I guess it is VP210 ?  The system is reading the KNVV table with the sales are of the document

and if there is no entry there for any of the partners you will get this message.

You can validate this when creating the final settlement document check in the debugger

in function module KNVV_SINGLE_READ.

The rebate recipient is defined as: sold-to party = the payer = ship-to party

This is hard coded in function SD_BONUS_CREDIT_NOTE_CREATE

..

* Partner

  CLEAR FXVBPAKOM.

  FXVBPAKOM-PARVW = 'AG'.

  FXVBPAKOM-KUNNR = KONA-BONEM.

  APPEND FXVBPAKOM.

  CLEAR FXVBPAKOM.

  FXVBPAKOM-PARVW = 'RG'.

  FXVBPAKOM-KUNNR = KONA-BONEM.

  APPEND FXVBPAKOM.

  FXVBPAKOM-PARVW = 'WE'.

  FXVBPAKOM-KUNNR = KONA-BONEM.    >>>>

The rebate agreement is created and valid for a specific sales area Sales org, distribution channel and division, the settlement materials you have defined in the agreement have to maintained in that sales area as well as the partners. In the sales document header there is only one field for the

sales area, it is filled form the agreement master data (KONA) and from the items when the credit memo request is being created. There can only be one sales area so it wouldn't make sense to have settlement materials in the same agreement with different sales areas either.

You have to fully maintain your master data to avoid such errors

I hope this helps you further

Kind regards

Brina

[Former Member]

Thanks Brian for taking the time to answer. Yes error message is VP210.

Not sure from where system picks up sales area for SH. " SH not maintained in 0001/02/01"

SP=PY (Rebate recipient) 0001/02/03.

Rebate maintained in 0001/02/03.

Material for settlement maintained in 0001/02.

Thanks in advance.

[former_member131691]

seems from the message as though you need to maintain ship to party '15000' (coming from KONA-BONEM) into the sales area that the agreeemnt is created in (See KONA-VKORG, VTWEG, SPART)

to avoid the error. I do not know where the sales area 0001/02/01 would be coming from but nonetheless if it is valid you will need an antry in KNVV to avoid the error. If it is not expected you

will have to debug the generation of the credit memo from VBo2

You can check from here and work back to the origin of the unexpected division entry:

FUNCTION 'SD_SALES_HEADER_MAINTAIN'

...

PERFORM XVBPA_PRUEFEN(SAPMV45A) USING POSNR_LOW.

--> function KNVV_SINGLE_READ

Hope it helps

Kind regards

Brian