Inter-Company Billing - Automatic Posting To Vendor Account (SAP-EDI) Automatic posting to vendor account is done by EDI.

In our case where both companies are proccessed in the same system (& client), it is sufficient to create Idoc. This proccess requires several steps: 1. Creating a Customer to represent the receiving Company. 2. Creating a Vendor to represent the supplying company. 3. Creating a Port 4. Maintain an Output Type 5. Creating a Logical Address 6. Creating a Partner Profile for both Customer & Vendor 7. The relevant MM customizing is maintained. 8. The relevant FI customizing is maintained. 1. Creating a Customer to represent the receiving Company. The customer has already been created (XD01) for the purpose of Intercompany processing and entered in the approperiate transction in customizing (Sales and Distribution Billing Intercompany Billing Define Internal Customer Number By Sales Organization). Note: The cutomer has been created in the supplying company code. The organizational data in this case is: Supplying Company Code: 1180 Supplying Plant: 1180 Supplying Sales Organization: 1180 Supplying Distribution Channel: 01 Supplying Division: 00 Receiving Company Code: 3100 Customer representing the receiving Company Code: P3100 2. Creating a Vendor to represent the supplying company. The Vendor is created with the standard transaction (XK01). Note: The Vendor is created in the receiving Company Code. The organizational data in this case is the same as above. Vendor representing the supplying Company Code: P1180 NOTE: There is NO need to connect vendor to customer in the control screen. 3. Creating a Port Tools Business Communication IDoc Basis Idoc Port Definition (T. Code WE21) Maintain Transactional RFC: (Choose Transactional RFC and press the create icon). A dialog box will open asking whether you want the system to generate an automatic name or whether you wish to use your own name. Port name: Automatically generated Version: 4.x

RFC destination: PLD (This was defined by the basis people).

4. Maintain output type Output Type RD04 - Invoice Receipt MM is a special function, responsible for the execution of the Idoc and will be entered in the Partner Profile later on. Output type RD04 is maintained: Img: Sales and Distribution -> Basic functions -> Output control -> Output Determination -> Output Determination Using the Condition Technique -> Maintain Output Determination for Billing Documents Maintain Output Types (T. Code V/40).

Partner functions

Sales and Distribution -> Basic Functions -> Output Control -> Output Determination Output Determination Using the Condition Technique -> Maintain Output Determination for Billing Documents. Assign Output Types To Partner Functions

Maintain Output Determination Procedure

Assign Output Determination Procedures

Master Data Maintain output Master Data Logistics -> Sales and Distribution -> Master Data -> Output -> (T. Code VV31) 5. Create Logical Address Img: Sales and Distribution -> Billing Intercompany Billing -> Automatic Posting To Vendor Account (SAP-EDI) -> Assign vendor. (T. Code WEL1)

Logical address 1180P3100 is made of the supplying Company Code (1180) and the receiving Customer (P3100). Note: If the receiving Customer is a numeric number you must add zeros between the Company code and Customer number so the Logical Address will be 14 digits. E.g if the customer number was 3100, than the logical address would have been 11800000003100 as can be seen in the second line. (In our case the customer is an alpha numeric number so the second line was not necessary. It was created just for this documentation and was not saved) The Logical address is completed when the receiving Company Code and the Vendor are entered in the detail screen.

It is also necessary to activate the account assignment. IMG: Sales and Distribution -> Billing Intercompany Billing -> Automatic Posting To

Vendor Account (SAP-EDI) -> Activate account assignment.

6. Creating a Partner Profile for both Customer & Vendor Tools Business Communication -> IDoc Basis -> Idoc -> Partner Profile (T. Code WE20)

Customer: Put cursor on Partner type KU and press create. Enter typ, Agent & Lang, SAVE

Press in outbound paratrs. Section, to maintain detail screens The following screen will appear.

Enter the following data in the appropriate fields: Partn.funct. BP Message type INVOIC Message Code FI Receiving port A000000001 Basic Type INVOIC01 Press enter and the screen will change to the following: Enter PacketSize 1

