So I have been developing SAP IDOC interfaces for nearly 20 years.  Started with IDOC in the R/3 .0D days.  I have seen a lot of really poorly configured IDOC scenarios.  So here are 5 things I always do when configuring IDOC.

Here are 5 things you should do with SAP IDOC Interface Design:

1. I never use the delivered message type.  What do I mean by that?  You are implementing an outbound ORDERS interfaces so the standard SAP message type and IDOC type delivered would be ORDERS:ORDERS05.  I always immediately configure a new message type.  Something as simple as ZORDERS:ORDERS05 but usually something a little more complex like /xstream/orders_web or zorders_web.  So you are saying why would you do that when you can just use the standard delivered message.  There are a number of really good reasons; 1) You are most likely not the only one that will need to use this interfaces.  2) When enhancing the interfaces which you will most likely need to do you will potentially impact others leveraging it or they will impact you.  3) Most third parties developing integration into SAP for their respective products don’t really know what they are doing and use the standard names and therefore end up impacting your particular integration scenario with their changes.  4) You always have the standard vanilla interface to benchmark against in future development and troubleshooting.  5) You can organize your naming across multiple teams / integrated systems so that message type allows you to quickly see what system is using what transaction.  Specifically you want to look at all orders for all integrated systems.  You can see this if you name your message types in a smart way.  NOTE: Just because you renamed the message type doesn’t mean you have created a custom interface.  You have just given it a new logical name.  I have had this argument a number of times over the years where Chicken-Little goes running around saying all the integration is custom and we are not using standard SAP interface, not true we are using a standard interface with a new logical name.
2. If you enhance an inbound or outbound processing routine WE41 and WE42 (even if you just implemented a user exit) create a new process code, even if it is not required.  Again good reasons for this; 1) Allows you to keep your processing isolated from other processing. 2) It is an immediate clue to support teams that something non standard is not running.  3) If you do modify processing as a result of your change you can always flip back to the standard to look at how the standard code behaves.
3. Never use immediate processing on partner profile WE20 in production.  EVER!!!  (I could write a book on all the bad things that can and will happen)
4. When enhancing inbound IDOC interfaces use pre and post processing wrapper around standard processing routine when possible instead of enhancements or exits.  When an IDOC is posted or created via Change Pointers or Message Control they are typically processed through standard function.  These functions often have built in exits and many enhancement points that allow you to modify standard IDOC processing.  There are cases where these exits and enhancement points are required and the logical choice for implementing your specific change.  However in my experience I have found that wrapping a standard function with a wrapper function usually can get the job done.  Why do I like wrappers better?  Because they are easier to find and trouble shoot.  The processing is either before or after entering the standard processing function and is contained to one place.  I have seen instances where 3 plus exits / enhancements have been implemented and causing issues.  Digging though the code to find the custom code causing the issue can be very time consuming.  Again there are some things where a wrapper just will not work, in those consider wrapping the function and using it to document the specific exits / enhancements you are using, because 5 years after you write your enhancement the poor support guy following in your foot steps will never be able to find the documentation you created and saved in Solution Manager.  Technically you most likely can not find the documentation you created and saved in solution manager.
5. Unless you are sending sensitive data,  you have unimaginable data volumes, or you are implementing a standard IDOC scenario that generates a ton of segment data that you just don’t need, avoid using IDOC filter techniques.  Specifically IDOC message reduction, IDOC segment filters, and IDOC views.  20 years ago these features where important to control network volume and storage volume.  Today both network traffic and storage load are pretty insignificant when designed correctly and just make your life more difficult when maintaining the interface. Most IDOCs go through a middleware tool, the mapping layer is often a natural IDOC filter to map only the data you need.   If you apply filters upstream of middleware and then someone requests some of the data that was filtered upstream you have to make 2 changes.  You need to unfilter the data then you have to update the mapping.  Again only place I apply filters today is with sensitive data that I do not need in mapping and would prefer not to expose in the middleware layer.  BTW I have most likely said the opposite in previously published documents 10-15 years ago, that is because 10-15 years ago IDOC load was a real factor on overall system load.

One more thing to consider.  Pick the right technology for your integration.  There are so many approaches that can be used to integrate with SAP.  In almost all cases a file based interface is the wrong choice, the problems they create from a support perspective are huge.  If you require an Asynchronous feed you need to consider IDOCs or PROXY’s.  If you require Synchronous communication you can consider direct RFC, BAPI, Web Services, or SAP Gateway O-Data Services.  Each SAP integration technology has their strengths and weaknesses so pick the one that best fits your requirements and your overall infrastructure strategy.