GTS-EWM-NCTS process

[Former Member]

Hi Experts,

I have no experience with EWM, though i have worked on the ERP Warehouse management. EWM seems to be bit difficult for me

I am trying to setup ECC-EWM-GTS integration for a simple transit procedure with Safekeeping.

• I create my IBD in ECC, enter the T1 and MRN#, I see a Transit being created in GTS by the normal process and the same IBD gets distributed to EWM.
• In EWM, I see the same T1 and MRN from ECC is available in EWM. I setup the "in yard" status and see another Transit being created in GTS with the same IBD#.

• Without T1 and MRN on my IBD in ECC, no Transit in GTS.
• Now when I key in T1/MRN in EWM and set "In yard" status for my IBD in EWM, I can find a Transit in GTS. So only 1 Transit in GTS/

So my question is on the usual process

1) Should we stop keying in the T1 and MRN in ECC and do it only in EWM?

2) I thought when I setup "in yard" status in EWM for the same MRN that was keyed in ECC, system will still check if there is a Transit available already with the same MRN# before creating a new transit in GTS

Can someone help me with the standard procedure please?

Thanks

Dhilipan

[mouaz_benredjeb · Accepted solution]

Hello Dhilipan,

In the few projects where I have participated to implement NCTS, I never encountered the case where EWM was used.

So I am trying here to answer your questions based on my proper experience even though as stated above I never encountered the case where EWM was involved.

I will first start by answering your 2nd question . Indeed, GTS should "aggregate" the different IBDs that share the same T1/MRN number. In other words, you should have a unique Transit declaration in GTS for multiple IBD with the same Tx/MRN number.

From my experience, the only case were the aggregation did not work was when a huge number of IBDs was updated simulatenously in ECC with the same MRN number (for one customer, we had sometimes 50 IBDs updated with the same MRN number through a Z program in a single shot). In such cases, GTS did not cope with the volume of data received and started to create multiple Transit documents instead of aggregating them based on the MRN.

In the test case you have described in your post, what was the status of the 1st Transit document (created by the IBD) when the 2nd Transit document (created by EWM) was created ?

Moving now to your first question, if you/we don't find the reason why the IBDs are not aggregated, then indeed "may be" you will have to enter the MRN only in EWM, "may be". In my opinion, part of the answer is not technical but rather practical: The MRN has to be entered manually into the system. Does the reception department have access/authorizations/knowledge to do it directly in EWM ???

Regards.

Mouaz BEN REDJEB

[Former Member · Accepted solution]

Hi Mouaz,

Thanks. Nice to hear from your after a long time.

I had the same opinion on IBDs and Transit relationship.

SAP is a small world . I had opportunity to check the same program that you are describing to update MRN for multiple IBDs. Indeed its because of huge volumes and when the RFC queues start processing simultaneously it creates multiple transits. Setting up delay statements in the custom transaction doesn't help always when there are too many IBDs being processed simultaneously. I think we must ensure there is a transit created for the 1st IBD before processing with the MRN update for 2nd one( Just after the 1st one is updated). Not for all IBDs though. Just between 1st and 2nd one.

Regarding Transit status:

When the T1 and MRN was updated in the IBD in ECC, we had a transit created ready and available in GTS. However arrival notification was not sent.

In EWM, status for the same IBD was set to "In yard"- A new transit got created in GTS with the same MRN which was shocking for me.

Few minutes back when i checked(which is 4 hours later to creation of the transit by EWM). I see a change log by the RFC user from EWM system had canceled the Transit declaration.

Could be someone had removed the delivery assignment in EWM. I need to check and confirm this.

My expectation is

1) If I update the T1 and MRN in ECC, let the transit be created in GTS. But when I set the IBD "in yard" status in EWM, it should check whether there is a transit available already for the same MRN before creation- I'll execute some more tests and confirm this.

Thanks for your inputs as always

Regards

Dhilipan

[mouaz_benredjeb · Accepted solution]

Hi Dhilipan,

I had a look at the piece of code where the aggregation of MRN is taking place in GTS.

I have seen 2 things that could explain your issue:

(1) Other than the Tx/MRN number, the aggregation logic takes into account other things like the Logical system. So may be the aggregation is not working in your case because ECC and EWM are not sharing the same Logical system ?

(2) IBDs transferred to GTS are mapped in table /SAPSLL/CORREF. Please try to have a look at this table. If you find 2 entries with the same IBD number then may be there is a mismatch in one of the "secondary" fields of the table that could explain your issue (e.g. same IBD number but different Object type, Reference Application, etc...)

Regards.

Mouaz BEN REDJEB

[former_member215181 · Accepted solution]

Hi Dhilipan,

Apologies for a late response here (holidays)...

To address the issue with the RFC, take a look at Note 1875119, created for one of my projects some time ago.  It allows the use of qRFC instead of the usual tRFC, and makes a world of difference when trying to transfer large numbers of Deliveries together.

Obviously that Note is for an ERP feeder system, but maybe SAP would also provide the same functionality for EWM (you'd need to create an Incident to make that request).

Regards,

Dave

[Former Member · Accepted solution]

Hi Mouaz,

Thanks for your help

1) I think it was just the timing issue to have multiple transits for same MRN. I tried with a fresh flow with all 3 systems together. There is just one transit created even after I set in yard status for my IBD in EWM. So, multiple transit issue is just a very rare case.

2) I see a difference in the CORREF table update with respect to the QALREF. Whenever an IBD is replicated from EWM, the QALREF is set as EXTIDF and not as EXTID.

This is leading me to another issue for which I am working with SAP

So, when my transit is created from EWM system directly. Which means I enter the T1 and MRN in EWM and set the status as "In yard"- A transit gets created in GTS. This transit is created under QALREF- EXTIDF in CORREF table.

When we get in the Transit- Display Inbound activities transaction and try to find out the Transit with the Inbound delivery number. It doesn't show my transit declaration because the standard code is considering the QALREF to be "EXTID" always when we mention the feeder system data.

I'll keep you posted if I get any response from SAP.

Thanks

Dhilipan

[Former Member · Accepted solution]

Hi Dave,

Thanks a lot. We've done this change already in our ECC system. As you said, we may have to use similar logic in EWM if we come across the same issue in future.

Thanks

Dhilipan

[former_member215181 · Accepted solution]

Hi Dhilipan,

That's strange, since (as far as I can see) the standard code is correct.

If you look into Function Module /SAPSLL/MM0B_6800_TIBD_MAP_R3 at line 24, you'll see:

     es_api_tibd-qual_refno    = gc_qalref-external_number.

And double-clicking the constant shows:

   constants:

     begin of gc_qalref,
       external_number         type char6      value 'EXTID',

       external_number_flow    type char6      value 'EXTIDF',

     end of gc_qalref.

Are you sure you're not changing the value in the BAdI or anywhere else?

Regards,

Dave

[Former Member · Accepted solution]

Hi Dave,

This works with EXTID when my transit is replicated from ECC. In my case, I am facing issues when the transit is being replicated from EWM system.

I've not checked the code in EWM yet. To be frank, no clue on which code to check in EWM

Regards

Dhilipan