change the carrier code in invoices

[Former Member]

Good morning, we would need to change the carrier code in invoices recorded, (VBPA-LIFNR -> PARVW = SZ )

someone had the same need?

how did you solve?

Thank you

Fiorenzo

Italy

[Former Member · Accepted solution]

I checked and it's not what I need. (Maybe I did not explain it correctly)

I should change the partner in a bill (already booked) exactly the carrier. through the transaction VF02

but the field is not editable

my question is, can you make it editable?

thank you

[Former Member · Accepted solution]

Fiorenzo i was about to ask the same question and you replied. Thank you for explaining this. The answer is you cannot change the partner function at billing level, have a look what OSS Note 499918 says about this. As per my understanding i think this value is getting copied from your sales document, is it so? If it's true then you can cancel the invoices make the changes at sales document level and then regenerate the invoices but i'm not sure as if why its obligatory for the business to make such change at billing document level and if business is sticking to change it at VF02 level then to control this i believe still there's an option of using an Exit as mentioned in OSS Note 43296. In case of any help on this, please feel free to ask. Thanks.

[Former Member · Accepted solution]

Grazie thank

note 499918

These functions are not provided.

According to the SAP concept, the change options in the billing document should be reduced to the minimum (for example, tax classification -> account determination) and the required changes should be made in the sales order or delivery document the billing document is based on.

note 43296

There is no standard solution for the following customer requests

but it is strange that the exchange rate of the courier invoice is enabled by SAP.

it seems illogical to reverse a bill to change the courier (which has no impact on accounting data) and it can happen that in an invoice needs to be modified at the last moment to change the courier.

thanks for the time dedicated to me

[former_member182378 · Accepted solution]

and it can happen that in an invoice needs to be modified at the last moment to change the courier.

Fiorenzo,

Why your company needs to modify the courier after completion of the billing document (VF02) or during the creation of billing document (VF01)?

Some business scenarios:

1. Some companies have fixed couriers, during order creation, you input that courier company, in the partner section or its automatically picked up from the customer master. This information then flows to the delivery and finally to the billing document.

2. Sometimes courier is changed after order creation. Then user has the option to go into the delivery and change the courier in tab partners. This updated courier will flow from delivery to the billing document.

Here the sales order and delivery will have different courier details.

As discussed above and in the OSS note, billing document takes the information from its preceding documents. Or else, there would be data mismatch and inaccuracy, that might make reporting etc. much less effective.

TW

[Former Member · Accepted solution]

hello,

for international shipments, the invoice must be attached to the delivery and sometimes it happens that the courier change when the invoice has already been issued. it's just a problem printing because the courier no haveeffect on accounting document, in the press of delivery is sufficient to note the change in print (and in any case also on delivery is not possible to change the courier after goods issue)

only we have this problem? where we go wrong?

(Sorry for my english ....) 

Fiorenzo

[former_member182378 · Accepted solution]

Fiorenzo,

Is the business need - the actual courier name, details must be printed in the invoice printout?

If the courier is incorrect in the billing document, then the printout also has incorrect information.

In exceptional cases, the courier changes from the one that is initially planned.

At what stage of the process does your company choose / finalize the courier?

TW

[Former Member · Accepted solution]

Is the business need - the actual courier name, details must be printed in the invoice printout?

If the courier is incorrect in the billing document, then the printout also has incorrect information.

this is the problem, you would want to change the courier of invoice for quickly reprint it with the correct courier

At what stage of the process does your company choose / finalize the courier?

the client communicates to us the courier collects the goods, but the day of the withdrawal tells us that it will be another courier to collect the goods. And the documents are ready and printed ...

we have the strange customers ... I know 

grazie TW

thanks for your cooperation

[Former Member · Accepted solution]

PS. :

I used the "hammer" method by editing the field "VBPA-LIFNR" directly in the table, and it works. But I'd prefer a more academic system.

[former_member182378 · Accepted solution]

Fiorenzo,

As we know, that directly changing values at table level is not recommended. But, i have seen, business does things to keep the business going, and this is the first priority.

An option (not a good one) is to have the "actual" courier printed on the invoice printout, even though the billing document, tab partners does has the old / incorrect courier.

Design:

Have/create a custom (z) table with courier number and billing document number. Once a billing document is created then this table will be  populated automatically with the bill no. and the courier.

In case, the customer changes the courier, at the last minute, then go and update the courier no. for that billing document no. in this z-table.

Add a logic in the smartform, to pick the courier no. from this z-table, instead of the billing document.

Business scenario:

Delivery is picked, PGI done. Billing document created and printed.

Customer changes the courier.

Business user goes to this z-table, changes the courier no. for that billing document no.

And reprints the invoice printout. In this one, the courier no. and details are the of the latest one.

TW

[Former Member · Accepted solution]

TW

thanks for the suggestion, a little laborious but doable.

I will have to prepare an ABAP program for the SD staff for changing the Z table autonomously

[former_member182378 · Accepted solution]

I will have to prepare an ABAP program for the SD staff for changing the Z table autonomously

Fiorenzo,

I didnot understand your comment.

If you choose to go with this design. You need to create a new table and a transaction code to access/edit this table. SAP Security team would have to give access to this transaction to those who should edit this table.

The coding in the smartform, assigned to the output type which triggers the invoice printout, needs to be changed.

When the customer changes the courier, business needs to change it somewhere. So changing it at table level or changing it in a z-table, the effort is the same.

The shortcoming of this design is that the SAP transaction data for example the sales order, delivery and the billing documents will not have the correct courier information.

TW

[Former Member · Accepted solution]

TW

right, sorry is my translation, which is incorrect.

I meant that I have to build a transaction for SD personnel.

thanks again for your cooperation.

Fiorenzo

[former_member182378 · Accepted solution]

Fiorenzo,

Please keep posting questions, comments in SCN. These real time issues and business process information is very beneficial to all in this forum.

thanks!

TW

[Former Member · Accepted solution]

TW

I didn't understand your comment.

I am publishing in SCN! or not ? where did I go wrong ?

if I made mistakes, I'm sorry.

Fiorenzo

[former_member182378 · Accepted solution]

Fiorenzo,

In my post I said thank you!

I wanted to say that your question (this thread) is of great value and will benefit many members. Your question discusses a real time issue (some thing faced by your business).

We are analysts, we will improve and become more experiences when we read and think of solutions, to real time questions. Like this one.

In summary, I wanted to say that this is an interesting question. and thanks for it!

TW

[Former Member · Accepted solution]

ok TW   grazie

[Former Member · Accepted solution]

I just googled about Grazie and learnt a new Italian word so Grazie for this . Coming to the query again after reading above threads, i would suggest you to consider Z* table as a last option but with change log, you know exceptions are always there. What if end user will not remain the same who's responsible earlier for changing the courier against billing document number using an upload program to update Z* table. What if the case would be that invoice has been returned and the previous end user has already left the company, new end user isn't familiar yet so what he will do first is to check the courier at billing document level which is suppose TCS and in billing document print it's appearing as OCS so it would be better to update Z* table with complete change log too with old or new values or you can overwrite the value of LIFNR for the billing document via an exit to avoid any discrepancies.

Another solution which i've in my mind is why don't you do separate partner determination for your sales order like ZS* by setting it as modifiable. For such billing documents whenever there will be a need to change the courier, user will select it manually under partners tab of sales order in that case you'll be having 2 partners for courier one is old and other is new. Now smart form logic for billing would be to pick the updated partner function always if found any against that preceding sales order for a billing document. I'm not sure whether business would be okay for the user to change courier at sales order level or you can simply give them an upload program to do so. There are ways around, but it totally depends which option you would like to go for. In case of any further assistance, please feel free to ask. Always willing to help. Stay blessed and happy week ahead. Thanks.

[Former Member · Accepted solution]

Ciao Rehman , grazie .

Another solution which i've in my mind is why don't you do separate partner determination for your sales order like ZS* by setting it as modifiable.

this solution would be great, but I have no idea how I should act to create it.

Moreover the carrier is inserted into the delivery (which can result from different sales orders) and also in delivery can not be changed if you performed the goods issue (we also WM)

I will have to consult an outside consultant. thanks

Fiorenzo

[former_member182378 · Accepted solution]

Fiorenzo,

How is the courier "inserted" in the delivery?

Is it done manually during creation of delivery or it populates automatically, extracted from some source?