Go to the Message Control tab press screen.

and enter the data as specified in the following

You can repeat the process for cases where invoice verification is done against purchase order. in this case enter MM in message code field.

As you can see the only difference between the FI & MM invoice is in the message code and output type. NOTE: You cannot use output type RD04 again therefore you must copy it in customizing to another output type (in this case RD00) Vendor Follow the same procedures but maintain the inbound parameter Screen as follows:

7. FI CUSTOMIZING Financial Accounting Accounts Receivable and Accounts Payable Business Transactions -> Incoming Invoices/Credit Memos -> EDI -> Enter Program Parameters for EDI Incoming Invoice (T. Code OBCE)

Make sure to maintain posting types, tax code and invoice doc.type.

Use KR when not using purchase order & RE when using purchase order.

Assign Company Code for EDI Incoming Invoice

By leaving the field CoCD blank, all company codes are available. Assign G/L Accounts for EDI Procedures (T. Code OBCB) P1180 = Vendor 3100 = Company Code of receiving company (of customer)

NOTE: G/L account should not be connected to CO. Assign Tax Codes for EDI Procedures (T.Code OBCD) It is necessary to match the output tax from the sales order to the input tax. Tax type = Output Tax Tx = Input Tax

Accounting -> Financial Accounting -> General Ledger -> Master Records -> Individual Processing -> Centrally (T.Code FS00)

G/L account no. = account number that was entered in transaction OBCB (page 24) Tax category must allow for input tax. Make sure manual posting is allowed for the G/L account. (Create/Bank/Interest screen). TEXT In many cases the G/L account has been configured so that text is mandatory. This could be either Header Text or Item Text. Header Text No special configuration is necessary. Just enter text in the Header note. You may use the following access sequence.

Item Text It is necessary to implement a userexit in order to fill the item text field. Detailed instructions are found in note 39503 8. MM Customizing: Make sure the Unit of Measures ISO Codes are configured correctly. General Settings Check units of measurement (T. Code CUNI)

Optional MM Customizing: NOTE: This is only necessary for logistics invoice verification. Materials Management Logistics Invoice Verification EDI Enter Program Parameters

Monitoring There are several transaction that allow you to monitor the IDoc. First you need to know the IDoc number. You can see the IDoc number in the processing log in the Header output screen in the billing document. You can use transaction WE02 or WE05. Enter the IDoc number in the selection screen. If you have an error in the IDoc, you could analyze it with transaction WE19

WHAT IS ALE? Application Link Enabling (ALE) is a set of business processes and tools that allow applications on different computer systems to be linked. This can be done between different SAP systems as well as between SAP and non-SAP systems. In a single SAP system different applications are integrated via a single database (e.g. finance, sales, production, human resources). However, many companies do not have just one integrated system but a distributed environment with different applications running on different systems. To run the whole business in such an environment, the distributed applications have to be linked. This can be done through Application Link Enabling (ALE). ALE provides distributed business processes that can be used to link the applications on different platforms. There are some ALE business processes delivered in the standard SAP system. Furthermore, there are tools that can be used to change the existing ALE business processes or to implement new distributed business processes. Besides the business processes, there are special ALE services that are required to set up and control a distributed environment. These services include a distribution model, business object synchronization, and tools for monitoring or error handling. ALE is a major part of SAP's Business Framework Architecture. Besides the basis middleware, that provides the communication between components, and the interfaces (BAPIs), ALE business processes and ALE services enable the cooperation of the single components within the framework. That makes ALE the glue of the Business Framework. WHAT ARE THE BENEFITS OF ALE? With ALE, companies get the opportunity to improve business performance and to solve organizational or technical issues by:

Increasing Flexibility: Through distribution you can decentralize your business, enabling local units to operate independently from each other. This flexibility enables the local units to return better business results than in a centralized environment. They have the necessary flexibility to optimize business processes in different organizational units and can ensure that information systems can handle the speed of change in rapidly expanding markets. Distribution allows a high level of freedom, provided that this level of freedom has been clearly defined. On the other hand, some companies, that already have a distributed organization with different computer systems in the local units, have the opportunity to link their units through ALE business processes. This enables them for example to provide a 'one face to the customer' approach. Another area that can benefit through ALE are virtual organizations (partnerships between independent companies, joint ventures and mergers and acquisitions). Of course, in many cases an integrated solution based on a single system is not possible at all. Some applications used by a company cannot run on the same computer system. This includes legacy systems or complementary software. It may also be possible that a company uses different SAP industry solutions or specific country solutions, which do not run on the same SAP System. If these applications run on different systems, they cannot be linked by a central database but have to use a special integration mechanism like ALE. In this way, ALE also links SAP Core Systems to other SAP components like CRM, Business Information Warehouse or APO. Reducing Costs: Besides the benefits of having an improved flexibility in setting up the whole business processes, ALE may also reduce costs, in particular costs of upgrading. If the whole business is run on one integrated system you have to upgrade the whole system, even if only one part of your company (e.g. human resources) requires an update. So the entire company is affected by the upgrade project and all users have to be trained for the new release. Within a distributed environment with release independent interfaces, like those provided by ALE, you can focus the upgrade project on that part of the company that has to be upgraded. The other parts of the company are not involved and need no training. This can save a lot of money. Furthermore, existing investments are protected. Another cost factor for distribution might be communication costs. For an overseas connection, it can be more expensive to provide online access to one central system (T1) than to connect distributed systems to each other (64K line). Increasing Security and High Availablity: There might also be some technical reasons for distributed systems. If some parts of the business have special requirements for security of data access (e.g. human resources), this can be set up much safer on a standalone system, which is, however, linked to other parts of the company through distributed business processes. A similar example is high availability. High availability is usually required by the operations part of the company (production, logistics), but not by other areas (e.g. financials, human resources). In a distributed environment high availability can be set up for

specific parts of the environment instead of for the whole business. This can also reduce costs. In a distributed environment, you can not decrease the overall workload of the systems but you can separate the user workloads on different systems. Through this scalability you can improve performance. Another benefit of distributed systems is that if a technical failure occurs on one system, all other systems continue to operate. Only a small part of the business is disrupted by the error. On one central system such an error would disrupt the entire business. WHEN SHOULD ALE BE USED? Besides the benefits of ALE there are also reasons not to distribute:

The functional scope in a distributed environment is restricted. Not all functionality that is available in an integrated SAP system can be used with distributed systems in the standard yet. Although ALE provides tools to create new ALE business processes or to enhance existing business processes, this does involve additional expenditure. Each company needs some organizational standards and data harmonization. In a distributed environment, less standards are required than on a single integrated system. However, in a distributed environment the maintenance of the standards and the data harmonization is more difficult than on a single system. The administration of decentralized systems is more expensive. Support and service costs for hardware and software in decentralized systems are higher than these costs in a single centralized system.

