Posting of cancelled Invoice after posting date is over

[Former Member]

Hello Experts,

I am stuck up with a situation and as such seek your help.

A invoice was generated and the subsequent accounting document was also cleared. Now after the posting date was over, someone cancelled the invoice by T.code VF11 and as expected it didnt get posted .The document flow showing is as per below :

Order - open

Invoice - completed

Accounting Document - Cleared

Cancel Invoice - Open

Now, the business and their audit policies do not allow the client to cancel the invoice in back date ( within the posting period).

What are the options do we have to tackle the situation.

Joy

[Former Member · Accepted solution]

Dear,

I think it is not an issue for audit. because if you delete or cancel invoice in back date then the value of invoice is credit in account of customer in this date. You just explain the audit person that this is the standard of SAP. If posting period is open then SAP will allow to cancel invoice in back date.

If you want to restriction on that then develop that type of config in your system. so, next time it is not happen.

Regards,

Sandip

[Former Member · Accepted solution]

Dear Sandip,

Modification of the cancell invoice date to back date is not possible because the client also have a legacy system which runs simultaneously and hence not allowed.

[Former Member]

Hi Joy

Can you change the cancelled invoice date to the current month date?

The finance people must have finished reporting the prior month and therefore they can't have the figures change after the month is completed. Their reporting would be a problem if you did post it to the prior month

Kind regards

Dawn

[Former Member]

The issue has been temporarily addressed by changing the posting date.

However, now the client wants us to make an ABAP development so that no user is able to cancel the invoice after posting date is over. Now for that I have the following issues. Can someone please help me out in this.

The basic process details I am following is as per below:

For Transaction Code VF11 (i.e for Cancellation of Invoice) , when the invoice number which is subject to cancellation is provided, the System should search in VBRK table for the following :-

1)The System will at first search whether the entry exists or not. If the Entry is not valid then it should give an message u201C Document xxxxx does not Existu201D.This is in line to the existing practice.

2) If the Document number is valid then it will go to the billing date field and will fetch the value from the VBRK table . Then it will match whether the value fetched (i.e. this Invoice date) is in present posting period or not. The system can find the posting period from the table V_T001B.

a.If the Invoice date lies in the present posting period then the system will allow the cancellation document to be saved. This is in line to the existing process.

b.If the Invoice date lies beyond the present posting period then the system will not allow to save the cancellation of the Invoice with a pop up message of u201C The Document number subject to cancellation do not lie within the present posting periodu201D .

Now We have looked both the tables, from VBRK we will get Doc# and Billing date(FKDAT) but when we select Posting Date from table T001B( Permitted Posting Periods) there is some issue.

1. What will be the condition for selecting records from T001B table.Since there is multiple key fields

RRCTY (Record Type) ,

BUKRS (Posting Period Variant) ,

MKOAR (Account Type or Masking)

BKONT (To Account).

So, to get unique record what will be the value of this key fields. Is there any relationship with VBRK table ?

2. Which field I have to consider as Posting Date or Period. Because there are many fields related to Posting period.

[Former Member]

Hi Joy

I am not that technical, but would it not be a good practice not to cancel even if the document is in the open period? Another alternative would be to limit the cancelation to a super user who knows the rule of open period. You can then remove transaction VK11 out of the users' authorization profiles.

Hope this helps

Kind regards

Dawn