Yes, I too observe that the delivery is uneditable after PGI and updating a courier in it is not possible.

Business process question - Why does business user complete PGI and create an invoice before the truck arrives? In my past company, the warehouse team clicked on PGI after the forklift truck loaded the truck. When you do PGI after loading the truck, you know the courier company. At this time the delivery is editable (PGI not done).

Once PGI is done, invoice can be created and printout can be taken.

So, you could look into the business process, and see if it canbe solve outside SAP, with user discipline and changed way of working in the warehouse.

TW

[Former Member · Accepted solution]

It was my assumption that from sales document, carrier is getting copied but no worries you can create new partner for sales order and add it whenever you want even after invoice creation. IMG path to configure the same would be sales and distribution -- basic functions -- partner determination -- setup partner determination -- setup partner determination for sales document header, here create a new partner function by assigning LI as partner type, then create a copy of TA name that partner function procedure whatever you want and add your carrier partner function to it. Now next step would be partner determination procedure assignment against your sales document type. Now even after invoice creation if business has the need to assign new carrier then it can be assigned at sales order level and same can be displayed for invoice print as per logic of invoice smart form. I'm sharing snapshots for the configuration steps in which i've choose existing partner function i.e. VN, you can create your own and do the determination and assignment accordingly both for sales document header and item levels. You'll find a lot of documents for this on SCN. My concern is why to take help from an outside consultant, why don't you try this at your own. It'll be a learning for you. You can ask me freely in case you need any help on this. Thanks.

Partner determination procedure in SD - ERP Operations - SCN Wiki

[Former Member · Accepted solution]

Thanks,

I'll do the tests in TEST environment and if you encounter difficulties contact with you

you are very kind

Fiorenzo

[Former Member · Accepted solution]

Please bear with me for the questions that i'm asking again and again. You said that the carrier has been inserted at delivery level which is a resultant from different sale orders so your business is responsible for single delivery and invoice creation against multiple sale orders (based on standard delivery and invoice consolidation criteria w.r.t sale orders). Is that so? I'm afraid if this would be the case then there's a complication in implementing above provided solution.

[Former Member · Accepted solution]

Is that so?

yes....

yes, the delivery is made for different sales orders, the invoice is carried out for a delivery or even for several deliveries!

[Former Member · Accepted solution]

Well if that's the case then for every sales document user has to assign new carrier as partner function which i'm sure won't be a big deal if business wants to fulfill this requirement. Suppose i'm having a, b and c sales document against which there'll be single delivery and invoice in the system so user will enter new carrier in a, b and c sale orders and vice versa. I believe there won't be any issue . In case you've any other question in mind related to this you can ask. Thanks.

[former_member182378]

Fiorenzo,

As I mentioned in an earlier post, maybe the answer lies in the way warehouse activities are done!

Business process question - Why does business user complete PGI and create an invoice before the truck arrives? In my past company, the warehouse team clicked on PGI after the forklift truck loaded the truck. When you do PGI after loading the truck, you know the courier company. At this time the delivery is editable (PGI not done).
Once PGI is done, invoice can be created and printout can be taken.
So, you could look into the business process, and see if it canbe solve outside SAP, with user discipline and changed way of working in the warehouse.

Warehouse process steps:

1. Picking completed, stock is at the door

2. Truck arrives, and is at a door

3. Forklift truck loads the truck

4.1 The courier is the same, what customer informed before, then warehouse team lead click on the PGI button

4.2 The courier is different, from what customer informed earlier, then warehouse team lead goes to VL02N, change the courier. Saves the delivery. Then clicks on the PGI button.

5. Create billing document and print it.

TW

[Former Member]

TW, as I explained, is not quite that straightforward.

thank you all, I realized that for SAP you can not do, patience

Fiorenzo

[Former Member]

thank you,

so you have to make a change in the USER EXIT. there is not a customizing function.

I'm abaper "light"  , will check how to update the exit. thanks for collaboration .

[Former Member]

Take the help of your abaper and write a piece of code at include RV60AFZD use FORM USEREXIT_NEWROLE_XVBPAK_AVBPAK or FORM USEREXIT_NEWROLE_XVBPAP_AVBPAK for header and item level. XVBPAP is the work area you need to look for. Feel free to ask in case you need any further info on this. Thanks.