Concept Question about EDI and Error Processing

[Former Member]

Hello All,

This is a concept question, I was wondering how others would approach this scenario.

Let's take this scenario. In EDI often the transmission for a purchase order comes in with an invalid material number. Normal error processing is for the EDI team to research the issue (find the correct matnr), edit the idoc and reprocess the Idoc. I would like to move that type of error processing out of the hands of the EDI folks and into the hands of the business users.

How would they correct the material number? It has to be more intuitive than editing an IDoc, it has to be an easy and intuitive user interface. This process has to also work for many types of EDI transmissions both inbound and outbound.

There would be many ways to handle this: create a report with an editable grid that would change the idoc during input and create the order with the corrections, convert the idoc to xml and use simple transformations, use an xsl report...etc. You get the point.

How would you approach this? Before I start the design I want to make sure I've given all the options due consideration...all options, webdynpro, transformations, regex, you name it...all is available, except there is no XI.

Personally I'm leaning towards an editable grid and processing buttons that would post the idoc in background...but I do that type of thing all the time and I may be in a rut and neglecting better design options.

Thanks for your input,

Greg

[ThomasZloch]

> Personally I'm leaning towards an editable grid and processing buttons that would post the idoc in background

That's how I solved this about 8 years ago, if that's of any help to you. It was actually a classical report using WRITE statements with options INPUT and HOTSPOT, I have to admit shamefully. But it worked well in practice.

Let's see if there are better ideas nowadays.

Thomas

[Former Member]

Hi Greg Foss

Do this way... but it not recommended by SAP.

For example you received a purchase order with wrong material Number and data is

Transmitted to SAP System... idoc generated and waiting for processing...

Create Custom z report for users...where purchase order IDoc item details is shown in the report

If user thinks any of the material is wrong the uses enter the correct material number side to wrong material number and save the report . Once the report is saved then data is stored in a Custom table with IDoc number, line item number, wrong material number, correct material number etc (This table helps for referencing the correct material no while processing the idoc )

Now Write use exit to change the IDoc segment data at line item level i.e. Material number at line item by comparing the table...

Note: First IDoc (inbound) need to generate in 64 status

User should correct any material is wrong in Purchase order using custom z report

Then process the IDoc....

IDoc got posted with out wrong material...

In brief

A custom Z Program can help to correct the wrong material number in purchase order .. beforen IDoc is posting to sap.

Thanks

Ramesh

<telephone number removed>

Edited by: Thomas Zloch on Apr 15, 2010 12:10 PM

[Former Member]

Thanks both Ramesh and Thomas,

We are all thinking alike, this seems like the right course of action for me. I'm going to leave the query open for a while, I'd like to see what other folks have to say. I'm thinking that the old style technique of handling this situation is the best...however, I'd really like an excuse to use webdynpro or some transformations.

Greg

[Former Member]

Hi Greg,

some thoughts that popped into my mind relevant for choosing a solution:

<ul style="list-style:square;">

<li>Data volume, percentage of failed messages and time needed to correct them</li>

<li>Types of errors, their distribution and actions required to resolve the problem (e.g. IDoc editing versus master data corrections or similar actions).</li>

<li>Reporting requirements around the interface</li>

<li>Organizational structure and user(s) handling the failed messages</li>

<li>Integration into existing structure for handling process failures/error monitoring</li>

</ul>

I'm surprised that nobody mentioned workflow yet (though I'm not really a workflow fan from what I've seen in SAP so far, but it has its advantages).

Though standard IDoc error workflows are rather technical in nature and pretty simple, i.e. centered around showing error messages and reprocessing of IDocs (general reporting seems also poor), workflow capabilities offered by the framework like agent determination, hiding of work-in-progress work items from other users, hand-over of work items and several options for deadline monitoring are pretty neat. So by defining a custom object and attaching it to your IDoc message you're free to implement additional frills (like the editing capability without having to go down to IDoc container level) and combine it with the workflow advantages.

I like the ALV approach, because it's a nice way of combining reporting capabilities with the error handling. But when the requirements include too many workflow features, the ALV solution might become to cumbersome to implement.

Regardless of the chosen solution user training including basic IDoc training is very important. Though business users like to avoid dealing with the technical details, the concepts are actually pretty simple and will help in dealing with possible errors and possible reactions. This way they're equipped with the knowledge to tackle also new interface errors and they're less likely to do silly things.

I doubt that you'll be able to define a solution that provides a nice user interface hiding technical details and allows correction of all possible interface errors (which often shift due to the simple fact of existing quality improvement processes). Though technically possible, I'd like to see the controller who is willing to pay for all the implementation effort...

Cheers, harald

[Former Member]