ALE should be used in a company if the benefits of ALE for this company outweigh the reasons against distribution. For this you always need to carry out a company specific investigation, in which you also should consider the culture of the company. ALE is good for some companies, but not for all. WHAT IS THE RELATIONSHIP BETWEEN ALE AND MIDDLEWARE? There are many such messages, the most common of these include a customer sending a purchase order message to a vendor, or a vendor sending an invoice message to a customer. Classic EDI is mainly restricted on the exchange of transactional data, no master data or configuration data. In most cases, EDI replaces the transfer of paper copies of these documents. Via the messages ALE business processes can be implemented between business partners. The EDI messages also use the ALE services. For the communication between different types of systems special EDI messages are defined as standards for inter company communication. There are many standards for these messages - in the United States, the ANSI X.12 standard is the most prevalent, in Europe, the UN/EDIFACT standard is used. For sending EDI messages the information has to be converted into an EDI standard. With SAP systems this is done by EDI subsystems. This conversion is the only difference between EDI messages and other messages used in ALE business processes. The processing of these messages on the SAP System is the same as the processing of other ALE messages. WHICH ALE BUSINESS PROCESSES ARE AVAILABLE? ALE business processes are integrated business processes that run across distributed systems. This can be two different SAP systems, links between SAP and non-SAP systems, SAP and Web-servers (Internet Application Components) or SAP and desktop applications. The links between the systems may be loosely (asynchronous) or tightly (synchronous) coupled. These business processes are release-independent and can run between different release levels of the systems. Many SAP applications offer ALE distribution processes, for example Master Data Replication, Accounting, Logistics and Human Resources. WHEN SHOULD SYNCHRONOUS OR ASYNCHRONOUS LINKS BE USED? When distributed applications are linked by ALE business processes, the question often arises as to how tight the link should be. Synchronous and asynchronous links have both advantages and disadvantages:

Synchronous links have the advantage that the sub-process on the server can return values to the subprocess on the client that has started the link. Problems with synchronous links occur if the communication line or the server is temporarily not available. If this happens, the sub-process on the client can not be finished (otherwise there would be data inconsistencies). (Example: There is a logistics system and a financial system. Every stock movement in logistics has to be

posted in the general ledger of the financial system. If the link between logistics and finance is synchronous, no stock movement can be recorded in the logistics system if the communication line to the financial system is down.) Because of this, synchronous links are usually used if the client only wants to get some data from the server and the sub-processes on the server do not have to write any data to the database. With asynchronous links the sub-process on the client can be finished even if the communication line or the server is not available. In this case the message is stored in the database and the communication can be done later. The disadvantage of asynchronous links is that the sub-process on the server can not return information to the calling sub-process on the client. A special way for sending information back to the client is required. In addition, a special error handling mechanism is required to handle errors on the receiving side. Asynchronous links are used if a synchronous link is not applicable. For the problems with sending return information to the client and with error handling there is some support from the ALE services.

WHY DOES SAP USE ALE INSTEAD OF DATABASE REPLICATION OR DISTRIBUTED DATABASES? Database replication is another possibility for doing business object synchronization. However, there are some major disadvantages with database replication. At the moment database replication is database dependent and releasedependent within one database. This makes database replication impossible for the use with non-SAP systems and even for the replication between SAP systems, you have to make sure that all systems are running on the same SAP release and the same database release of a single database vendor. Furthermore, with database replication you cannot do things like field conversions or version changes. ALE does not have these shortcomings because it offers application driven data replication independent of the underlying database. Another technology, distributed databases, is no alternative for ALE at the moment, either. There are some good results of distributed databases available, but the performance is far from sufficient for using it with larger applications like SAP. HOW CAN I SERIALIZE IDOC PROCESSING? There are various procedures for processing IDocs in a serialized way, that is to process them or transfer them to the application in a certain sequence. Depending on your respective requirements, one of the methods proposed in note 752194 may be suitable for the required purpose.

ALE IDOC Cheat sheet

Posted by sapmm on April 16, 2009 Here is the complete list of all the transaction codes you need to know for ALE & IDOCS. keep it handy, always useful Main Transaction Codes Main Menus WEDI EDI Related Activities BALE ALE Related Activities SWLD Workflow Related Activities SALE ALE Configuration NACE Message Control Configuration IDOC Definition SE11 Data Dictionary WE30 IDoc type editor WE31 Segment editor BD53 Reduction of IDoc types WE60 Documentation for IDoc types WE61 Documentation for IDoc record types IDOC Monitoring WE02 IDoc display WE05 IDoc Lists WE06 Active IDoc monitoring WE07 IDoc statistics Configuration(ALE and EDI) BD54 Maintain logical systems BD64 Maintain distribution model BD71 Distribute Customer Model BD82 Generate partner profiles FILE Logical File Paths PFTC Task Definition PPOC Maintain Organization Structure SM59 Maintain RFC Destinations SWE2 Event Linkage SWU3 Basic Workflow Settings WE20 Partner profiles WE21 Port definition Run Time Workflow SO01 SAP Inbox

