ALE CODING WITH DISTRIBUTING OF CUSTOMER DATA FROM HR TO FI SYSTEM

Applies To:

ABAP

Summary

A business scenario and technical solution in detail to depict the customizing data distribution process through ALE along with some extra light on HR documentation.

By: Samasivarao

Date: 08 Jan 2006

Business Requirements

Standard tables, Custom table with HR-documentation maintained in HR system
Receiving SAP FI system make use of Master data Distributed from HR system, in developing a new custom application

Technical Solution

Data Maintenance of standard tables in the HR systems
Master Data distributed from HR system to FI system by ALE process
A new custom table created in HR and FI System
HR documentation maintained in HR system
Custom table data distributed from HR to FI system via ALE customizing data distribution

Process in Detail

Custom Tables

Custom tables created in HR and FI system with required fields. For Example, we create a custom table ZTIME to maintain time IDs.

Also we create a field to maintain Time ID documentation in the table.

Custom tables created in SE11 transaction with required fields, data elements, and domain. We just concentrate on HR documentation.

Create a new field INFO in the custom table ZTIME with following attributes : Data type : CHAR

Data length: 1

Description : Time ID Documentation

Save; activate the table with extended table maintenance.

(Funk. Group ZTIME_EXT, Screen 0001)

INFO ZINF CHAR 1 0 Time id Documentation

We need to design the ZTIME table maintenance screen for documentation field.

· Go to transaction se80.

· Enter Function group : ZTIME_EXT

· Select screen 0001.

· Go to Screen painter.

· Create a Pushbutton with following attributes :

EI type: Pushbutton

Name : DOCU_BUTTON

With Icon: X

Fctcode: 0%%%

Output field: X

Create a new PBO module in Screen 0001 flow logic :

MODULE HRDOC_LIST OUTPUT

IF STATUS-ACTION EQ AENDERN

OR STATUS-ACTION EQ ANZEIGEN.

DOCU_BUTTON = ICON_INFORMATION.

LOOP AT SCREEN.

IF SCREEN-NAME = 'DOCU_BUTTON'.

SCREEN-ACTIVE = 1.

SCREEN-INPUT = 1.

MODIFY SCREEN.

ENDIF.

ENDLOOP.

ELSE.

CLEAR DOCU_BUTTON.

LOOP AT SCREEN.

IF SCREEN-NAME EQ 'DOCU_BUTTON'.

SCREEN-INPUT = '0'.

SCREEN-ACTIVE = '0'.

MODIFY SCREEN.

ENDIF.

ENDLOOP.

ENDIF.

ENDMODULE.

Icon with ‘INFORMATION’ symbol will be passed at runtime.

C. Till now Custom table and a field for documentation is created. Now we need to write flow-logic modules in screen 0001 to invoke HR documentation. (Similar functionality of PDSY transaction).

Create a Time id documentation class ‘ZTIME” in PDSY transaction with required attributes :

Document class : ZTIME

Obj.documentation : X

Client-specific: X

Object table: ZTIME

2. Create a PAI module ZHRDSYS_DOCU_EDIT_FUNX with following code.

CALL FUNCTION 'HRDSYS_VIEW_DOCU_EDIT'

EXPORTING

STATUS_ACTION = STATUS-ACTION

OFIELD1 = 'TIMEID'

OTYPE = 'ZTIME'

NEXTLINE = NEXTLINE

TABLES

EXTRACT = EXTRACT

TOTAL = TOTAL

X_NAMTAB = X_NAMTAB

CHANGING

FUNCTION = FUNCTION

XACTION =

ACTION =

EXCEPTIONS

FIELDNAME_ERROR = 1

INDEX_ERROR = 2

OTHERS = 3.

IF SY-SUBRC <> 0.

* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO

* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.

D. Now custom table ZTIME is ready to maintain Timeid attributes and Documentation:

Go to transaction SM30.

Enter table name: ZTIME

Click on Information button to maintain documentation as follows:

Transport Entries of Standard Custom Tables

Whenever data is maintained in standard and custom table in a development client, a transport request is created.

