Showing results for 
Search instead for 
Did you mean: 

SAP B1 / AP Invoices received from a vendor business partner code different than Goods Receipts'

0 Kudos

Hello experts,

at my company (electronics industry) we use SAP B1 with Italian localization and we have this situation where we place orders to the usual vendor as set in the Item Master Data of the different part numbers, we receive the order through Goods Receipts PO on the same vendor code as the PO, but we receive the invoice from vendors with a different BP code than the PO and the GRPO. This situation typically occurs when we place the order to  electronic component distributors that have multiple branches and controlled companies throughout Europe, or even outside Europe, each iderntified by its specific European Tax ID ("partita IVA"). The Purchasing team and even the vendor itself don't know for sure what country and company the components will be shipped from, so they are not able to use the correct BP code in the PO from the start. The Receiving team in the warehouse receive the shipping against the PO, but A/P team can't post the invoice using the same BP code as the PO and the GRPO, because they have to use the BP code of that Tax ID that has raised the invoice. In SAP B1 they cannot copy the invoice on the correct BP code using the "Copy from" function because SAP shows only the GRPO with the same BP code as in the invoice. If they use the function "Copy in" from the GRPO to the AP invoice and then they change the BP code in the AP invoice window, the relation between the GRPO and the invoice is lost and the GRPO remains open and unmatched to the invoice.

Using the Consolidation BP code is not an option because it allows to consolidate the GRPO from multiple vendor codes to one single consolidation vendor code (many-to-one relation), instead we have the opposite case where we have one consigning vendor code but receive invoices from multiple different vendor codes (one-to-many relation) depending on what country the distributor has the components available and where they decide to ship from.

We either cannot book the invoice under the same BP as the GRPO and then move the balance to the correct BP with a journal entry because this way all our tax declarations (i.e. Intrastat, and others) involving GRPO and AP invoices data (part numbers information such as prices in euro, weights, BP tax ID of the vendor of the parts etc) will not come out correctly.

We face the exact same problem for example with Amazon, we place the order to Amazon but we don't know what country they will ship and raise the invoice from and with which tax ID.

Typically the AP team asks for reversing the GRPO and redo it with the correct BP code, but this is not always possible, plus it's an unacceptable waste of time as we have GRPO and invoices with hundreds of lines and it takes forever.

Ideally we'd like to be able to book the AP invoice under the correct BP vendor code by using the Copy From function and copy it from a GRPO with a different BP code that cannot be set as a Consolidation vendor in the Business Partner Master Data (for the reasons above).

Any idea? Does anyone else face this same problem and how do you handle it in your company?


View Entire Topic
0 Kudos

I agree that payment consolidation is the best way to support this, but what you need is limited to newer versions. In the last few patches, you don't need to define a fixed consolidating BP on BP master data, you can simply choose one on the document directly if needed.

When creating AP Invoice, you select consolidating BP and the posting will be done on this BP account. The only potential downside is that standard system reports usually show the original document vendor instead of consolidating vendor (for example purchase analysis or tax register book), so you might need to do some custom magic with reporting tools.

0 Kudos
If you did delivery consolidation on the GRPO and then Copy From on the AP Invoice it will show the document fully as the target vendor even if the GRPO is the original vendor.