Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

An issue regarding the program:RSNASTED

Former Member
0 Kudos

Hello,Experts:

I have an issue regarding the program:RSNASTED.We have an EDI output type:ZDE1 which is using the standard program:RSNASTED.Sometime, user will manually add this output type into the delivery document.But in this case,the output requirement doesn't work if the output type is manually added.So we need to add some checking into the program:RSNASTED in order to block this EDI output type sent out if certain conditions are not met,for instance, a block is set on the delivery document.

Do you know if there is any user-exit which can be used for this purpose?

Thanks

Title edited

Edited by: Rob Burbank on Oct 2, 2009 11:35 AM

5 REPLIES 5

Former Member
0 Kudos

I think you'd be best off to search for a customer exit within the specific area where you're creating the IDoc. I.e. instead of using a generic customer exit with RSNASTED (doesn't exist to my knowledge, didn't double-check in a system though), which would get triggered for all outbound IDocs, it seems much better to actually code your requirements into the outbound function module that generates the output (so if you're using standard SAP, search for an exit in that area instead).

I'd say a good example is function module IDOC_OUTPUT_ORDCHG for sending purchase order change messages. In some cases the output fires, but then SAP determines that there are no relevant changes that should be sent, so no IDoc is generated and instead an error message appears in the output log.

Another option might be within the transaction, where the user adds the output type manually (which renders the requirement useless). Here you actually might be able to prevent the addition of the output type and give a direct error message to the user.

Last but not least, my usual favorite: If the user adds the output manually, it seems that that's what he really wants to do. That raises the question if this might rather be a training issue, if the output really shouldn't be generated...

Hope this helps, harald

0 Kudos

Hello,Harald:

Thanks a lot for your reply.Our SAP is now connecting to SAP GTS system. So if a delivery document is blocked in GTS,we need to block the EDI message sent out from this delivery document.Output requirement for the EDI message work well to prevent the automatic created EDI message in the delivery document but doesn't work in the case user manually add edi message into document.

Now we add the checking into the user exit:EXIT_SAPLV56K_001 in function:IDOC_OUTPUT_Delivery to block the IDOC generation if delivery is blocked in GTS system.The IDOC generation can be blocked successfully by this user exit but the EDI message type will still have the status of "successfully processed" in the delivery doucment after IDOC generation is prevented.So user have to manually repeat the EDI Message type so that this EDI message type can be retriggerred by the background job of RSNAST00.

I am wondering if the EDI message in the delivery document can still have the status of "not processed" even after IDOC generation is prevented.

BR

0 Kudos

Search for a user Exit where you can update the status of IDoc Error.

You should populate the ERRTAB with necessary values to get the IDoc status Updated.

Can you please check it.

0 Kudos

Hhmm, I'm not sure I fully understand the requirements. So via requirements you are already preventing the delivery output from being created, but you are concerned that users manually add the output. If that's correct then it still sounds actually better to somehow prevent the user from triggering the output manually...

Anyhow, as far as I know within standard SAP output processing you don't have a chance to keep an output record in status not processed once you've triggered the actual processing. So once processing has started the output record should either be marked as successfully processed or faulty (error occurred, no output was generated).

If you want to suppress the output via the customer exit EXIT_SAPLV56K_001 you're using, you basically set the status of the NAST record via the exception that you return. By using exception DATA_NOT_RELEVANT_FOR_SENDING SAP (RSNASTED/EDI_PROCESSING) will mark the output record as successfully processed and add the message that you returned with the exception to the output log. However, if you'd trigger exception ERROR_MESSAGE_RECEIVED, the output record would be marked with an error status and you'd see the error message in the output processing log (and you could setup workflow to provide the user with the corresponding workitem).

Overall this still seems awkward though. I'm not sure if you could somehow come up with a better solution. For example use incompletion log to mark delivery as incomplete as long as it's blocked in the GTS system (not sure if that would allow saving of the delivery though, like it works on sales order level - maybe configurable?). Another option might be to always trigger delivery output and then suppress output if the delivery has already been output or if it's still blocked. To account for possibly necessary manual resends, one could evaluate NAST record to see if it was triggered manually versus automatically for "not-blocked" deliveries (NAST-MANUE).

Former Member
0 Kudos

Hi,Harald:

Thanks a lot for your kindly help!

BR