There is no problem for the transport entries of standard table.

When we create a transport request for custom table, only table contents show up in the request. No objects related to Time ID documentation stored up.

We need to add some extra modules in the extended table maintenance.

Go to transaction code SE11.
Go to extended table maintenance screen of ZTIME.
Go to Maintenance Events and maintain the following modules and events.

01 F_HRDSYS_SAVE_01

02 F_HRDSYS_SAVE_02

11 F_HRDSYS_TRANSPORT

Maintain these modules in subroutine of function group ZTIME_EXT.

FORM F_HRDSYS_SAVE_01.

CALL FUNCTION 'HRDSYS_VIEW_SAVE_01'

EXPORTING

OFIELD1 = 'TIMEID'

ACTION =

TABLES

TOTAL = TOTAL

X_NAMTAB = X_NAMTAB

HRDSYS_ACTIONS = HRDSYS_ACTIONS

EXCEPTIONS

FIELDNAME_ERROR = 0

OTHERS = 0.

ENDFORM.

FORM F_HRDSYS_SAVE_02.

CALL FUNCTION 'HRDSYS_VIEW_SAVE_02'

EXPORTING

OTYPE = 'TIMEID'

CORR_NBR = -CORR_NBR

TABLES

HRDSYS_ACTIONS = HRDSYS_ACTIONS.

ENDFORM. “f_hrdsys_save

FORM F_HRDSYS_TRANSPORT.

CALL FUNCTION 'HRDSYS_VIEW_TRANSPORT'

EXPORTING

OTYPE = 'ZTIME'

OFIELD1 = 'TIMEID'

XMARK =

CORR_ACTION = CORR_ACTION

STATUS_ACTION = STATUS-ACTION

E071K = E071K

TABLES

X_NAMTAB = X_NAMTAB

CORR_KEYTAB = CORR_KEYTAB

EXTRACT = EXTRACT

EXCEPTIONS

FIELDNAME_ERROR = 0

OTHERS = 0.

ENDFORM. “f_hrdsys_transport

Addition of the above subroutines allows creating a transport entry for custom table contents along with its documentation.

Transport request contains following objects:

ALE Distribution of Customizing Data from HR to FI Systems

Design a ALE model distribution system as follows:

Go to Transaction SALE

Navigate to step -> Synchronization of customizing data ->

Maintain Distribution groups.

1 .Create a new distribution group ZTIME_DG with following customizing objects:

Actually LODC and PHDC are logical objects related to Time ID documentation.

To include PHDC in the distribution group list, need to add up one more setting:

Go to transaction SOBJ.

Change the transport attributes of PHDC object to ‘Manual Transport’ and Save.

Come back to distribution group list and save the entries.

All entries will be saved successfully.

Distribute the distribution group to receiving system.

Create a ALE model system with sending system as HR system and receiving system as FI . Add Message type CONDA2 to distribute the customizing data.

To CONDA2 message type, add the distribution group ZTIME_DG. Generate Partner profiles and distribute the ALE model.

Now ALE model is ready for distribution. Whenever master data maintained in standard and custom tables, transport request will be created in the HR system.

From HR system, Run a stand-alone program RBDCUS44 (Tran. Code: BDXE)

This program will collect all the transport entries related to customizing objects modeled in ALE process and transport the same to receiving system transport buffer.

Receiving system is ready to import the transport requests from the buffer via transaction BDXD.

These stand-alone programs can be scheduled in the background mode on timely basis.

At last master data of standard and custom table with time ID documentation is available in the receiving system.

It is time for the receiving FI system to make use of data to build a new application.

Disclaimer & Liability Notice

This document may discuss sample coding, which does not include official interfaces and therefore is not supported. Changes made based on this information are not supported and can be overwritten during an upgrade.

SAP will not be held liable for any damages caused by using or misusing of the code and methods suggested here, and anyone using these methods, is doing it under his/her own responsibility.

SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of the technical article, including any liability resulting from incompatibility between the content of the technical article and the materials and services offered by SAP. You agree that you will not hold SAP responsible or liable with respect to the content of the Technical Article or seek to do so.

