NEED DEFINITIONS

[Former Member]

HI

I need Interview point of definitions for Cross Application Concepts...so, can any of you plz give me a brief explination about

1 .PROCESS CODE

2. MESSAGE TYPE

3. OUTPUT TYPES

4. customer distribution model.

what is these are.. and what is the purpose of these..

Thanks

babu

[Former Member]

Hi,

these all are IDOC/ALE related terms. Just search for IDOC material and you will get lots of link on SDN.

Regards,

Atish

[Former Member]

Hi

Message Type/Output type: both are same with respect to IDOC /ALE terminology

Which determines the various Processes associated with an application document

A selection program exists fro each message Type

A message type is attached to a IDoc type

Process Code: Is the one which always points to a selection Program (Function Module)

Customer Distribution Model: Distributing the data among the customer in ALE scenarios

See the Tcodes BD10,11,12,13, 14 etc

Reward if useful

Anji

[Former Member]

hi,

<b><i>Process code:</i></b> is nothing but a triggering function module when idoc data reaches to target system.

<b><i>message type:</i></b> is used to ensure what/ which type of data is transering from source to target.

<b><i>customer distribution model:</i></b> is used to define and set the source and target systems for transefering the data using logical systems & cleint.

<b><i>Reward points if useful</i></b>

Chandra

[Former Member]

Hi Babu,

<b>Processing Code</b>

The processing code is a logical name that determines the processing routine. This points usually to a function module, but the processing routine can also be a

workflow or an event. The use of a logical processing code makes it easy to modify the processing routine for a series of partner profiles at once.

<b>The logical processing code determines the algorithm in R/3 used to process the IDoc</b>

The processing code is a pointer to an algorithm to process an IDoc. It is used to allow more

flexibility in assigning the processing function to an IDoc message.

The processing code is a logical name for the algorithm used to process the IDoc.

The processing code points itself to a method or function, which is capable of

processing the IDoc data.

A processing code can point to an SAP predefined or a self-written business object or function module as long as they comply with certain interface standards.

<b>Allows changing the algorithm easily</b>

The processing codes allow you to easily change the processing algorithm. Because the process code can be used for more than one partner profile, the algorithm can be easily changed for every concerned IDoc.

<b>The processing code defines a method or function to process an IDoc</b>

The IDoc engine will call a function module or a business object which is expected

to perform the application processing for the received IDoc data. The function

module must provide exactly the interface parameters which are needed to call it

from the IDoc engine.<b></b>

<b>Message Type</b>

The message type defines the semantic context of an IDoc. The message type tells the processing routines, how the message has to be interpreted.

The same IDoc data can be sent with different message types. E.g. The same IDoc structure which is used for a purchase order can also be used for transmitting a sales order. Imagine the situation that you receive a sales order from your clients and in addition you receive copies of sales orders sent by an subsidiary of your company.

The message type defines the semantic context of an IDoc. The message type tells the receiverhow the message has to be interpreted.

The term message is commonly used in communication, be it EDI or

telecommunication. Any stream of data sent to a receiver with well-defined

information in itis known as a message. EDIFACT, ANSI/X.12, XML and others

use message the same way.

Unfortunately, the term message is used in many contexts other than EDI as well.

Even R/3 uses the word message for the internal communication between

applications. While this is totally OK from the abstract point of view of data

modelling, it may sometimes cause confusion if it is unclear whether we are

referring to IDoc messages or internal messages.

The specification of the message type along with the sent IDoc package is especially important when the physical IDoc type (the data structure of the IDoc file) is used for different purposes.

A classical ambiguity arises in communication with customs via EDI. They usually

set up a universal file format for an arbitrary kind of declaration, e.g. Intrastat,

Extrastat, Export declarations, monthly reports etc. Depending on the message type, only applicable fields are filled with valid data. The message type tells the receiver which fields are of interest at all.