cancel
Showing results for 
Search instead for 
Did you mean: 

Cash Discount (SKTO) Not Calculating for Sales SA

Former Member
0 Kudos

Hello There,

I have two Invoices and both for same customer/payer, same material and same pricing procedure

Invoice1: Sales Scheduling agreement -> Delivery(ZL2) -> Invoice (ZF2)

Invoice2: Standard Order -> Delivery(ZL2) -> Invoice (ZF2)

Also in the accounting document both Invoices are posting to  the same profit center.

The problem is for Invoice2 cash discount is being calculated whereas, for Invoice1 it is not calculating the cash discount (SKTO). I can see that for Invoice1, there is 'volume rebate group' set and for Invoice2 there is no volume rebate group and cash discount is set.

Could you please guide or suggest what could be the reason? Is there any user exit for this, which checks the order type(C or E) and based on that cash discout or rebate will be given to the customer?

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Thanks everyone for the response. The problem is solved now.

Analysing too deep some times leads to ignore small things which maters most.

The SA was created in 2012 and Invoice is from 2015. When I checked all the change log from 2012, I found in 2014 the Cash discount flag was set from BLANK to 'X'. As the pricing procedure ( with cash discount ) is copied from SA all the time for subsequent documents, it is always copying the same old data and the later on changes in MM are not reflected in the new invoices.

Regards,

Answers (3)

Answers (3)

sez41
Active Contributor
0 Kudos

Hi

What is the value of VBAP-SKTOF in the reference sales document of billing document in which VBRP-SKTOF is blank?

Is it possible if someone changes the value of VBAP-SKTOF directly from database table via SE16/SE16N? Did you check log tables SE16N_CD_DATA & SE16N_CD_KEY and analyze this?

Former Member
0 Kudos

Hello,

Thanks for your reply.

VBAP-SKTOF is also blank. There is no change log found with se16n_cd_data analysis as well.

Regards,

Shiva_Ram
Active Contributor
0 Kudos

SKTO works based on the payment terms discount set up. Are you using same payment terms for both the scenarios? Also are the materials used on these scenario's same? From the picture you have posted, cash discount in one is checked and for other it is not checked. Hence can you check the material master ->sales view for cash discount field box checked or not?

Regards,

Former Member
0 Kudos

Hello Shiva,

Yes, I have checked all these and nothing are conflicting. And to note, I know that requirement 009 for condition type SKTO checks, whether the check box is ticked or not and therefore determines the Cash discount but here in this case the question is when all the conditions for Cash Discount are same in both the Invoices, why the cash discount check box is not checked? Cash discount for the materiel is checked there is no change. Also there are no changes in Invoice at all.

Thanks for the reply.

Shiva_Ram
Active Contributor
0 Kudos

What is the pricing analysis shows for SKTO?

Regards,

Former Member
0 Kudos


Pricing analysis says "Condition ignored (requirement 009 not fulfilled)".

Requirment 009 checks KOMP-SKTOF (Cash discount indicator and we are trying to find out why it is not checked when all the master data and other factors are identical) and t001-xmwsn (not required as both have same company code)

Thanks,

jignesh_mehta3
Active Contributor
0 Kudos

Hello Aniruddha,

We can see that Cash Discount is indicated in Invoice with Pricing date as 19.11.2015 and not in Invoice with pricing date as 23.11.2015.

Have to checked in Material Master record change logs if someone has modified the Cash Discount indicator (Sales: Sales org 1 screen) between 19.11.2015 and 23.11.2015?

Thanks,

Jignesh Mehta

Former Member
0 Kudos

Hello Jignesh,

Yes, I already checked this. There is no change in material master. And this has not happened just for one Invoice, there are many examples in Production where for SA, SKTO is not calculated where as for Standard Order it has been.

Thanks for the reply.