ALE STEP BY STEP PROCEDURE WITH TCODES

Step 1 – Analyses Hierarchy Levels:

Analyses the data relationships being processed in the interface. Define the appropriate hierarchical Parent-to-Child relationships.

Navigate to transaction code WEDI
Transaction WEDI displays the IDOC main menu. This allows navigation around the various development and control areas to create a customized IDOC.

Step 2 – Create a new segment:
via wedi : Development - IDOC Segments or Transaction code WE31.
• Enter segment name and click on Create.
Name of theÞthe segment type must start with Z1, and have a maximum of eight characters.
• Enter description and enter the relevant field names and data elements.
The each field in theÞsegment should represent a structure in the program so for segment a field name and a data element must be defined.
• Save the segment and enter Person Responsible and Processing Person.
• Go to Edit and Set Release.
• Repeat this procedure for each new Segment in the IDOC.

Step 3 – Create a new IDOC Type
via wedi Development - IDOC Types or Transaction WE30.
• Enter segment name (starting with Z), click on Basic Type and then Create.
• Create as new, enter Person Responsible and Processing Person and enter description.
• On ‘Create Basic Type’ screen decide where segments should be inserted and go to Edit/Create Segment.
• Complete relevant fields in the Maintain Attributes screen:
• From the relevant segments created in Step 2 enter the Segment type and if mandatory segment.
• The Minimum and Maximum number of segments to be allowed in the sequence. (One minimum and one maximum if segment is mandatory).
• The Parent Segment and Hierarchy Level will be automatically created depending on where in the IDOC tree you decided to create that particular segment.
• Repeat this process for each segment needed in the IDOC type, deciding whether to add the next segments at the same level or as a ‘Child’.
• When IDOC created return to initial screen. Go to Edit and Set Release.
• Go to Transaction WE60 to view the IDoc Type you have created.

Step 4 – Create new Message Type
via wedi Development - Message Types or Transaction WE81.
• Display/Change and click on New Entries
• Create a new Message Type and Save.

Step 5 – Link Message Type to IDOC Type
via wedi Development - IDOC Type/Message or Transaction WE82.
• Display/Change and then click on New Entries.
• Enter Message Type, Basic Type (IDOC Type) and Release (46C) and Save.

Step 6 – Create an entry in EDP13 via transactions WE20 and BD64.
The partner profile for the Idoc must be set up and generated in the transaction BD64 and transaction WE20.
• WE20 – Add Message Type to appropriate Partner Type, Enter Message Type, Receiver Port and Idoc Type and save.
• BD64 – Create a Model View, Enter Sender and Receiver Ports, Attach Message Type. Go to ‘Environment’ on Menu and click on Generate Partner Profiles and generate (not save) profile.

Step 7 – Populate the custom IDOC via ABAP Program
See Test Program ZOUTBD_IDOC_TEMPLATE, Appendix IV.
• Create an Internal Table for each segment type, this should be exactly the same structure as the segment type.
• The control record is filled into a structure like EDIDC. The message type and the Idoc type for the Idoc must be populated into the eddic structure.
- PERFORM populate_Control_structure USING c_mestyp
c_SEGMENT_type1.
• The data segments are filled into a structure like edidd-sdata; sdata and the segment name are populated into the eddied structure.
- PERFORM transfer_Parent_data_to_seg.
• The standard SAP function module MASTER_IDOC_DISTRIBUTE is called to pass the populated IDOC to the ALE Layer.
- PERFORM master_idoc_distribute.
• NOTE: This function module is only called for stand alone programs and Shared Master Data programs (SMD). It is not called when using extensions or output determination.
• The ALE Layer handles the sending of the IDOC to the receiving system.
• Error handling (see Step 7b).
• Commit work.

