VF04, problem during massive processing

[Former Member]

Hi all,

we have a problem running transaction VF04 in massive mode, some times the invoices are registered without respecting the sequence of deliveries processed, so the date into the invoices created are wrong and not correctly sorted.

I guess the problem is generated by the processing mode of VF04, synchronous or asynchronous, we are running transaction in asynchronous mode, is it possible? Or have I looking for any old user-exit?

Thanks GN.

[former_member131691]

Hi GN

When you run VF04 the system calls function module SD_COLLECTIVE_RUN_EXECUTE and in
here the billing is carried out in blocks of 1000 (can be changed)

SD_COLLECTIVE_RUN_EXECUTE
…
  SORT V60P_INPUT_VKDFIF BY KUNNR VKORG V_FKART V_FKDAT SORTKRI
                            FKDAT FKART VBELN.
  CALL CUSTOMER-FUNCTION '010'
       TABLES
            CT_VKDFIF = V60P_INPUT_VKDFIF

…
  LOOP AT V60P_INPUT_VKDFIF WHERE SELKZ NE SPACE.
    ON CHANGE OF V60P_INPUT_VKDFIF-KUNNR OR
                 V60P_INPUT_VKDFIF-VKORG OR
                 V60P_INPUT_VKDFIF-V_FKART.
      IF COUNTER > 0.
        CLEAR SY-CALLD.
        DELETE ADJACENT DUPLICATES FROM XKOMFK.
        PERFORM RV_INVOICE_CREATE

You see the sorting criteria in standard, if you wanted a different sorting of the internal V60P_INPUT_VKDFIF table you can use user exit EXIT_SAPLV60P_010

I hope this helps you further 
Kind regards
Brian

[Former Member]

Hi Brian,

thanks for your answer, my problem isn't sort criteria, in VF04 the sort is right, the problem is after processing, the invoices created some times are created without respect the same order shown into the VF04.

[former_member131691]

Hi GN

I am not 100% sure what you mean exactly maybe you could explain the exact details in an example.
Anyway there are some points to consider, if you use number range buffering the sequential number assignment can never be guaranteed because of the way the numbers are issued from the buffer.

As far as the assignment of the FI documents perhaps you can overcome this issue by splitting the creation of the invoice in VF04 from the creation of the accounting document. If you set a posting block on the affected billing types in VOFA, VF04 will only create the billing document in that step. You can then schedule RVFAKSPE to run afterwards to release the billing documents to accounting, probably when the billing document numbers are committed already to the database the issue of sequence will be resolved ?

I hope it helps
Kind regards
Brian 

[Former Member]

Brian as you can see in the above example, wrong result of VF04 processing is:

00000001     21.07.2014

00000002     27.07.2014

00000003     19.07.2014

what  would like have is:

00000001     19.07.2014

00000002     21.07.2014

00000003     27.07.2014

just like shown previously by VF04 before process documents.

Normally this is the result but some times the result is the first one of this post, any idea?

[Former Member]

I'll try to add some more details, what customer want is that FI document, posted according to the ones created in SD, have the same date of SD invoice, so, as in SD invoices we have dates not correctly sorted, as described in previous post, in FI we have invoices sorted wrongly and this cause an error. Usually I know in FI the invoices are posted using an unique date, so I think that are no problem if VF04 is processed in asynchronous or synchronous mode, in our scenario I guess the asynchronous mode is wrong, what do you think about my assumption?

Thanks GN.

[Lakshmipathi]

Can you explain with an example how system is behaving currently and how you want?

G. Lakshmipathi

[Former Member]

Running VF04 system extract document correctly sorted by date:

19.07.2014

21.07.2014

27.07.2014

I process through "Collective billing document" function and it create following documents:

00000001     21.07.2014

00000002     27.07.2014

00000003     19.07.2014

Note that the error is random, normally the system creates invoices sorted by date, sometimes it happen that the date sort is not respected...