When it comes to coding, my basic philosophy is summed by the KISS principle: Keep it Simple, Stupid.
If I wanted to count the number of times that I've been called either simple or stupid or both I'd have to take off my shoes and socks. And I don't want to do that here. Young, impressionable minds may be reading this.
But I did want to write about a really cool, simple, and maybe slightly stupid custom EDI utility that would prove very useful in managing the number of work flow items associated with STATUS IDocs in your SAP ERP system.
This utility is useful for those hardy souls who have built a STATUS IDoc interface into SAP to update their outbound IDocs with status information about key processing milestone in the EDI subsystem such as translation, transmission, or even 997 Acknowledgment from the trading partner.
I could write about building a custom STATUS interface from your EDIU system but I may save that for future postings. If you're working with an external EDI system and trading partners — and there are thousands of SAP sites that are — it's a useful interface to have because it records the processing history of the IDoc outside of SAP within the IDoc's status and control records.
The basic problem I'm trying to address here springs from the fact that the STATUS IDoc is triggered by a work flow task — TS30000206 — which is linked to process code STA1 in the inbound partner profile.
Go Forth and Multiply
This means that everytime a STATUS IDoc posts to SAP, it generates a number of records in the work flow system. Take the example of a STATUS IDoc updating an outbound INVOIC with STATUS 06 or "Translation OK" indicating that the translation map in the EDI system successfully converted the outbound IDoc to an X12 810 transaction set.
Another wonderful EDI milestone to track in your outbound IDoc in SAP is receipt of the 997 acknowledgement from the customer. This is particularly useful for dealing with a technophobic Accounts Receivables department when they call to complain that they can't see an invoice on a customer's website and could you please resend?
It's a great feeling to look up the INVOIC IDoc in SAP, see that the current status is 16 which proves that the customer acknowledged receipt of the 810 in their EDI system, and to then be able to give your friendly AR contact the date and time that the invoice was received by the customer.
Tracking EDI activity creates data in SAP. There will be a STATUS IDoc recorded in the IDoc database tables EDIDC, EDID4 and EDIDS. This IDoc is not linked to any business object in SAP and has no purpose once its outbound IDoc has been updated with the new EDI system status. It's not really useful even for reporting, unless you're a real data freak and want to be able to count the number of angels who can dance on the head of a pin.
You'll also get a number of records in all tables associated with the work flow system. These records are recorded because, as we have pointed out, the IDoc is triggered by a work flow task. A small sample of these tables and records include:
| Table | Description | NoOfRecs |
| SWWWIHEAD | Work flow header record | 1 |
| SWW_CONTOB | Work flow item data container object records | 2 |
| SWW_CONT | Work flow item data container | 1 |
| SWW_WI2OBJ | Relation of work item to object | 1 |
| SWWLOGHIST | Work item processing history | 5 |
Double this if you record one or more additional processing steps in the EDI system, such as 997 acknowledgments.
Scratching the Surface
This just a sample of some of the key tables in the work flow system that are populated by STATUS IDoc processing. Many more tables are actually updated.
Now this wouldn't be an issue if we were only talking about a handful of STATUS IDocs. But if you're generating around 5,000 to 10,000 outbound IDocs everyday — invoices, deliveries, vendor PO's, and so on — and if the STATUS interface is recording one or more processing steps for each one in the EDI system, you could easily receive tens of thousands of STATUS IDocs into your SAP system everyday.
This is not remarkable volume. It's the kind of traffic that would not be out of line for a company with revenues between $700 million and $1 billion a year that depends heavily on EDI for customer orders, shipping, and invoicing.
Even if your EDI system bundles all status updates into a single STATUS IDoc by EDI interchange, each outbound interchange can be multiplied by at least one or more STATUS IDocs. If your EDI system cannot or does not bundle status updates, you can multiply each of your outbound IDocs by one STATUS IDocs for each processing milestone tracked.
So don't be surprised if 25 or 30 percent or even more of the total number of records in your EDIDC table — which records the IDoc control record — are STATUS IDocs. You can then multiply each of these STATUS records by at least 10 to get the approximate number of work flow items generated by each of your status updates.
And that just covers the sample work flow tables we recorded in our table above.
You don't have to be an Einstein to figure out that between the STATUS IDocs and all of their linked work flow items, your system will accumulate a whole lot of data that is going to impact the performance of your work flow system, including your SAPOffice Inbox, which reads the same tables to pull up its work tasks.
I don't know about your experience, but mine is that the SAPOffice Inbox suffers from poor performance in the best of circustances. Throw a million or more work flow items into the same tables that it reads and performance is bound to suffer. And the rub of it is that STATUS IDocs and the work flow item data they generate are not used by anything and are not linked to any other business object once they've completed updating your outbound IDocs with current EDI processing status.
The Good News
So the good news is that you can safely delete all these records.
There are standard programs that you can use to delete both STATUS IDocs and their linked work flow records. Transactions:
- WE11 (report RSETESTD) deletes IDocs by Message Type and create date range.
- SWWL (report RSWWWIDE) deletes work items by work flow ID, type, status, create date range, and task.
- SWWH (report RSWWHIDE) deletes work item history by work flow ID and create date range.
WE11 deletes all IDocs of a particular message type but not any of its associated work flow items. SWWL deletes all work items from all tables by work flow ID or task but you need to have one or the other of its keys in advance. Task TS30000206 can be used to identify STATUS IDoc work items but so can TS30200090 and TS00008068 which are also used by other business application IDocs that you may not want to delete at the same time.
As for SWWH, you need the work flow ID, although SWWL also cleans out work item history.
Still, you can catch most of your STATUS IDocs and workflow items by running WE11 for message type STATUS followed by SWWL for all work items by task TS30000206. These parameters may not catch them all but if you schedule a two step job — the first step for SWWL and the second for WE11 — to run everyday or every other day, you should catch most of them.
I'm an ABAP programmer and I love to code. I also love to poke around in the standard code and figure out how SAP does certain things and then use these discoveries in my own utilities. Luckily, a lot of these house-keeping tasks are handled by standard function or method calls.
So stay tuned for part 2 of this posting where we will look at a couple of these functions and see how they can be put together to make a simple custom ABAP that will in a single step delete all STATUS IDocs along with their linked work flow items and history.
Whether or not you want to do this is up to you and your basis team. At the very least, it's good to understand what the options are and how SAP works. I'm a great believer in leveraging standard SAP functionality in my custom ABAPs. It makes my life easier and more interesting at the same time.
