Incoterms: invoice split

[Former Member]

Hi,

How can I avoid SD invoice split in TCode VF04 due to different values in INCO2 field in sales order or delivery?

I have already replaced the routine 001 by blank in TCode VTFL for copying rules from LF delivery to F2 invoice for TAN item type.

However it seems not to be enough.

I have also looked up SAP Note 11162.

As a result I have a doubt about the feasibility of my requirement.

Just to illustrate: I would like to have a signle F2 invoice for two LF deliveries for the same customer (both ordering and ship-to) for which I have  respectively FH Geneva and FH Lausanne incoterms.

How can I achieve this?

[andrea_brusarestelletti · Accepted solution]

Hello,

  since field "INCO2" is an header field of the invoice document, your purpose can't be achieved (unless you clear the the content of field INCO2 before creating the invoice, but in that case, you would lost that information).

Best regards,

Andrea

[Former Member]

Hi Andrej,

a bit late the reply but ... the solution is simple and standard:

you can achieve it by setting B in copy control Delivery-Invoice (tcode VTFL) entry “DetermExportData” . It will re-determine export data for billing documents, no export data is updated in the deliveries.

Regards,

JM

[akrason]

Hi Joan,

Never too late to do better! (even if not now, then maybe next time...) Thanks!

But just to make sure to get your point : if I put B then my "FH" & "Geneva" in the first sales order/delivery  and "FH" & "Lausanne" in the second sales order/delivery will be unified into one common value?

Which one? The one in customer master where, let's say "FH" & "Destination to be defined", is the current Incoterms?

[Former Member]

Hi Andrzej,

yes, they will be put in a single common value thus avoiding splitting. Which value? When values differ, they're set to blank in billing document (no changes will be produced in deliveries). You can test yourself.

Regards,

JM

[akrason]

Hi Joan,

Thanks again.

So just to summarize this (hot to some extent) discussion between all contributors my conclusion is that I have two ways for avoiding invoice split due to different INCO1 and/or INCO2 fields.

The first one (one that I have actually just put in place) is to customize copying routine with the help of CLEAR command.

The second one is to redetermine export data at billing step by the means of customizing (value B).

Both lead to the same result. Simple, clear and clean.

[akrason]

Hi all contributors,

Thank you so much for your answers.

I notice that the topic is quite touchy given you discussion.

So let me give you my feedback (sorry but I will not award relpy prize).

Clearing INCO2 in copying routine did work fine.

We also needed to consolidate even further our invoices as we have 3 major clients (98% of turnover) with possibly several hundred invoiced items per client and per day.

As a result I have noticed that some constraints for consolidation will come not from invoice creation step but from invoice cancellation.

So far the "do not touch" fields are: distribution channel and origin of sales tax ID number.

When cleared on invoice creation the system prevents from cancelling, if needed, this document. 

[former_member205178]

Hi Andrzej,

I will speak for myself. The idea of Award Reply Prize is not something which excites me . Seen enough of that last two decades.

As long as you understand what you need and work towards it, good for you. In the process, if people like us 'who volunteer' are able to help you arrive at a decent solution that is a plus.

I enjoy helping people and that is the only reason for my presence here.

Good luck with your solution.

I drop off this post.

Thanks.

[former_member182378]

Krason,

Could you please elaborate on

As a result I have noticed that some constraints for consolidation will come not from invoice creation step but from invoice cancellation.

[akrason]

Hi,

Krason is my last name so call me Andrzej if you will.

Your request makes me suspecting that my last sentence:

"When cleared on invoice creation the system prevents from cancelling, if needed, this document.  " is not explicit enough.

So I repeat in less literary style (sorry but I am not English native speaker): You cannot cancel an invoice which is missing distribution channel and origin of sales tax ID number in its header.

[former_member182378]

Andrezej,

Sure! I would do that!

Members are from different parts of the world with different names. Therefore I always address my post with the name which is first (in your case it is Krason)

About my question, it comes from - if user can create a billing document, then that billing document can be cancelled too!

E.g. if there is no distribution channel, then would a billing document be created in the first place?

[Jelena]

Andrea is correct - there are header-level fields that will be used to split the invoice no matter what.

It seems quite logical to separate financial transactions using Incoterms because there would be different cost involved and two documents would need to be generated for two different destinations. Otherwise it seems you're delivering to two different ports yet expect to provide the customer with one invoice. Would the customer even be able to clear customs with such document? Doesn't make much sense to me...

I'd suggest to understand the meaning of the fields before trying to break the system. If the information in the Incoterms fields is actually not relevant to the business then just don't put it there, use a different field.

[akrason]

Thanks Jelena.

You are perfectly right.

But in today's (ERP) world many of us want to do perfectly what cannot be done in as-designed way.

I am in domestic business and our customer's: storage locations, ad hoc constructions sites and usual delivery addresses must be described in INCO2 field.

Thus no worry about invoicing rules. However this allows me to manage the selling price as "cost price + service provided" (depending on INCO2, but not only) rather than "list price - discount".

Therefore I have another question.

Both SAP Notes 11162 and 36832 list the fields which should not cause invoice split.

However it would be much more useful to know which fields (and where from!) DO CAUSE invoice split if no routine is used (or if routine 001 is selected).

Would you know the answer?

[andrea_brusarestelletti]

Hello,

I remember a note saying this, but I can't find the  number, anyway any header field of the Invoice document,  so any field of table VBRK coming from the documents that you are invoicing is a splitting reason, just for the nature itself of an header table: if the value si different in the previous documents,  how can the system determine in the correspondent field of table VBRK which value should be copied?

As far as it's possible,  as suggested by Lee Ai, you can clear the field INCO2.

Best regards,

Andrea

[former_member205178]

Hi,