Project Specific Step 7b – Error Handling
• Analyze which fields in the interface are mandatory for the receiving system and who needs to receive error notification.
• Declare a structure of type ‘MCMAILOBJ’ for sending instructions.
• Enter values for the internal table based on structure ‘MCMAILOBJ’
• for selection processes, on SY-SUBRC checks and where fields are mandatory for the receiving system; insert Function Module ‘MC_SEND_MAIL’.
• Enter values in the following parameters: -
MS_MAIL_SENDMODE = ‘B’ (Batch Mode)
MS_MAIL_TITLE = 'Mail Title'
MS_MAIL_DESCRIPTION = ‘Error description’ (e.g. MATNR not given)
MS_MAIL_RECEIVER = ‘Name of Receiver’ (To be determined)
MS_MAIL_EXPRESS = ‘E’ (Express Delivery)
MS_MAIL_DLINAME = Leave Blank
MS_MAIL_LANGU = 'E' (Lang usage)
MS_MAIL_FUNKOBJ_NAME = Leave Blank

TABLES
MS_MAIL_CONT = I_MCMAILOBJ

Note:
It has to be determined separately for each interface how these errors and mail notifications are to be grouped – dependant upon the number of errors that are potentially likely. One possible approach is to send an email for each reason for rejection and include all the records that failed for that reason in the mail notification. Another possible approach is to send an email for every failure.
When error checking for mandatory fields it is common SAP practice to reject a record on its first failure (irrespective of subsequent errors in that record)

Step 7c – Send status mail
• Append to table I_MCMAILOBJ details of the time the interface was processed, how many Idocs were created and how many of these produced a status of 03.
• Select the user to receive the mail from ZINT_RECEIVER, using the name of the program as a key (SY-CPROG).
• Use function Module ‘MC_SEND_MAIL’ to send a mail to the user containing the contents of I_MCMAILOBJ at the end of the interface processing.

Step 8 – Test the population of the custom IDOC
via wedi IDoc - Display IDoc or Transaction WE02.
• Enter your message type and execute.
• Status should be green, double click on one of the Idocs you have created to view its contents.
• If a problem has occurred click on Status which will give you a description of the error.
• Drop down Data Records arrow and this should list the data in the IDoc in the correct hierarchical structure.
• Click on each individual segment and view the content to check that the correct data has been read.
• If you have UNIX access by using AL11 you can view the file that you have created.

Note:
For some interfaces it may be valid to send an empty file to SAP. This empty file is converted to the custom IDOC format expected by SAP. This custom IDOC will contain dummy information. In the inbound processing code, if the dummy information is identified then the processing of the IDOC is considered to be complete and the IDOC should then be assigned a successfully processed status of 53, even though it has not been processed at all.

Hi,

2.2 Inbound Interface

Follow steps 1 to 5 inclusive as detailed above in outbound interface.

Step 6
Write a custom function module to handle custom inbound processing. This custom function module must
• Check for the correct message type
• Read the IDoc data segment
• Perform data conversion and validate the data as appropriate
• Post the data to the database
• Handle any error situations
• Set the correct return values for the status record

Note that the Function Module must not make a commit to the database. This is because the status record is not written until control returns to the ALE layer. So if you commit work in the Function Module and an error occurs in returning to the ALE Layer, the status record must not be updated with a successful outcome.

The commit work is executed in the ALE Layer after the status records are updated, via the standard SAP function module IDOC_INBOUND_PROCESS. This attributes of this function module are set up in (Transaction BD51), click on ‘New Entries’ and fill in data; the main input parameters being ‘Input Type’ and ‘Dialog Allowed’.
Take care as some standard SAP transactions contain a Commit Work as part of their processing. Therefore using a BDC to process inbound data to SAP may not be acceptable. You need to check that the SAP transaction is ALE enabled.

Step 7
(Transaction WE57)
Assign the custom function module to the IDoc type and the message type.
Set function module to type ‘F’ and direction ‘2’ for inbound.

Step 8
(Transaction WE42)
Create a new process code and assign it to the function module. The process code determines how the incoming IDoc is to be processed in SAP.

Step 9
(Transaction BD67)
Assign the function module to the process code created above. Got to ‘New Entries’ and enter the process code and the function module name.

Step 10
(Transaction WE20 and Transaction BD64)
Create a partner profile for your message and ensure that in transaction WE20 the process code is the one that points to your function module. (See step 6 of creating Outbound Idocs).

