topic Re: IDOC data inconsistency in Application Development and Automation Discussions

IDOC data inconsistency

Former Member — Tue, 20 May 2014 15:26:20 GMT

Hi experts,

i have an issue that there is data inconsistency in IDOC( delivery address created with respect to PLANT instead of STORAGE LOCATION).

now i want to rectify the issue by checking the mapping in the program , the IDOC is created by standard procude ( thorough ME21N).

can anybody tell me how can i find the program/interface name where the logic is written for filed mapping for IDOC

IDOC type ORDERS05

Message type ORDERS

Thanks

Niru

Re: IDOC data inconsistency

Former Member — Tue, 20 May 2014 19:06:19 GMT

Hi Niru,

You can use the transactions like WE19 ,BD73 , WE15 to debug the IDoc if Idoc numbers r known. Or else use partner profile transaction WE20 to find process code. From the process code identify the function module attached to it using transaction WE41 or WE40

Thanks & Regards,

Arun

Re: IDOC data inconsistency

Mohamed_Mukhtar — Wed, 21 May 2014 04:07:30 GMT

Hello Niru,

Please check the below fields in delivery address tab in purchase order line item

Address

Customer

Vendor.

The above fileds must be same for all purchase order items to pick storage location address. If any change in above fields then plant address will be picked in idoc.

To find out how this address is being picked, you need to debug outbound idoc creation.

To debug outbound idoc please search SCN with keyword 'debug outbound idoc' .

Thanks

Re: IDOC data inconsistency

Former Member — Fri, 23 May 2014 13:06:31 GMT

Hi ,

I have put a breakpoint inside the FM IDOC_OUTPUT_ORDERS and try to reprocess the idoc from WE19, but the control not stoped at Break point .

assume below is validation inside the FM makng the issue.

IF pekko-werks NE space AND

pekko-kunnr EQ space AND

pekko-emlif EQ space AND

pekko-adrn2 EQ space AND

pekko-adrnr EQ space.

CLEAR int_edidd.

CLEAR e1edka1.

int_edidd-segnam = 'E1EDKA1'.

e1edka1-parvw = 'WE'.

*- if Third party order, send customer number of first S.O. item -----*

PERFORM fill_kunnr_header.

e1edka1-lifnr = pekko-werks.

lv_prog = 'SAPLEINM'.

PERFORM fill_e1edka1_we_gln IN PROGRAM (lv_prog) IF FOUND.

PERFORM edka1_fuellen.

* Call Method PROCESS_IDOC_SEGMENT (BADI MM_EDI_ORDERS_OUT)

PERFORM badi_process_idoc_segment.

* Call Customer Function 002 (enhancement MM06E001)

PERFORM customer_function.

* Außenhandelsdaten

* Partnerzusatz für IMPINV01 ab Release 4.0A z.B. Zoll-ID-Nummer

IF control_record_out-idoctp(6) EQ 'IMPINV'.

PERFORM fill_e1edkaz.

ENDIF.

*- Manuelle Anlieferungsanschrift, wenn in allen Positionen gleich ----

IF pekko-adrnr NE space AND

pekko-kunnr EQ space.

CLEAR int_edidd.

CLEAR e1edka1.

int_edidd-segnam = 'E1EDKA1'.

can you please tell me how can control stoped at this code?

regards

niru

Re: IDOC data inconsistency

Former Member — Fri, 23 May 2014 15:19:44 GMT

Hi Experts,

Any idea on this?

regards

niru

Re: IDOC data inconsistency

nabheetscn — Fri, 23 May 2014 15:34:26 GMT

Hi Niru

Your idoc is triggered via output type messages I hope. Go to messages choose a processed output type and repeat output. Choose the new output type-further data. Choose option send via periodic job instead of immediately and save. Go to se38 rsnast00 program execute. Enter details and execute and it will stop at break point

Nabheet

Re: IDOC data inconsistency

Former Member — Fri, 23 May 2014 16:23:15 GMT

Hi Niru.

As far as I know, the WE19 don´t reprocess FM IDOC_OUTPUT_*.

The FM's IDOC_OUTPUT_*. fill the IDOC Type (the process that you do manually in WE19).

For reprocessing, I suggest you find out which message the sales and distribution is configured in your environment and what routines are processed. For this:

Customizing SD and MM Output Control to Create IDocs

How to trigger a sales order Idoc ORDERS05 when ever we create or change it

Maintain Distribution Model and Distribute Views

Hope this helps .

Regards.

Douglas Santos

Re: IDOC data inconsistency

Former Member — Fri, 24 Jul 2015 14:51:06 GMT

This message was moderated.