I understand your situation. My comments here may not directly contribute in any solutioning but could not resist chipping in. It definitely might give you food for thought

By coding around something which is meant for standard purposes, it creates a ripple effect where we have to keep checking again and again check for how we can map the same field in other touch points of the system for example - reporting, pricing, shipping process flow[in this case].

By the way, even though INCO [ INternational COmmercial ] Terms sounds like a feature only for International [read global / export / non domestic ] Usage -  it can be used domestic too.

It just conveys that there are certain commercial business terms which are international in nature with respect to the general usage. These are shipping / transportation related and need not just be Customs related.

The thought that we want to do perfectly what cannot be done in as-designed way, leads to more situations and solutions dancing around the actual problem.

My two cents here are to look at some other field mapping for this purpose. It might be painful but not impossible to do so. But then again, if you are just a soldier implementing a solution around the existing mapping in the past, then this discussion is a moot point and is just that - a discussion .

In today's world while perfect solutioning may mean not following standards, as a corollary - standard process / field usage does not have to mean being uncool, rigid, boring, inflexible and other negative connotations like that. It means not looking a field/process in a silo and having a big picture in mind.

Always a tussle between Functional Thinking, Business Push and Technical Solutioning .

You have a good one.

Thanks.

[Jelena]

Andrea kind of beat me to it, but in general all the fields in VBRK structure that are filled in by the time the VOFM routine is called are used for splitting. I had to debug it long time ago and don't remember the exact location, but it literally fills in VBRK structure for one delivery and then for the second delivery and compares them for equality. If any field is different then new invoice is started. It shouldn't be very difficult to debug again, if necessary (unfortunatelt I don't have time right now myself).

One note - you're saying the Incoterms 2 field "must" be used, but I really doubt it's a "drop dead" situation. Dee Sea's post above was a bit TMTR for me, but brings up a good point (again) - it just does not seem the right field based on your description.

Anyways, this was a good discussion, but maybe it's time to make a decision and close it if your question has been answered. Thank you.

[former_member205178]

Hi Jelena,

TMTR made me wonder what it was ? BTW, I am still learning the internet lingo .

I agree I am too verbose many a times.

You have a good one.

Thanks.

[former_member187652]

haha Dee Sea, UrbanDictionary says: TMTR, TOO MUCH TOO READ

[former_member182378]

Dee, Members, Krason,

My two cents here are to look at some other field mapping for this purpose. It might be painful but not impossible to do so. But then again, if you are just a soldier implementing a solution around the existing mapping in the past, then this discussion is a moot point and is just that - a discussion .

As we know, many a times, clients do not want the "already existing process, fields etc." to be touched. As the risk and expenses seem not worth it for the client.

So, the consultant has to get a feel of how the client would react, when faced with the idea of changing some existing configuration. Especially when the said config touches many important functionalities of the business.

[former_member205178]

Hi TW,

I am visiting this thread just one last time

Your point about client not wanting to touch existing processes, fields, etc. is the most likely issue here.

In theory, if the field INCO2 as a combination with INCO is being used correctly, there should be no requirement of trying to consolidate invoices by merging deliveries with different INCO Terms which cause Invoice Split into one Invoice.

It was in that respect I had made the comment. As far as risks, expenses and priorities are concerned, sometimes it requires courage to accept mistakes, make corrections, travel paths which are not popular than keep living with problems and have lots of challenges. Not everything can be felt directly  monetarily nor in the short term.

From my experience, more often than not Customer Master specific fields get a bad rap during the initial implementations as they are loosely interpreted, mapped and design decisions made.

Afterwards people have to live with that. Down the line, when people are more used to the system and start understanding and appreciating the fields power more, by the time the damage is done.

All of the above being said, we clearly do not have the full requirements and reasoning of the use of INCO2 in it's original form in this particular case, so I would leave it at that. As you know, we are in no position to influence Andrzej or anyone else, as this is just a suggestion and discussion forum.

No more comments on this, as I am not being useful and more of a distraction in this thread. 

Thanks.

[former_member182378]

Dee,

Your posts (in this thread) and else where are a good learning for many members!

So, please don't stop, thinking that your posts are adding no value.

If you want to stop...then by all means (it is an individual's decision, and this is volunteer work)

Thanks!

[former_member187652]

Andrzej,

inco term will cause split due to standard setting. this can be achieved by some development.

talk to your abaper and develop a routine cloning whatever routine you are using as of now, with below modification

in the new routine, right above ENDFORM insert line

CLEAR VBRK_INCO2

[former_member193761]

Please do split analysis and send the screen shot.

[Former Member]

Hello,

     The routine in the field Data VBRK/VBRP (Field ZUKRI) in copy control is what controls the Invoice split/combine logic. Instead of making blank the routine, you can ask your ABAPer to modify the standard routine and remove the INCO term field from splitting criteria.

     Also check the article in the below link, it might be useful to you.

          Invoice split & Consolidation

Regards,

Umesh

Message was edited by: Umesh Ghanekar

[andrea_brusarestelletti]

Hello,

I don't agree: header fields are splitting criteria despite the usage of ZUKRI, where you can define additional splitting criteria and where you can remove the standard fields already defined and moved to ZUKRI.

Best regards,

Andrea

[Former Member]

Thanks Andrea. Noted the content.

[atul_mohanty]

Hi Andrzej -

If you do not have a option, you can have a custom routine (data transfer) to combine invoice based on customer.

VBRK-ZUKRI  to be the customer you are refering.

Regards,

Atul Mohanty

[former_member186385]

Hi,

can you please check the split criteria

Gto VF02--> Input the Billing document and click on ENVIRONMENT--SPLIT CRITERIA

system will prompt to enter other Billing document for which split has happened

please check the split and revert back, i believe there could be something else

regards,

santosh