Import Security filing while the STO is in Export level for Compliance

[Former Member]

Hi Experts,

Need some inputs on issues that I am facing with regards to Import Security filing for US.

1) We have been using Stock transport orders for Export level Compliance check unlike the standard way of screening it at Import level.

2) So, now when we try to create Pre-declarations with respect to PO. It doesn't work because the PO is already considered at Application Level SD0A for Export check. And the work list to create Pre-declaration is actually looking for PO# with Application level MM0A. Which makes sense to me. When you are working for Imports you will need the PO to be available at Import Application level MM0A.

3) We can also create ISF Pre-declarations with respect to Inbound delivery. But for us, Inbound delivery will bit late in the cycle. Inbound deliveries are created after PGI of Outbound delivery. ISF declaring that time will be late. We wanted to do it a bit earlier.

Just wanted to know, if anyone had been in the same situation and managed to find out a solution. I am trying to look for a workaround, if not will go for complete custom development.

Please do let me know if you feel we are not in the right track.

Thanks in advance for your inputs.

Regards

Dhilipan

[mouaz_benredjeb · Accepted solution]

Hello Dhilipan,

I had a look in the system and unfrotunately it seems that there is no BADI to influence the WL e.g. to add entries in the WL depending on some custom coding.

May be what you can do is to create an enhancement spot at the end of the one of the following objects where you'll be able to add the custom code that will add your "SD0A PO" in the WL:

- Program /SAPSLL/LCIBD_INTACTF04 / End of "form cibd_by_po_select"

OR

- End of FM "/SAPSLL/CIBD_GET_DATA"

I was thinking aswell if instead of mapping your PO against SD0A that perhpas you could map it against a "ZSD0A" and "MM0A"... but this a long shot and anyhow it will require some developments and may lead to new unforseen side effects...

Regards.

Mouaz BEN REDJEB

[Former Member · Accepted solution]

Hi Mouaz,

Thanks a lot. My last option was to go for an enhancement. Appreciate your help in suggesting the enhancement spots. I'll check these.

Thanks for your help as always.

Regards

Dhilipan

[former_member215181]

Hi Dhilipan,

From what you say, I assume that you're talking about a cross-border Stock Transport order (e.g. NLCC), and that you currently have an "own development" to spoof transfer with Application Level 'SD0A' instead of 'MM0A', so that you can carry out compliance checks for the supplying company's Export process.  If that's not correct, then please put me right.

My suggestion would be to modify your development so that the STO's are transferred with 'SD0A' AND 'MM0A'.  That would be valid, since the single order fulfills roles for both ends of the journey.  It would be such a shame to re-develop the standard Import side, since it works perfectly well.

I understand your point about timing of the Inbound Delivery.  Would it be possible to tailor your system to create the IBD as soon as picking is complete in the OBD?  I assume that the IBD creation is controlled by an Output Requirement that is checking the Goods Movement status, and it should be quite straightforward to create an alternative Requirement to check the Picking status instead.  In that way, subject to agreement on process, you could have an earlier IBD, still with the full data set.

Regards,
Dave

[Former Member]

Hi Dave,

Thanks a lot. I was planning to replicate in 2 levels. But was just worried if I try to get the status of Customs document from ECC might give me some problem.

I'll try this and confirm back. Thanks a lot.

Regards

Dhilipan

[former_member215181]

Hi Dhilipan,

If you do try to replicate at 2 levels, you might want to code the enhancement BAdIs (e.g. /SAPSLL/IFEX_SD0A_R3) to prefix or suffix the document number, just to avoid any overlap between the 2 replicates in GTS.  Neither the header or item reference table (/SAPSLL/CORREF, /LEGREF) has a unique index on the feeder system document number, but you might get confusion when specifying the ERP document number in GTS if 2 replicates share the same number.

You'll need to try it and see, but it's potentially a simple solution using mostly standard functionality.  I hope it works.

Regards,

Dave

[Former Member]

Hello Dhilipan

Can you share what solution approach you took to overcome your problem.

Thanks a lot.

[Former Member]

Hi Jamali,

We are proceeding with enhancement. Instead of depending on the IBD or PO. We will have enhancement to create a CBOL in GTS and with respect to CBOL and PO, we will create Pre-declaration.

Regards

Dhilipan