SWEL Event Log SWI1 Workflow Log SWI2 Work Item Analysis SWI5 Workload Analysis Message Control NACE Condition Record Maintenance VOK2 SD Message Control Components VOK3 Purchasing message Control Components VOFM View Message Requirements V/86 Condition Table Field Catalog WE15 IDoc test: Outbound from MC Testing WE19 Test tool WE12 IDoc test: Inb. Procg of Outb. File WE16 IDoc test: Inbound File WE17 IDoc test: Inbound status report Reprocessing IDOCS BD87 Process inbound IDocs BD88 Process outbound IDocs System Monitoring SM12 Locked Entries SM13 Update Monitoring SM21 System Log Display SM58 Transactional RFC Log SM66 Debug Async Update Tasks ST22 Dump Analysis Other Relevant Transaction Codes AL05 Monitor current workload AL11 Display SAP Directories AL18 Local File System Monitor AL19 Remote File System Monitor AL21 ABAP Program analysis ALO1 Data Relationship Browser ANA_VAR Table Analysis: Analysis Variants BA10 Subsystem Config. BA11 Channel Definition for Transceiver BD10 Send Material BD100 IDoc display object channel view BD101 Consistency check BD102 Outbound registry BD103 Inbound registry

BD104 maintain tbd53 BD105 maintain tbd54 BD11 Fetch Material BD12 Send customer BD13 Open customer BD14 Send vendor BD15 Open vendor BD16 Send Cost Center BD17 Get Cost Center BD18 Send General Ledger Account BD19 Get General Ledger Account BD20 IDoc passed to application BD21 Select change pointer BD22 Delete change pointers BD23 Delete serialization data BD24 Send Cost Elements BD25 Send Activity Type BD26 Get Activity Type BD27 Send cost center activity prices BD28 Send obj/cost element control data BD30 Distribute material object list BD31 Distribute document object list BD32 Distribute plant allocations(matBOM) BD40 Read change pointer for group BD41 Dispatch IDocs for group BD42 Check IDocs for group BD43 Post IDocs for group BD44 Assign message types to ser. group BD47 Dependencies between methods BD48 Dependency method message BD50 Activ. change pointer for mess.type BD51 Maintain function modules (inbound) BD52 Activ.change pointer per chng.doc.it BD53 Reduction of IDoc types BD55 Maintain IDoc conversion BD56 Maintain IDoc segment filtering BD57 Maintain link and serialization ty. BD58 Convert Org. units BD59 Allocation object type -> IDoc type BD60 Additional data for message type BD61 Activate change pointer BD62 Define segment conversion rule BD63 Transport ALE tables to message type BD65 Maintain IDoc type required fields BD66 IDoc type field -> change doc.field BD67 Maintain input methods

BD68 Maintain lists BD69 Assign message type to IDoc BD70 Adjust number ranges BD72 Activate events BD73 Reposting of IDocs (ALE) BD75 Convert IDoc status BD76 Model upload/download monitoring BD77 Distribution of control data BD78 Monitoring control data distribution BD79 Maintain IDoc conversion rules BD80 Conversion pre-production/production BD81 Filter objects parameter filtering BD83 Send IDocs after an ALE error BD84 Post IDocs after ALE error BD85 Consistency check for transfer BD86 Consistency check for sales BD89 Control data model. initial screen BD90 Start DA-OU BD91 Send characteristic BD92 Send class BD93 Send classification BD94 OA file transfer BD95 Specify ALE object types BD96 filter objects of receiver determin. BD97 Assign RFC dest. to logical systems BD98 ALE consistency check active BD99 Message type dependencies BDA1 Call RSARFCEX BDA4 Specify ALE object types BDA5 Distribute documents BDBG Generate ALE interface (BAPI) BDBP Hierarchy maintenance of BAPI param. BDBS Generate coding for mapping BDCP Number range maintenance: ALE_CP BDLS Mapping Logical System Names BDM2 Monitoring: IDocs with receiver BDM5 Consistency check BDM6 Monitor: Check input workflow BDM7 ALE Audit: statistical analyses BDM8 ALE Audit: Sending the confirmations BDM9 Reorganizing the audit database BDMC Upload info structures BDR1 Display application log for recovery BDR2 Reorganization of recovery data BDRC ALE: Determine recovery objects BDRL ALE: Process recovery objects

