Problem with output of Outbound Delivery

[maciej_gottfried3]

Hello All,

I have a problem: when deliveries are posted via VL02N, the output determination works correctly - YPDF position is created in NAST

and possible to use. Unfortunately, when goods issue is posted via VT02N, outputs determination is different, and no YPDF output is

determined. It is possible to create it manually (via Extras - Delivery Output - Header) but it not acceptable for every document.

What can possibly be wrong and where shoud I check to make this VT02N path correct?

Thanks in advance

Best Regards,

Maciej

[Lakshmipathi]

Moved from SAP ERP Sales and Distribution (SAP SD) to Output Management

[VeselinaPeykova]

1. Check the requirement for the output type in the output procedure and the dispatch time in the condition record. When the output should be determined (is there a check for goods movement status)  and how it should be processed (immediately, application own transaction etc.)?

2. If you process the output at shipment completion, please check what is set in RV56ABST and the corresponding variant for your shipment type - is the output type specified in the variant, is 'Carry out goods issue posting during save' specified. To process delivery outputs via VT02N, they should be already determined in the delivery in the previous steps (before goods movement is posted).

3. What do you see in the determination analysis for the output in the delivery after processing it via VT02N?

[maciej_gottfried3]

1. Requirement is of type 1 (Delivery GI posted), dispatch time is set to 3

2. I have to ask for that, since I'm not processing the data,

3. For YPDF type I can see:

Condition type    Message    Description

YPDF              541        Output found

Access    Message    Description

010       541        Output found

and it looks exactly the same as or "correct" delivery notes, which can use YPDF

BR,

Maciej

[VeselinaPeykova]

If you would like to process the outputs via RV56ABST, you will need to remove the requirement for the output type,

or...

you can set dispatch time for YPDF to 4- send immediately (keep the requirement for goods movement status as it is now) and in this case you do not need to include it in the variant for RV56ABST.

The reason behind my proposals:

In the first step of RV56ABST the already determined outputs in the deliveries are selected and processed according to the selection criteria specified. In your case the output is not determined, because you do not have goods issue posted yet, so there is nothing to select.

In the next step goods issue is posted. You output can be determined now, but it is too late.

In the third step billing is performed (if it is set in the variant).

For the documents where you have not determined output and you have posted goods issue - just enter each delivery in change mode and save (for a really big number of incorrect documents a batch input can be a good option), then you can mass process them via VL71.

[maciej_gottfried3]

Hello

Thank you for your suggestions - I will check if dispatch time change helps.

One more thing, that seems to confirm your way of describing things: three other outputs are determined for the discussed case, but they have requirement type set to 0 (which is no requirement I guess?). So if this flow looks like:

1. Determination&processing  -> 2. PGI -> 3. next steps

It would seem, that setting requirement to 1 for YPDF causes lack of processing for that in point 1. Am I right? So maybe it would be reasonable to also set reqirement to 0 for YPDF so it is processed regardless to PGI step. However the question is, what side effects can it bring?

BR,

Maciej

[VeselinaPeykova]

Is it reasonable to remove the requirement for goods issue for YPDF?

The answer depends on why you have it in the first place.

1. Do you expect any data coming from goods issue to update any information for the printout?

Example: you print a non-valuated delivery note and you need to fill the actual goods issue date.

2. What will be the consequences if somebody processes the output from VL71 before picking is finished?

Again the example is with non-valuated note: in this case you may get incorrect or misleading information, as goods issue is the step where the truck leaves the premises and you are supposed to check the quantities based on the printed papers, also this would be the document that the customer would sign for product acceptance.

3. Technically you may have additional processing after the printout, such as updating z-tables, generating documents and so on - you ned to check what will be the impact in your case.

If none of these cases is relevant for YPDF, then probably it will not be a huge problem to remove the requirement. Otherwise it would be better to keep it and set the processing time to immediate.

I completely forgot to ask earlier, but do you use collective processing of outputs like DSDP? If not, then just ignore that I asked

[maciej_gottfried3]

So I guess that here is the clue - one more question: do you know how to call output determination so I can use it in postprocessing? It would resolve the issue I think.

BR,

Maciej

[VeselinaPeykova]

I am not sure whether I understood your question - do you mean that you are fine with the idea to print the output at shipment start for example? It may be techically possible by assigning an activity profile to shipment start for this shipment type, but does not seem logical from business perspective.

[maciej_gottfried3]

Sorry for the shortcut. I think, that postprocessing in some exit after RV56ABST, that would re-evaluate outputs and create ones according to current conditions would be good solution. Since it is after PGI, YPDF should be created. I'm checking FM MESSAGING right now, but no luck so far.

BR,

Maciej

[VeselinaPeykova]

