GTS - Exclude UoM from Commodity Code Transfer

[Former Member]

We are looking into excluding the commodity code unit of measure from the commodity code transfer process from GTS to ECC.  In our ECC the system is requiring a conversion from the base unit of measure in ECC to the commodity code unit of measure coming in with the tariff number from GTS. 

Does anyone have experience excluding this from the transfer?  Should it be done on the GTS side or ECC side?  What kind of issues did you encounter when you made this customization?

Thank you,

Alison

[former_member215181 · Accepted solution]

Hi Alison,

Despite my earlier recommendations to make full and proper use of the UoM; if you really want not to use it, then you can do so quite easily in GTS.

Code BAdI /SAPSLL/STAWN_RETRANSFER_R3, Method LLNS_RETRANSFER_RFC_R3 to clear the UoM field, something like this:

  FIELD-SYMBOLS: <fs_swn> TYPE /sapsll/api_llns_swn_prot_s.

* Clear the Unit of Measure for the transfer

  LOOP AT ct_llns_swn_prot ASSIGNING <fs_swn>.

    CLEAR <fs_swn>-spec_uom.

  ENDLOOP.

There shouldn't be any adverse impact in the ERP system - it will be just as if you've made a manual entry into T604 and left the UoM field blank.

Regards,

Dave

[Former Member · Accepted solution]

Hello Dave,

We have done this clearing of UOM from transferring to ECC. However, there is another problem, if we do not have the internal/external UOM maintained the transfer job cancels. We did not see the need to maintain the internal/external UOM, since we are clearing this from transferring to GTS.

Whenever, a product is classified with a classification that does not have the internal/external UOM maintained, the job dumps.

Any suggestions?

Thanks,

Padma

[former_member215181 · Accepted solution]

Hi Padma,

Sorry for the delay in replying (on holiday).

Yes, I can see the relevant code that is causing your problem.  The developer really wants to make sure that you don't transfer any bad data to the feeder system.  That makes sense, but I share your view that an individual classification failure shouldn't stop the whole transfer job (only the transfer of that particular Commodity Code or Classification).  Perhaps you could appeal that point through an OSS Incident?

Otherwise, and preferably in any case, you should maintain the UoM schema correctly in GTS.

Regards,

Dave

[Former Member · Accepted solution]

Hi Padma,

I have this put in Idea space already. You can vote for this

Complete failure of Commodity code retransfer report when the Commodity code carries UoM missing map...

For my project, I had to write a custom logic in the implicit enhancement to change this message as an Information message instead of error.

And my case was not to skip UoM, but not to dump if there is no internal UoM mapping. So, i had changed this to information message and triggered an email notification to our users saying there is a new external UoM which is not mapped in the system. This way, they can have this setup in the system for future use.

Thanks

Dhilipan

[Former Member · Accepted solution]

Dave, thank you for your help!  We are doing some analysis on this before we update the BADI.  The purpose of the analysis is to see how many products have a supplementary unit of measure assigned to them in GTS.

Is there a GTS table that shows the supplementary units of measure assigned to a material for with a tariff number?  When I do an F1 on the field I get /SAPSLL/PRODUCT_LLNS_DYNP_S, but that is not a table in SE16. 

Thank you,

Alison

[former_member215181 · Accepted solution]

Hi Alison,

No, it's the Tariff Codes that have the supplementary units, not the Products.  So you would need to create a table join (/SAPSLL/PNTPR, /SAPSLL/PRCTS and /SAPSLL/CTSNUM) to find the "affected" Products.

Regards,

Dave