Step 11
Ensure that error handling functionality is present.

Note:

If an interface is expecting a file every day, and a custom IDoc may only be output from SAP periodically, it would be necessary to create some kind of output from SAP on a daily basis to pass to Mercator to allow it to map to an empty file. As we are dealing with custom IDoc types we can design the IDoc so that the data segments are not mandatory. Therefore the SAP program, on finding no data to populate the custom IDoc, would only need to create the control record. The empty IDoc containing the control record would be passed to Mercator. Mercator will map this to an empty file format.

Useful Transaction Codes:

WEDI : IDoc Menu

WE02 : IDoc List (can enter IDoc number to select on)

WE05 : IDoc List

WE19 : Transaction WE19 can be used to test the IDoc

WE30 : IDoc Type Development: Initial Screen

WE31: Development Segments: Initial Screen

WE60 : Documentation for IDoc Types. This allows you to view the IDoc you have created.

WE81: Display View ‘EDI: Logical Message Types’: Overview

WE82: Display View ‘Message Types and Assignment to IDoc Types’: Overview

For Outbound ALE Configurations: (Example)
IDoc definitions and necessary ALE configurations settings for the outbound.

Create Idoc segments – Transaction WE31.

Create Idoc type – Transaction WE30.

Create Message Type – Transaction WE81.

Assign Message Type to Idoc type – Transaction WE82.

Create a distribution Model - Transaction BD64

Update outbound parameters of the Partner profile – Transaction WE20
For the Logical system A for the above two message types update the partner profile.
For each message type specify the Port and the IDoc types.
( Note : Port definition need to maintained using transaction WE21 and
it has to be defined as a Transactional RFC port with RFC destination for
system specified, which need to be maintained using SM59 ).

TRANSACTIONS AND DESCRIPTIONS

Transaction Description
SALE ALE Customizing
BALE Distribution Administration (ALE)
WEDI IDOC Type and EDI Basis
BD21 Analyze change pointers – create IDOC from change pointer
BD10 Send material master
BD12 Send customer master
BD14 Send vendor master
BD61 Activate change pointer generally
BD50 Activate change pointer for message type
BD54 Maintain logical systems
BD64 Maintain distribution model
BD71 Distribute customer model
BD87 Process inbound IDOCs
BD88 Process outbound IDOCs
BDM2 Cross-system IDOC reporting
WE02 IDOC Display
WE05 IDOC List
WE20 Maintain partner profile
WE21 Maintain port definition
WE30 Develop IDOC types
WE31 Maintain IDOC segment
WE60 IDOC Documentation – IDOC types
WE61 IDOC Documentation – IDOC record types
BDM8 ALE Audit – sending confirmations
BDM7 ALE Audit – statistical analyses
WE12 Inbound processing of outbound file – convert outbound to inbound file
WE14 Process (dispatch) IDOCs through port – RSEOUT00
WE15 Outbound IDOC from NAST – message control
WE16 Inbound file
WE41 Process code outbound
WE42 Process code inbound
SARA Central IDOC archiving
WE47 Status code maintenance
SAR3 Archiving object customizing
WE63 IDOC type for parser output
WE82 Assign IDOC to message type
SM59 Maintain RFC destinations
SM37 Display batch jobs – job overview
SM50 Process overview
SLG1 Evaluate application log
SM21 System log
SM58 Transactional RFC monitoring
RZ12 RFC Server Group maintenance

SAP ABAP

ALE CODING WITH DISTRIBUTING OF CUSTOMER DATA FROM HR TO FI SYSTEM

Summary

Business Requirements

Technical Solution

Process in Detail

Custom Tables

INFO ZINF CHAR 1 0 Time id Documentation

Transport Entries of Standard Custom Tables

ALE Distribution of Customizing Data from HR to FI Systems

Disclaimer & Liability Notice

ALE STEP BY STEP PROCEDURE WITH TCODES

TRANSACTIONS AND DESCRIPTIONS

Blog Archive

About Me

CONCEPTS IN ABAP WITH TOPIC WISE

SAP and other ERP consultants

SPONSER LINKS