EDI-Idoc Scenario - Any remarks and suggestions plz!!!

[Former Member]

Hello guys,

I want your opinion on the following EDI-Idoc scenario:

An external system sends me a flat file with master data in a non-idoc format and I want to post these data to my R/3 using as much as possible the standard procedure of the inbound EDI-Idoc interface.

Let say I already have the Idoc type and message type that I want to use.

1. I will create a dummy File port. I know that this has no actual meaning since there is no actual communication with the external system but I will do it for completeness reasons.

2. I will also create a dummy partner profile of type LS assigning to inbound parameters the Idoc message type and a Z* function module as a process code.

3. I will develop a custom program that will transform the flat files into Idocs of the specified type and store them into tables IDIDC and IDID4 as ready to be processed.

4. Then I will schedule a standard program (any suggestions of which program?) to process them. I quess that this program will call the process code in order to process the data and post them to R/3. Or this is not the case?

What do you think about this scenario? Is it applicable or am I missing something?

And what about error handling? Will the system produce by itself a workflow task to inform the agents I will assign to the partner profile or should I do something about it?

Any thoughts, corrections and suggestions will be highly apreciated...

Thank u very much

Amanda

[Former Member]

Hi Amanda

Can't you straightway right a program which will read the non -idoc file and then call youridoc posting program by filling the segment.

Best Regards

Naresh

[former_member194669]

Hi,

My suggestion:

Instead of processing of flat files why don't go for a RFC, that can be triggered from

the legacy directly, and get file data into RFC then within the RFC populate all EDIDC, and EDDiD structures. abd call for your inbound function module.

Error handling i think no need for workflow. , you can send mails to concerned people if IDoc gone to error thru your custom RFC.

aRs

[Former Member]

Hi,

You have two options to fulfil your requirement.

1. If you do not have any middleware to map the flat file to the IDOC then, the approch you are taking is correct.

2. If you have middleware, then map the incoming flat file into the IDOC and post the IDOC in standard way.

If you do not have middleware system then the solution you have mentioned will work fine but there are few corrections.

<b>>1.</b> I will create a dummy File port. I know that this has no actual meaning since

<b>></b>there is no actual communication with the external system but I will do it for

<b>></b>completeness reasons.

<b>No need to create a dummy file port</b> or any dummy port for this inbound interface.

<b>>2</b>. I will also create a dummy partner profile of type LS assigning to inbound

<b>></b>parameters the Idoc message type and a Z* function module as a process code.

You have to create a dummy partner profile for partner type LS. But you only need assign it message type and process code. No need to create a dummy process code, assign Z FM and use this process code. Just use standard process code. For example, if the interface is for inbound invoice, use message type as INVOIC and process code as INVL.

<b>>3.</b> I will develop a custom program that will transform the flat files into Idocs of

<b>></b>the specified type and store them into tables IDIDC and IDID4 as ready to be

<b>></b>processed.

Yes, you will have to create a custom program which will read the flat file and fill the data into appropriate IDOC structure. But i suggest that you schedule this program itself for let's every 10 or 15 mins. What this program does is,

- Read the specified unix directory if new file exist. ( "INBOUND directory" )

- If new file exist then, convert this file in to IDOC you want

- Write the idoc into database ( FM <b>IDOC_INBOUND_WRITE_TO_DB</b> )

- Above FM will return the new idoc number

- Use this IDOC document number and call a program to post the IDOC. This program would be <b>RBDAPP01</b> ( this is the asnwer to your fourth point - which program? )

- If the application document posted, copy the flat file from "INBOUND" directory to "ARCHIEVE" directory and delete the file from "INBOUND" directory. In interface based on flat file, the right practice is to move the processed file to archieve directory and delete the file from the "original".

<b>>4.</b> Then I will schedule a standard program (any suggestions of which program?)

<b>></b>to process them. I quess that this program will call the process code in order to

<b>></b>process the data and post them to R/3. Or this is not the case?

I already gave answer to this question in point-3 above. You will be using the report <b>RBDAPP01</b> to post the idoc.

The syntax would be:

SUBMIT rbdapp01 EXPORTING LIST TO MEMORY 
                      WITH SELECTION-TABLE seltab AND RETURN.

you can check the F1 help on 'SUBMIT' command for information on how this statement works.

I hope i clarify most of your doubts.

Let me know if you have any question.

Regards,

RS

[Former Member]

I am very sorry for the delayed response RS...

I was away for a while

Thank u very much for your answer, it was very clear and helpful.

Amanda