Generate Output (NAST) from Purchase Order line item (EKPO)

[juan_suros]

I have a requirement to send information about individual Purchase Order line items out of SAP. This is a sales interface that mixes Sales Orders and Purchase Orders, considering each line item (VBAP, EKPO) a unique order.

In Sales Orders, NAST based outputs are directly supported at the line item level. For Purchase Orders I will need to write some code.

Each line item output will be processed as an outbound edi document.

Can anyone who has done this give me advice on best practices?

[roberto_forti]

Hi,

For example, see the conditions for output types by transaction NACE and which object is setting up (processing routines) i.e. program = "Z..." and Form Routine = "Entry". Transaction WEDI is about Idoc's.

[DominikTylczyn]

Hello juan.suros

I don't think item level output processing is supported by purchase orders.

One obvious workaround is to restrict purchase orders to one item only. If that is feasible, you won't have a problem anymore.

Another option is to trigger the output on the header level and generate as many EDI documents as there lines in the purchase order ready to send. You are implementing custom processing of the output anyway, so that's perfectly doable. The custom output processing could work as follows:

1. Read the output processing log of the previous instances of the output. The log can be read with the WFMC_PROTOCOL_GET function.
2. Loop through PO items. For each PO item:

• Check if the item is ready to send. If not, skip the item.
• Check in the NAST protocol from point 1, if the item has already been sent. If so, skip the item.
• Generate EDI document for the item.
• Store the item number in the output processing log using the NAST_PROTOCOL_UPDATE function.

Make sure that the output can be triggered multiple times. Then if there is a change to the PO and new items get ready to send, the output will be triggered again.

Best regards

Dominik Tylczynski

[juan_suros]

RE: Header level processing: In my use case, there is no guarantee that all document items are ready to send at the same time. I may end up doing something like that repeatedly, running all items in the correct state each time.

Thank you for response

[Ryan-Crosby]

If they aren't ready for processing then maybe they should go onto a different PO... that's really a process issue and not a system issue. Beyond that, it also sounds like some type of process where the proposal is to bend the system to something it is not built for... I'd look at that a lot more closely. But the approach that 3a9e4ce873a94034b33dc62b0ce600ee has suggested is likely to be much more manageable in the long-term than generating outputs by item.

[juan_suros]

Ryan,

You are pointing out that if we restrict Purchase Orders to a single line item, then we keep the standard logic for all quantity and fullfillment scheduling while removing the distinction between a header and line item output.

I'll run it past the business types.

Thank You,

Juan

[DominikTylczyn]

juan.suros See my updated answer.

[Ryan-Crosby]

juan.suros No, I simply meant don't include items that are not ready for sending because you had mentioned that they might not all be ready at the same time. Hence the suggestion that that piece is more a process issue.