I dont think that it can be done with out a Zreport! . So I Would like to share my creativity! z-report should provide below steps for business.

1. it can be run daily basis, which should select all idocs which are in status 51 with message number (..related to wrong material number). report output should inlcude :idoc number-wrong mat no- space for new material to be entered by business against wrong 1. And there should be one button for RUN.

2. After RUN, the material number should be changed to new 1 in segments and idocs should be reprocessed.

3. repeat the run until business enter right mat num.

--

Reddy

[Former Member]

We handle the reprocessing of failed IDOCs in a slightly different method.

It is a bespoke report, which details the errors in ALV, but we have a reprocess button on the report. This calls function IDOC_INPUT and we set parameter INPUT_METHOD to 'E'. This calls in foreground from the error.

So it runs the transaction silently in BDC format, until the error occurs, then opens up in dialogue to allow the user to change the invalid material, and then continue on with processing.

[Former Member]

<b>Paul:</b> So it runs the transaction silently in BDC format, until the error occurs, then opens up in dialogue to allow the user to change the invalid material, and then continue on with processing.

This works when the processing function module uses BDC. But even then I think this is possibly nice from user perspective, but a nightmare from auditing perspective. I.e. correct me if I'm wrong, but I'm pretty sure there's no log indicating that the user changed the material number. Thus for anybody comparing the IDoc contents against the posted document (including change history) there's no trail that shows this change. Of course you can assume that this is what must have happened, but I personally prefer if I can track in the system what happened and have proof for that.

<b>Reddy:</b>
<ol>
<li>it can be run daily basis, which should select all idocs which are in status 51 with message number (..related to wrong material number). report output should inlcude :idoc number-wrong mat no- space for new material to be entered by business against wrong 1. And there should be one button for RUN.</li>
<li>After RUN, the material number should be changed to new 1 in segments and idocs should be reprocessed.</li>
<li>repeat the run until business enter right mat num.</li>
</ol>

Design seems to limited to me (takes care only of one error message). Might work if that's the main pain point and this is the only one the user is dealing with. Otherwise I'd expect pretty soon they start complaining about having to use different tools for the possible errors. I'd keep the report more general, but allow this special form of processing only for a given error message (otherwise it's a normal re-process as triggered for example via BD87).

Also, I assume that when you talk of changing the IDoc you mean that you actually keep an original copy around (like SAP does when you edit an IDoc). Often this is required from an auditing perspective. I'm not sure why you wouldn't want to check the material number <em>before</em> trying to process the IDoc to avoid wasting system resources (but maybe I misunderstood the step).

Anyhow, in theory you could also achieve all of this via workflow. You can add custom columns to the work item overview in the inbox, only issue here is that it doesn't scale well (so issues with larger volumes).

[Former Member]

You know, this is what the forum is all about sometimes...hearing how different people approached a similar problem.

My conclusion is that most people in this forum have approached the situation quite similarily. Some used the foreground processing option, some used native or enhanced workflow...but in the end, it is not that entirely different. I should have put in more details on the frequency of the errors and the users, it would have honed in more exact responses.

In the end, I'm going to go with an editable ALV. Errored IDocs can have any relevant field changed at the header or the line item. When the user has corrected the error they will push a button that will essentially reprocess the IDoc with the corrections.

I know...not very glorious or fancy...perhaps I'll do the ALV in WebDynpro...haven't done that yet, I'm a little bored with the standard ALV and all, they've made it too easy for us.

Thanks everyone...I tried to throw the points around for the discussion.

Greg

[Former Member]

Greg,

I'm probably a bit late to this party, but thought I'd throw in my two cents anyhow...

We've taken a different direction on this. What we do is check the products in a userexit of IDOC_INPUT_ORDERS, and then override MATNR with either UNDEFINED-MAT or EXCLUDED-MAT, depending on the results. We also build a Material Description relating to what was ordered, and the result of the Material check. For an Excluded material example, we would include the barcode ordered, the Material determined, and an indicator showing how it might be excluded (Deletion Indicator, Sales Status, Exclusion record). The Sales Order item is recorded as such, and our Customer Servce team runs reports frequently on such items. If they can resolve the issue they will, otherwise the information is used to realign the master data with the Customer.

Probably the main reason we do it this way is because most of our business runs to very tight delivery deadlines, and they would rather miss one line off an order, than miss the entire order.

Cheers, Paul.

[former_member782348]

Homedepot sending preferred carrier in the EDI order. In CMS order is created with carrier based on this.

For ex:

In EDI file, value “UPSG” is coming in segments. Which is equivalent to carrier UPS and ground shipping.

Can you please let us know how to convert this into SAP. So that we will map accordingly.