Hmm, really strange, in one test system I actually managed to process an output with print requirement 1 and processing time 3 + GI at completion... Which probably means that what I have explained so far for RV56ABST may be not valid for single delivery outputs. Did you check in your activity profile for shipment completion whether you have set YPDF output to be processed at all?

By the way, since output determination is checked at each delivery change - do you get the output determined for the delivery after GI is posted from VT02N?

[maciej_gottfried3]

I've checked variant assigned in activity profile,it doesn't contain anything about YPDF. In section "Print output after save" only "Messages about shipment has "Shipment" checkbox checked and output type given (but some other than YPDF). Since this whole issue is about delivery note, should "Messages about delivery" be also checked and filled with YPDF output type?

BR

Maciej

[VeselinaPeykova]

Are you absolutely sure that you do not use collective outputs for shipment processing and that you are not expected to assign YPDF to one of them? If yes, then set the delivery checkbox, enter the output type YPDF and save the variant. If you have doubts about collective processing, then you will need to check what each shipment output assigned to the profile is used for.

Side note - activity profiles can be set in each system separately without transpart requests, so please make sure that they are consistent.

[maciej_gottfried3]

I have two separate shimpemt types in activity profiles, one for individual and one for collective. This case was individual, unfortunately change in the variant didn't bring any change in output determination. Strange thing.

BR

Maciej

[VeselinaPeykova]

What do you see in VT70 for your shipment after shipment completion if you select the delivery checkbox (assuming that YPDF is not processed yet)? Do you see the output in the list when you use processing mode 1?

Activity profiles are used just to select outputs for processing at a given shipment status, they do not trigger output determination.

[maciej_gottfried3]

I can see three positions,which are determined correctly (those are visible when trying to call output to printer in VL02, the same are in NAST table).

BR,

MG

[VeselinaPeykova]

Reverse only shipment completion status (do not execute VL09), save, then try again to perform shipment completion from VT02N. Are the YPDF outputs processed correctly now?

[maciej_gottfried3]

Hello again

I did that - YPDF did not appear.

But I've made another test - set requirement to 0 and in such case YPDF got determined correctly, that would confirm that the problem is with order of events - PGI goes after output determination. Unfortunately it cannot stay that way - this requirement is mandatory from business point of view.

Thinking on some custom requirement routine to turn it off conditionally... I've found few other similar issues reporter, but no standard solution for them so far.

BR,

MG

[VeselinaPeykova]

Please correct me if I am wrong - what the business needs is: YPDF to be printed immediately after goods issue posting for the deliveries. Not to have to print manually via VT70 and not to allow YPDF processing in case goods issue is not posted.

If this is the case - is there any specific reason not to go with the other option, which I suggested earlier - to keep the print requirement for goods issue posted in the output procedure, but to set the condition record for the output to 4 - immediate? I suppose that you use some z-program in NACE for YPDF to process the printform - is there some specific part of coding that does not work with immediate output?

[maciej_gottfried3]

No, there is no problem with immediate printing. But since requirement 1 blocks the process would setting time to 4 change that? As you've stated at the beginning - output determination takes place before PGI and that seems to be the core of problem. The latest idea is to create custom requirement code and contitionally allow printing according to the source tcode of whole process.

BR,

MG

[VeselinaPeykova]

If YPDF is not some kind of valuated delivery note (for valuated delivery notes you need to generate a proforma to fetch pricing data), then there are basically two ways to process the delivery outputs in case you have shipment processing:

• The first one is by using activity profiles for the shipment, which fetch the outputs and process them.
• The second one is without using activity profile, but relying only on the output determination and processing in shipping. For the second option you need a way to tell the system to process the output. Since you do not use activity profile, you can set the condition record to immediate and after it is determined (posting goods issue is a change in the delivery), the output is determined and with processing 4 it should go to green.

In case you need to print valuated delivery notes, the situation is a bit different - there you rely on a collective shipment output, to which you assign the delivery outputs. You do not set the delivery outputs in the activity profiles, just the shipment output. In this case you have to set the processing time to 3, otherwise the main program, that is used for DSDP will result in error.

In case you have a user exit for output determination - e.g. redirecting to a different printer, then setting the delivery output to immediate processing might not work as well.

I would suggest that you try the option with immediate delivery output and with requirement 1 (without activity profile usage) and see whether it works for your scenario.

In some cases the root cause for output determination and processing can be incorrectly developed print requirement, but since you stated that you use a SAP standard one, I believe that this is not the case.

If you decide to use the source tcode as a criteria in a new print requirement - you may need to evaluate a number of possible ways to print/reprint a delivery output (VL03n, VL02N, VT70, VL71 are the first that come to mind). It is not impossible, but could be a challenging task.

Edit:

You might want to check the explanation and the possible solutions in this SAP note - 509475 - Delivery output: Behavior during GI posting via shipment .