Object type definition for an outbound IDoc

[yan3]

Hi,

We are using an output sent from several docs (SO, PO, Outbound delivery and inbound one), output that creates an IDoc which transmits some info to the transportation team.

Those IDocs can be seen in the so-called 'GOS' or Services for Object, window that can either be called when in a doc via the 'System' menu -> Services for Object and 'Display relationships' or be defaulted with the PUID 'SD_SWU_ACTIVE' value X in SU3 and the relationships submenu in that window.

And this works well for the SO, for the PO, for the OBD, but not for the inbound one.

I understood why (see that post), the issue is caused by the object type created by the IDoc in table SRRELROLES.

The object type for the IDoc created for the SO is BUS2032, the one for the PO IDoc is BUS2012, the one for the OBD IDoc is LIKP.

And the one for the IBD IDoc is LIKP too, what is causing the issue.

I copied in SRRELROLES table the line for one IBD IDoc and changed the object type to BUS2015, and the IDoc is now visible in the GOS window.

I tried to find where the object type could be defined for a processing FM, an IDoc type, a message function and a message variant (to not negatively impact the working behaviour for the OBD IDoc), but I wasn't successful (I thought having found the right thing with WE57, but that didn't work).

Any idea how I could define the object type for my IDoc, message function and message variant?

Maybe I missed something 'before' WE57.

Thanks for your help.

BR

Yan

[Ryan-Crosby]

It's not clear what you are describing in totality in your post, but best guess is you are maybe referring to WE42.

[Ryan-Crosby]

The object type relation comes from the configuration in TBD14 and is read during execution in program RSNASTED.  If an object is set to LIKP it should not be changed.  The mechanism you are describing is suspect since you are talking about sending out an inbound delivery, but you could create a Z message type with the relation you seek.

Regards,

Ryan Crosby

[yan3]

Hi still (though it seems its deprec iated to use it nowadays), as you might have read, the object changes according to the doc type 'from' where the IDoc is sent out (for the IDoc created for the SO is BUS2032, the one for the PO IDoc is BUS2012, the one for the OBD IDoc is LIKP), but not when the IDoc is sent out from an IBD.

[yan3]

Hi, I 'misread' my partner profiles, the message type is in fact a different one for the PO and for the SO... nevertheless, I don't get why the WE57 finetuning I did for a specific variant message and function for my processing FM, as offered by SAP, isn't working. BR Yan

[Ryan-Crosby]

@yan3 because it's based on the message type as I had already noted in the answer as a read on table TBD14. Review the table in SE16 for your message type and you will find 'LIKP'.

[yan3]

Hi, I understood, but why isn't WE57 helping?

[Ryan-Crosby]

@yan3 because TBD14 isn't part of the view that you see in WE57.

[yan3]

Hi, for the outbound process you mean, because for the inbound one, WE57 is helping changing the object I believe.

[Ryan-Crosby]

@yan3 yes but in your description you indicated you were sending this object not receiving it.

[yan3]

Yes, I'm sending it, then it's just that WE57 offers a choice (outbound or inbound) that in reality doesn't exist? Or maybe I got it wrong (which is still possible, even after many many years in SAP).

[Ryan-Crosby]

@yan3 yes, because as I previously stated the object type that is derived during processing in program RSNASTED is from table TBD14, which you are not maintaining when you make any adjustments in WE57. No adjustment to TBD14 = default value of LIKP.

[yan3]

Hi, sorry @Ryan-Crosby, was pretty busy the previous days (and last Monday was a French bank holiday ;)) ; oki, I thought that WE57 was playing a role there, as the object type was defined... since I don't see any user-exit or enhancement spot in the RSNASTED form where the object type is determined (FORM INITIALIZE_WORKFLOW ), I don't see any other possibility than copying the RSNASTED, put in the form where the object type is determined a kind of call to the EDIFCT table to get the object and set the resulting specific program in the processing routines for the output, or do you think of another possibility?