Automatic Trigger of Idoc Sending to PI on Material Master Create/Change

Question

Hi All,
I would like to ask how to automatically trigger sending of idoc on material master create/change without using a standard transaction like BD10. I already tried using MASTER_IDOC_DISTRIBUTE in the material master change user exit. It does send the idoc but my problem is when an inbound idoc creates a material, it will then pass through the userexit and use MASTER_IDOC_DISTRIBUTE again.
Any suggestions? Or do you have a better solution for this? My requirement is when uer goes throgh MM01/MM02 an idoc will automatically be sent to PI.
Thanks.

Answer 1

First of all a quick comment to your present solution. If it works and your only problem is that you'd like to suppress triggering the IDoc creation when a material is created/updated via inbound IDoc then you might want to just fix that. There's many possible ways to approach this, it all depends how much you want to change and what your processes are (I sorted the listed ones in order of personal preference, though the list is not complete for sure):
<ul style="list-style:circle;">
<li>Export some flag to memory when processing an IDoc that you can import in your exit and thus recognize that you don't want to send an IDoc. Depending on how you are processing your inbound IDoc BAdI BADI_MATMAS_ALE_IN might work; you might find others if this is not applicable or sufficient. If you're working on ECC 6.0 you could also consider coding the export of the flag in an implicit enhancement spot in your function modules used for IDoc processing.</li>
<li>Evaluate in your existing coding the transaction code SY-TCODE; most likely you should see a clear difference between your IDoc processing and the other updates where you want to trigger the IDoc.</li>
<li>Most likely the IDoc processing triggers function module MATERIAL_MAINTAIN_DARK (e.g. MATERIAL_INPUT_MATMAS01 does); this function module uses a global variable FLAG_BAPI_CALL to indicate the non-dialog processing. So if you feel adventurous you could evaluate this flag in your coding.</li>
</ul>
Change pointer won't really do you any good if your functionality is already working without them apart from the trigger. Even if you write change pointers, you still have to implement the trigger functionality, so essentially back to square one...
In general another good option is often to use workflow events that are already triggered. I.e. in your case business object BUS1001006 almost does the trick. It has events for <em>ViewCreated</em> and <em>Created</em>, but unfortunately lacks events for material updates (and I didn't see any other appropriate object that has it and a quick trace while updating a material didn't fire any appropriate event).
Cheers, harald