OE2C Process Code Inbound OYE0 EDI: Maintain Port Def. arfc OYE3 Display EDI Ports OYE4 Display ALE Ports OYED Maintain Port Definitions OE3C System Process Code OE1C Process Code (OutB) OYEL Display EDP21 (InB Partner Profile) OYEX Create EDP21 (InB Partner Profile Overview) OYEH Display EDP12 (Msg Control) OYER Create EDP12 (Msg Control Overview) OYEI Display EDP13 (OutB Partner Profile) OYEU Create EDP13 (OutB Partner Profile overview) OYSM Number Range Port Definition OYSN Number Range For IDOCS OYSO Number Range IDOC Types WE08 EDI: File Processing Status (EDFI2) WE09 IDoc lists enhanced WE10 IDoc lists enhanced WE14 IDoc test: Outb. from IDoc WE30 IDoc type editor WE32 View editor WE33 Value tables for IDoc documentation WE40 System process codes WE41 Process codes, outbound WE42 Process codes, inbound WE43 Funct.module: Status record display WE44 Partner Types and selection reports WE45 Forward (inbound) (V3, EDILOGADR) WE46 IDoc administration WE47 Status Maintenance WE48 Inbound process codes: Texts WE49 Inbound process codes: Change texts WE50 System process codes: Texts WE51 System process codes: Change texts WE52 Outbound process codes: Texts WE53 Outbound process codes: Change texts WE54 FMs for changing file names WE55 FMs for path names WE56 Status process codes WE57 Messages and application objects WE58 Status process codes: Texts WE59 Change status process codes WE62 Documentation for segments WE63 Parser for IDoc types and rec.types WE70 Conversion: Basic types

WE71 Conversion: Extensions WE72 Conversion: IDoc types WE73 Conversion: Logical messages WE80 IDoc types: Overview WE81 Logical message types WE82 Assignment IDoc type Message WE83 Extensions: Overview (EDCIM) WE84 Assignment of IDoc and appl. fields WECP Display CPIC interface status (R/2) WEL0 Forward (inbound) (EDILOGADR) WEL1 EDI: Interface Invoice for EDILOGADR WENA Messages on basis of changes WorkFlow Configuration OOAW & SWLV Subordinate And Peer Definition PFAC Standard Roles PO13 Maintain Substitutes SWO1 Business Object Builder If you like this post, you may as well like these too:
1. How to Populate extended IDOC File segments? Once you extend the IDOC, it is an enhancemnet of the standard IDOC. Write some coding in the USER-EXIT for each outbound/inbound message. Go to CMOD and search for 2. Archieving IDOC Nice article from a guy in Infosys showing the clear steps on archeiving IDOC. Here is the link to sdn. Download the Archieving IDOC(PDF File) from sapdb. 3. IDOC Creation (Step by Step) This Idoc Creation Procedure (Step by step Guide) will teach you with all the instructions on creation of Inbound and Outbound IDOC with screen shots for better understanding. 4. ALE Configuration To develop and configure a new custom ALE scenario, comprises 5 steps: 1. Design and develop the custom IDoc with it s segments and a new message type 2. 5. Learn ALE Implementation and IDOC creation in Simple Steps Here is a nice little article giving you simple steps as to how to Implement ALE and to create IDOC. ALE Implementation Guide and IDOC Creation Thanks to Menon