cancel
Showing results for 
Search instead for 
Did you mean: 

probable effects of removing Sold-to from invoice header?

Former Member
0 Kudos

hi

we have a requirement of doing collective billing by Payer and for that we need to remove Sold-to partner details from invoice header to avoid billing split.

We are achieving this by using copy control routine to suppress Sold-to from delivery and (ii) removing Sold-to from header partner procedure of billing type to avoid prevent split due to different Sold-to in preceding documents. (and maintain Sold-to at invoice item level)

Removing Sold-to from header partner procedure was required as otherwise the split indicator UNGLEICH=X was set and we could not find any user exit to set UNGLEICH = space in program LV60AB14 ( SAP ver 4.7 ).

While we are trying to assess the effects of removing Sold-to from invoice header, I would lile to know opinion of others about probable effects of doing such; if anybody has done same thing in past, please help.

thanks in advance

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

I worry about the pricing procedure, normally system will take the price from Sold-to party when doing billing, if you had removed the Sold-to party in the header, maybe system would issue the error message for price missing, unless you had maintained the price under the Bill-to party or Payer.

That's my concern. Suggest you not to do that!

Good day

Tao

Answers (4)

Answers (4)

Jelena
Active Contributor
0 Kudos

I personally think it's a dangerous idea. Sold-to party is one of the SD "staples" and removing it from the billing document seems rather extreme.

Most of the time the issue is just being approached from a wrong end. What is it that you're trying to do exactly? Sometimes a much easier solution, such as an invoice list or a custom output processing program, would do, no need to break the standard.

For example, once we had to provide a collective invoice to a large store chain for all the deliveries to the stores within certain period of time. At the same time, the stores also wanted their own invoices at the time of delivery. At the end I just wrote an ABAP report, which printed a Smart Form combining all the store invoices into one "chain invoice" with a made-up number. It complicated things a bit in payment processing for Accounting, but they agreed to this solution.

Or maybe you need to review your partner determination strategy - use Ship-to as Sold-to and Sold-to = Payer, if possible.

Former Member
0 Kudos

Hi

we had the following constraints:

1) due to legal issues (Italy) which states that AR posting should match invoice printout we could not go for Invoice Lists. Designing a different form is ruled out for same reason.

2) customers are used to getting single invoice per payer per month in present legacy system and hence from business point of view, multiple invoices are not acceptable.

Jelena
Active Contributor
0 Kudos

Are there any legal requirements that prevent you from having the single customers (which gets deliveries) as Ship-to and the payer (which pays the invoice) as Sold-to (Payer being the same customer #)?

From the previous posts it does not seem that you have a 3-tier hierarchy, where ship-to, sold-to and payer should all be different... So what's the problem? You'll get a delivery document for each single customer and then run billing once a month and you'll get a single invoice.

Also, since this seems to be specific to Italy, you might want to check the local Italy SAP boards (most likely you'd need some Italian-speaking person for that). Usually local consultants have better knowledge of local law and peculiarities. Your company is most likely not the only one facing the same challenges.

Former Member
0 Kudos

Hello Kustavas,

In my opinion, if you decide to delete the sold-to-party at the invoice header (that would be set the field VBRK-KUNAG to void), that is more or less a system modification and therefore worrying.

Even if it works NOW, there is no garrantee that it will work in the future and SAP will say that you are out of standard support because of this "modification".

I have had that case at two customer sites and it was solved "playing" with the customer partner function at the master data level.

Example: Instead of defining a "customer" as a sold-to-party, it was defined as a ship-to-party; the customer group was defined as the sold-to-party.

This way it was possible to group several deliveries of different "customers" (ship-to-party) in a unique invoice. Using a formula for data transfer, it was possible to split the invoice depending on the sold-to-party requirement (example on invoice / delivery or one invoice grouped for all deliveries, etc.)

Best Regards,

Franck

Former Member
0 Kudos

thanks for the suggestion.

Unfortunately we are implementating a global template where 85% of global business is already online and we are not in a position to change the customer master set-up.

former_member217082
Active Contributor
0 Kudos

Hi

If you cant change th customer master set up then deleting the sold to party (KUNNR) is highly difficult at billing level.

More over you need to uncheck the sold to party (SP) in partner determination procedure

Regards

Srinath

Former Member
0 Kudos

Hello again Koustav,

I understand you can't change much because you are on a template, nevertheless it is a Business Decision to create a customer as a Ship-to-party instead of a Sold-to-party, so it should not be a problem as the Template should contemplate more or less the same concepts.

If these customers will use EDI in the future, you will need to have one invoice per delivery, so the problem will not happen

In my opinion, it is a much cleaner process to have an invoice per delivery instead for instance of weekly or monthly invoicing. Each invoice is much smaller and if there is a discrepancy, only one invoice payment is delayed, not the full monthly invoice.

Another possibility, as Jelena said, is to send a special invoice list to the customer.

Anything is better than breaking SAP functionality.

Regards,

Franck

Former Member
0 Kudos

hello, friend.

i will still check on this, but my impression is that AR and credit data will be based on sold-to. removing the sold-to may then possibly cause problems in credit management.

regards.

sudhir_khetarpal
Explorer
0 Kudos

Hi

I don't see any problem if you remove sold to party from the header as it would still be available at the item level. You definitely should not have any problem as the role of sold to party is more less in SD, while billing is more related to FI-SD where payer, bill to party are more important.

Sudhir

Former Member
0 Kudos

Pricing may be a concern, but as of now our pricing procedure is working correctly.

what could be the effect on accounting and profitabiliy analysis etc.?

Former Member
0 Kudos

Hi,

  • If the customer number of Sold-to party is the same as payer, then no impact on accounting and profitability analysis;

  • But if different, from my point of view, still no impact on acccounting, but maybe effect on the profitability analysis, because the customer numbers are different between sold-to party and payer, that's mean, you deliver goods to sold-to party, but book the AR amount under the payer account.

Regards

Tao