· web viewmicrosoft dynamics ax. integration of sap and. microsoft dynamics ax with. microsoft...

Microsoft Dynamics AX

Integration of SAP andMicrosoft Dynamics AX withMicrosoft BizTalk® Server

Regional Distribution Scenario: Parent company sells products to the sales officeWhite Paper

This document is based on the integration between a SAP R/3 and a Microsoft Dynamics AX business management system in a demo environment. In particular, it focuses on integration betweenMicrosoft® BizTalk® Server 2009, Microsoft Dynamics AX 2009 and SAP Business Suite.

Created by Microsoft Corporation in collaboration with Hitachi Consulting.

Date: September, 2010

www.microsoft.com/dynamics/ax

1. INTRODUCTION................................................................................................41.1 BUSINESS TRANSACTIONS......................................................................................................41.1.1 PURCHASE ORDER FROM MICROSOFT DYNAMICS AX TO SAP......................................51.1.2 SHIPPING NOTIFICATION AND DELIVERY FROM SAP TO MICROSOFT DYNAMICS AX. 51.1.3 INVOICE DOCUMENT FROM SAP TO MICROSOFT DYNAMICS AX...................................5

2. SYSTEM SETTINGS AND MASTER DATA......................................................62.1 SAP CUSTOMIZATIONS.............................................................................................................62.1.1 CUSTOMIZING THE ORGANIZATIONAL STRUCTURE IN SAP............................................62.1.2 CUSTOMIZING “SALES & DISTRIBUTION” IN SAP...............................................................72.1.3 CUSTOMIZING “LOGISTICS EXECUTION” IN SAP...............................................................92.2 SAP MASTER DATA................................................................................................................... 92.2.1 SALES OFFICES AS CUSTOMERS TO PARENT COMPANY...............................................92.2.2 SALES OFFICES AS COMPANY CODES IN SAP..................................................................92.2.3 PRODUCTS USED IN TRANSACTIONS...............................................................................102.2.4 PRICE LISTS......................................................................................................................... 102.2.5 CHART OF ACCOUNTS........................................................................................................102.3 SETTING UP MICROSOFT DYNAMICS AX.............................................................................102.3.1 POST INSTALLATION SETUP..............................................................................................102.3.2 CONFIGURING AIF ENDPOINT ID.......................................................................................122.3.3 MICROSOFT DYNAMICS AX CUSTOMIZATIONS...............................................................12

3. MASTER DATA UPLOAD TO MICROSOFT DYNAMICS AX.........................133.1 IDOC SETUP FOR MASTER DATA TRANSFER......................................................................14

4. MICROSOFT BIZ TALK SERVER...................................................................144.1 INTERFACING TO AND FROM SAP........................................................................................154.2 INTERFACES............................................................................................................................ 154.2.1 SAP INTERFACE DEFINITIONS...........................................................................................154.2.2 INTERFACE MAPPINGS.......................................................................................................154.3 SETTING UP BIZTALK..............................................................................................................164.3.1 PURCHASE ORDER CREATION..........................................................................................164.3.2 BIZTALK DESIGN..................................................................................................................164.3.3 MAPPING AX PURCHASE ORDER TO SAP SALES ORDER..............................................184.3.4 BIZTALK ORCHESTRATION.................................................................................................184.3.5 SALES ORDER CONFIRMATION.........................................................................................214.3.6 RECEIVING IDOCS FROM SAP...........................................................................................214.3.7 CREATE MESSAGE SCHEMAS...........................................................................................224.3.8 CREATE GENERIC SCHEMAS.............................................................................................244.3.9 MAPPING SAP SALES ORDER CONFIRMATION TO POSO SCHEMA..............................254.3.10 MAPPING SAP SALES DELIVERY CONFIRMATION TO POSO SCHEMA.........................264.3.11 INVOICE IDOCS....................................................................................................................264.3.12 ORCHESTRATION................................................................................................................274.3.13 DEPLOYING FOR REGIONAL DISTRIBUTION SCENARIO................................................284.3.14 CREATING SAP RECEIVE PORTS FOR IDOCs..................................................................29

2

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

5. SCENARIO DETAILS.......................................................................................305.1 SCENARIO #1: CENTRAL ORGANIZATION IS PROVIDING GOODS TO ITS DISTRIBUTION SUBSIDIARY...................................................................................................................................... 305.1.1 SYNCHRONIZATION OF ITEMS AND PRICE LIST..............................................................315.1.2 TRANSFORM PURCHASE ORDER INTO SALES ORDER..................................................325.1.3 TRANSMIT ORDER, ITEM/QUANTITY, DATE CONFIRMATION.........................................365.1.4 UPDATE SALES ORDER STATUS AND QUANTITIES (GOOD RETURN TO SALES RETURN)............................................................................................................................................ 375.1.5 SEND INVOICE.....................................................................................................................37

6. CONCLUSION..................................................................................................38

3


1. INTRODUCTIONLarge enterprises consist of multiple small entities such as subsidiaries, branches, locations, and departments. In often cases, those smaller entities have either different business processes or totally different activities and business models. Most large corporations have implemented a financial solution such as SAP or Oracle (Tier 1 solutions) as their ERP backbone to run most operations. However, some of the local entities are too small to operate with the Tier 1 solutions due to complexity or budget constraints for the cost of implementation. Microsoft Dynamics AX offers a great alternative to those local entities by focusing on delivering flexible industry solutions that are easy to implement, and simple to use for maximum user adoption with minimal training. Microsoft Dynamics ERP two-tier connector allows Microsoft Dynamics AX to be implemented in subsidiaries to lower costs and increase productivity while remain connected to the corporate headquarters financial system.

The Microsoft Dynamics ERP Two-Tier Connector for SAP allows Microsoft Dynamics AX to exchange information with SAP Business Suite 6 (SAP) to facilitate collaboration across sites or departments by streamlining business processes going through different systems.

This document will describe the Regional Distribution scenario about the integration of intercompany procurement and supply-chain processes between local and regional distribution with centralized fulfillment organizations. In this scenario, the local company will source its items/products from other entity running on SAP. The request will be transferred to SAP and supply chain processes will execute and then update in both environments so users do not have to navigate through multiple user interfaces (UI) to track status of this sourcing and delivery process.

1.1 BUSINESS TRANSACTIONS The parent company sells products to the sales office. The basic elements of this order-to-stock transaction between sales office and parent are shown in the figure below.

4


In this scenario, the SAP parent and Microsoft Dynamics AX sales office essentially have a vendor-customer relationship. Information is exchanged, goods are shipped and cash is collected.

1.1.1 PURCHASE ORDER FROM MICROSOFT DYNAMICS AX TO SAPIn this scenario, demand planning is completed locally at the sales office so internal business rules in the sales office trigger purchase activities. A purchase order containing quantities, prices and a required delivery date is sent from Microsoft Dynamics AX to SAP. A standard SAP sales order is created upon receipt of a purchase order received from Microsoft Dynamics AX. A SAP sales order number is automatically created if the transaction is successful. The sales order captures the Microsoft Dynamics AX purchase order number, which is used as a tracking reference number both by SAP (parent company) and Microsoft Dynamics AX (sales office) throughout the business process. In addition, the sales order number from SAP is captured in the Microsoft Dynamics AX purchase order. BizTalk transforms the outbound Microsoft Dynamics AX purchase order into an inbound sales order message and calls the standard SAP BAPI to create the sales order in SAP.

After the sales order is processed in SAP, the sales order confirmation is passed to Microsoft Dynamics AX using BizTalk. The purchase order Corporate ERP field in Microsoft Dynamics AX is updated.

1.1.2 SHIPPING NOTIFICATION AND DELIVERY FROM SAP TO MICROSOFT DYNAMICS AX When the complete order can be delivered, a delivery is created after which a goods issue is done in SAP. Both transactions are manual. The delivery note created in SAP acts as a pick request for the warehouse to pick the order. The picked quantities are then manually updated in the delivery note. A goods issue in SAP depletes the stock levels in the system and makes a financial posting to reduce the value of the stock. This usually happens when the actual physical goods leave the warehouse to be delivered. A goods issue process results in material and accounting documents being created in SAP. The creation of the delivery note, updating the pick quantities and goods issue can be done directly in the delivery note (one transaction in SAP). When the goods issue is done and the delivery note is saved, the shipping notification message is automatically triggered and sent to Microsoft

5


Dynamics AX. The shipping notification creates an Inbound Microsoft BizTalk Purchase Receipt document in Microsoft Dynamics AX. This receipt automatically updates the Expected Receipt Date in the Purchase Order indicating when the complete order (total quantity of all requested items) will arrive at the sales office. The SAP shipping notification document number is also captured as the Vendor Shipment no. in the Microsoft Dynamics AX Purchase Order. The mechanism for the interface uses a standard SAP IDOC (intermediate document). The IDOC is generated as soon as the document is saved.

1.1.3 INVOICE DOCUMENT FROM SAP TO MICROSOFT DYNAMICS AXSince the sales invoice is delivery-based, the outbound delivery and goods issue will first have to be created in SAP before the sales invoice can be created. The sales invoice message consists of the sales price for each item that has been ordered from the Microsoft Dynamics AX sales office. The total amount to be paid to the parent company is calculated in Microsoft Dynamics AX. The Microsoft Dynamics AX purchase order number is also recorded in the sales invoice. The invoice triggers the creation of an Inbound Microsoft BizTalk Purchase Invoice document in Microsoft Dynamics AX. This invoice automatically updates the Due Date in the Purchase Order indicating when a payment is expected from the sales office. The SAP sales invoice document number is also captured as the Vendor Invoice no. in the Microsoft Dynamics AX Purchase Order. The mechanism for the sales invoice interface uses a standard SAP IDOC. The IDOC is generated in the sales invoice document as soon as the document is saved.

2. SYSTEM SETTINGS AND MASTER DATAThe business transactions described above depend on system settings and master data. The system settings form the organizational and technical structure, and the master data is the basis for content in the business transactions. This section describes the system settings for both SAP and Microsoft Dynamics AX concerning the integration of their processes.

2.1 SAP CUSTOMIZATIONSIn SAP, configuring the system is called “customizing.” This functionality provides all the means to configure the system and make it fit to an organization and its business processes. In other words, the customization does not concern operational data, but rather, the business structure and business process definition. Customizing in SAP is done in the Implementation Management Guide (IMG) and has a tree-like structure. Screenshots of the relevant areas in this structure have been included in the text below.

2.1.1 CUSTOMIZING THE ORGANIZATIONAL STRUCTURE IN SAPA standard SAP IDES environment has been customized to incorporate the Microsoft Dynamics AX sales office on an operational and financial level. This paragraph describes the elements that have been customized to create the scenario.

SAP Transaction: SPRO

SAP Implementation guide: Enterprise Structure- Definition

IMG Area Activity Description

6


Financial Accounting Define company code CUS Create a company code for the parent company.This is the smallest organizational unit where accounting transactions are registered. There is one single, standard company code for the SAP parent for which a chart of accounts has been defined. All financial transactions which involve the parent company are registered in this company code.

Define company code CEU The Microsoft Dynamics AX sales offices are represented as separate company codes in the SAP system. The reason for this setup is that it facilitates the financial consolidation of the sales offices.

Logistics- General Define plant CUS Create a site which represents the operating area of the parent company

Define division 00 A division is an organizational part of the sales area through which products are sold to customers.

Sales & Distribution Define Sales Organization CUS All sales are registered on this organizational level.

Define Distribution Channel 12 Part of sales area.

Materials Management Define Storage Location 0001 Physical location where stock is kept.

Logistics Execution Define Shipping Point CUS Point from which deliveries leave the plant.

SAP Transaction: SPRO

SAP Implementation guide: Enterprise Structure- Assignment

IMG Area Activity DescriptionFinancial Accounting Assign company code CUS to

credit control area 1000Credit control area 1000 is the standard IDES control area for Europe.

Controlling Assign company code CUS tocontrolling area 1000

Activate cost accounting functionality for the company code. Controlling area 1000 is the standard IDES controlling area for Europe. To make postings to cost elements possible (for example, to distribute the costs to a cost center, or to make an internal order), you must assign a company code to a controlling area. For this demo, we used account 792000, which is also presented as a cost element in controlling (because of the SAP standard setup). Of course, the decision to include a controlling area depends on many factors, which are not really relevant for this demo.

Logistics- General Assign plant CUS to company code CUS

A plant belongs to one company code

Sales & Distribution Assign sales organization CUS to company code CUS

Link financial accounting (company code level) to the sales activities.

Assign distribution channel 12 to sales organization CUS

Distribution channels and divisions are linked to sales organizations. The sales area can then be set up using combinations of sales organizations, distribution channels and divisions. For the scenario, a single sales area is used, as there is just one sales channel for intra-company sales.

Assign division 00 to salesorganization CUSSet up sales area CUS/12/00

7


Assign sales organization –distribution channel – plant

Define the plant that will provide goods for the sales area.

Logistics Execution Assign shipping point CUS to plantCUS

A shipping point is part of a plant.

SAP Transaction FS00Change reconciliation account for vendor

Reconciliation accounts for a vendor or customer are setup in SAP for automatic posting only. Therefore, you cannot post directly to these accounts. Account 165000 needed to be changed to make manual posting possible for this demo. Therefore, we connected 165000 to a general ledger account group without the check for automatic posting. NOTE: This is a necessary setting, without which posting is not possible.

2.1.2 CUSTOMIZING “SALES & DISTRIBUTION” IN SAPThe following three sales documents are used in the scenario: Sales order confirmation Sales invoice Delivery Note

The sales order confirmation, delivery note and the sales invoice used in the scenario are standard SAP IDOCs. There are no modifications in the way the documents are generated as the scenario is based on standard SAP functionality. All the parameters described below are available in a standard SAP IDES environment.The first step for sending a sales order confirmation is the Output Type definition for the sales order. Output type BA00 is the standard type for sales order confirmation and can be accessed in the path SAP Customizing Implementation Guide> Sales and Distribution> Basic Functions> Output Control> Output Determination> Output Determination Using the Condition Technique> Maintain Output Determination for Sales Activities> Maintain Output Determination for Sales Documents> Maintain Output Types. The delivery note output type LD00 is the standard type for delivery confirmation which along with sales invoice is set up in the same way, but has output type RD00.

SAP Customizing path for Maintain Output Types.The output type does not define one single medium used for creating the output. SAP allows various methods to output a sales order confirmation such as printer, fax, EDI. Medium four allows us to send IDOC messages and will be explained in the next step.

In the second step, the system can link the output type and specific medium to a business partner.This is useful because you might deal with some business partners who want to have paper forms while others prefer electronic messages. The condition record created below shows that sales order confirmations for business partner CEU are created using medium 4, which means ALE distribution model is used to create an IDOC as soon as the sales order has been saved in the SAP system. This is not part of the customization but is closer to transactional/master data and thus accessed in the standard SAP user menu as transaction NACE.

8


An actual sales order document (transaction VA03 – display) contains the reference to the output type and shows the status of this output (whether it is paper or otherwise). The log for the sales order show that output type BA00 (order confirmation) has been created in the form of an IDOC message that has been forwarded for transmission.

At this point, we turn to the configuration of the IDOC subsystem where partner profiles are created for every business partner, with which the system needs to exchange electronic messages. Partner profiles are accessed using transaction WE20.

The sales office is represented as a standard customer. A corresponding partner profile has been created to define that the system will allow the following types of IDOC messages to be sent to this particular business partner (outbound parameters):

Sales Order Confirmation

OR Standard OrderBA00 Order ConfirmationV10000 Order OutputORDRSP Purchase order / order confirmationORDERS05 Purchasing/Sales

As indicated earlier, the sales order confirmation will only reach the sales office if the parent company cannot meet the requirements of the purchase order sent by the sales office.

Sales Invoices

Billing Type F2 InvoiceOutput type RD00 InvoiceOutput Determination Procedure

V10000 Billing Output

Message Type INVOIC Invoice/Billing DocumentBasic Type INVOIC01 Invoice/Billing document

2.1.3 CUSTOMIZING “LOGISTICS EXECUTION” IN SAP

The advanced shipping notification IDOC is customized in the same way as the sales documents described above. The output type for this message is LD00 and is created and sent after the delivery is created using VL01N in the system.

2.2 SAP MASTER DATABesides the customizing described above, the SAP environment needs master data to process the business transactions. The following paragraphs describe the master data needed to set up business process integration.

2.2.1 SALES OFFICES AS CUSTOMERS TO PARENT COMPANY

Customer master record CEU

9


In an ‘all-SAP’ solution where both parent and sales offices operate within a SAP landscape, the sales offices would be separate plants and/or sales organizations depending on whether they carried inventory or not. This setting would make it possible to register the individual sales activities of every sales office. However, the intercompany procurement and supply chain process scenario demands another approach where end-customer sales are registered at the parent company as monthly net figures provided by the sales office. The replenishment of stock at a sales office takes place in a vendor-customer relationship. This allows the parent company to capture its intra-company sales and isolate it for financial consolidation purposes at a later stage. In order to create this scenario, the sales office is set up as a standard customer master record in the SAP system. This customer master is referenced when creating sales orders for the sales office. For this scenario, customer master record CEU has been created using transaction XD01.

2.2.2 SALES OFFICES AS COMPANY CODES IN SAP

Company code CEU

Sales offices are set up as company codes in order to create financial postings for the consolidation at the end of the month. Company code CEU has been created for this purpose in the same way as the company code CUS for the parent company.

2.2.3 PRODUCTS USED IN TRANSACTIONSThe following table displays the material master records that have been set up for selling to the sales office. They are finished products (type FERT) with a standard cost price. Access the material master using transaction MM03.

Material master records 000000000000000001000000000000000012000000000000000015000000000000000016000000000000000017000000000000000018000000000000000019

2.2.4 PRICE LISTSOne price list is an “Inter-company Price List” that provides transfer prices, which are prices that are agreed upon by the parent company and its sales offices as a purchase price. The price lists have been created using the standard SAP price list with no modifications. Only the sales prices (no taxes) are listed. The mechanism for interfacing is using an IDOC.

2.2.5 CHART OF ACCOUNTSThe standard SAP international chart of accounts (INT) is used to do G/L accounting in the parent company code CUS and sales office CEU.

Chart of Accounts INT

10


2.3 SETTING UP MICROSOFT DYNAMICS AXThe organizational structure in a Microsoft Dynamics AX sales office is simple. There is a company definition with an area of activity represented by a division. This division sells to end-customers in this scenario and generates sales revenues which, at a later stage, are consolidated in SAP.

The next paragraph provides the Microsoft Dynamics AX setup steps for the scenario. The setup is based on the .xpo file bundled with this document.

2.3.1 POST INSTALLATION SETUP Setup Microsoft BizTalk Management

In Microsoft Dynamics AX, go to Basic>Setup> Application Integration Framework>Global settings to open the Integration Framework global settings form

Select Ignore ‘Record Version’ for updates field

By default, the Application Integration Framework (AIF) is validating the record version value in the incoming XML file with the current value in the respective record in the Microsoft Dynamics AX table. An error message regarding the differences in values will not appear since the Ignore ‘Record Version’ for updates field has been selected. For the purpose of this demo scenario, a parameter was created to bypass this default for updates.

AIF Global Settings.

11


A trigger can be set for all or some of the Corporate ERP field in the Purchase Order form. In addition, the trigger can be turned off if needed. In Microsoft Dynamics AX, go to Accounts payable>Setup> Parameters>AIF tab. Select the Purchase Order – Trigger action by AIF field.

The Corporate ERP field has the following values: None Cancelled SalesOrderConfirmed SalesOrderSent SalesOrderShipped Received Invoiced Backorder ReceiptsList PurchaseOrder ShippedQtyUpdated PayInvoicedSalesOrder Returned

Currently, a trigger is setup for the following Corporate ERP field values: PurchaseOrder: Do “Purchase Order” posting SalesOrderConfirmed: Do “Purchase Order” posting Invoiced: Do “Invoice” posting

NOTE: The other values can be used as placeholders to attach actions to them.

The following is an additional setup step: o In the Accounts payable parameters form, select Copy all dollar values from

incoming AIF file field to ensure the sales prices, discounts and total line amounts are copied from the incoming AIF file.

AIF Account Payable Parameters.12


2.3.2 CONFIGURING AIF ENDPOINT IDThe Endpoint ID field can be set up in the AIF by navigating to Basic>Setup>Application Integration Framework> Endpoints. The endpoint is the external entity that participates in the document exchange. In this scenario, the endpoint is BizTalk and is called RemoteEP.

2.3.3 MICROSOFT DYNAMICS AX CUSTOMIZATIONSFour fields have been added to the Purchase order form. The fields are Corporate ERP, External Sales Order Id, Last External Invoice, and Last External Invoice Date were added to the PurchTable table.

Corporate ERP field is a non-editable field (enum) and can only be changed by an AIF incoming document. It stores the status of the purchase order relative to the sales order in SAP.

External Sales Order ID field is a non-editable field and can only be changed by an AIF incoming document. This field stores the created SalesOrderId from SAP.

Last External Invoice field is a non-editable field and can only be changed by an AIF incoming document. This field stores the InvoiceId of the created SalesOrderId from SAP. This field is available in the Posting tab of Purchase order form.

Last External Invoice Date field is a non-editable field. Microsoft Dynamics AX will set the current date when the Last External Invoice is set. This Last External Invoice Date field is available in the Posting tab of Purchase order form.

The Send electronically button has been added to the Purchase order form to send the purchase order as an XML message to the Gateway queue.

The following graphic shows the Purchase order form with the Send electronically button in the header.

Microsoft Dynamics AX Purchase Order.

13


The following shows the window when the Send electronically button is selected.

Microsoft Dynamics AX Send Document Electronically Screen.

3. MASTER DATA UPLOAD TO MICROSOFT DYNAMICS AXFor this scenario, the Item Master and its inter-company price only are interfaced with Microsoft Dynamics AX.

3.1 IDOC SETUP FOR MASTER DATA TRANSFERA partner profile should be created in SAP system which introduces a logical system to exchange IDOCs. In this scenario, the logical system is the Microsoft BizTalk server which is the ‘logical’ destination of the outbound IDOCs.

The outbound IDOCs can be setup with the following procedures in the URL. http://msdn.microsoft.com/en-us/library/ms942196(BTS.10).aspx

There is no business trigger for the distribution of master data; this is done manually using standard SAP transactions.

The MATMAS is sent through the navigation: ALE> Master Data Distribution> Cross Application> Material or transaction BD10 (Send Material)

4. MICROSOFT BIZ TALK SERVERThe BizTalk is used in the Microsoft Dynamics ERP Two-Tier Connector scenario as an integration broker between SAP and Microsoft Dynamics AX. The communication between SAP and BizTalk is carried out by IDOCs (SAP standard interfacing documents) and BAPIs (SAP Business Objects). The following displays the communication between SAP, BizTalk, and Microsoft Dynamics AX.

14


http://msdn.microsoft.com/en-us/library/ms942196(BTS.10).aspx

Corporate Legacy System

i.e. SAP ERP 6.0

Materials + Prices (IDOCS)

Create Sales Order (BAPI)

Sales Invoice (IDOCS)

Financial Consolidation (BAPI)

Items + Prices (AIF)

Order Confirmed (AIF)

Purchase Invoiced (AIF)

Financial Consolidation (AIF)

Sales Order Confirmation (IDOCS)

Order Shipped (AIF)Shipping Notification

(IDOCS)

New Purchase Order ( AIF)

4.1 INTERFACING TO AND FROM SAPThere are two interfacing methods used:

IDOC: Outbound IDOCs are documents that can be created by SAP. For example, an IDOC with all information of the sales order is sent to another system when a sales order has been created and saved.

BAPI: BAPIs contain functions that can be executed from outside SAP by using RFC connections.

Choice between BAPI’s and IDOC’s:Due to the complexity of IDOCs, the scenario uses BAPIs for the inbound SAP-interfaces. The structures and tables as input for the BAPIs are less complex than for IDOCs. For the outbound SAP interface, IDOCs are implemented because these are created by SAP and contain far more data thanBAPIs can return.

If there are high volumes of changes to outbound and inbound messages then IDOCs are preferred due to less administrative processes in BizTalk by leveraging content based routing. For example, IDOCs can be used for Master data such as items, customers, and vendors. BAPIs are preferred for lower volume changes to outbound and inbound messages. The BAPIs provide more control of transaction’s content and operations. For example, a transaction validated in SAP can trigger a required approval which can be sent back to BizTalk.

15


4.2 INTERFACESThe interfaces for the Microsoft Dynamics ERP Two-Tier Connector are summarized below:Interface Source Destination

1. Materials (IDOC MATMAS05) SAP Microsoft Dynamics AX2. Customers (IDOC DEBMAS03) SAP Microsoft Dynamics AX3. Purchase Order (BAPI_CREATESALESORDER_FROMDAT2) Microsoft Dynamics AX SAP4. Shipment Notification (IDOC DELVRY06) SAP Microsoft Dynamics AX5. Invoice (IDOC INVOIC02) SAP Microsoft Dynamics AX6. Sales Order Confirmation (IDOC ORDERS05) SAP Microsoft Dynamics AX

4.2.1 SAP INTERFACE DEFINITIONS The system integration required for the SAP interfaces are based on SAP BAPIs (Business Application Programming Interface) and IDOCs (Intermediate Documents). A BAPI contains RFCs that are able to perform actions in the SAP system such as creating an order or to upload a financial order. For the BAPIs, there are input/output definitions, which can be imported in BizTalk using the BizTalk SAP Adapter. An IDOC is a standard SAP document that contains business data. There are many standard IDOC message types available such as Material Master, Delivery Document, and Invoice. The IDOCs are intermediate documents defined in SAP. The structure of an IDOC can also be automatically imported in BizTalk using the SAP Adapter. In this scenario, the standard SAP interfacing (IDOCs and BAPIs) is used as much as possible.

4.2.2 INTERFACE MAPPINGS All data exchange in Microsoft Dynamics AX is completed through XML data generated by AIF. The outbound data is mapped to an SAP request message by BizTalk process (BizTalk Map) and the BAPI response messages. The IDOCs are transformed to inbound XML messages through AIF.

4.3 SETTING UP BIZTALKThis section discusses the steps for setting up BizTalk for this Regional Distribution Scenario. The steps will focus on the specific configurations related to this scenario rather than the standard setup. The following are the steps initial steps for setting up BizTalk.

Step 1: Install BizTalk ServerStep 2: Add BizTalk Adapter Pack 2.0 on the Existing BizTalk 2009 InstallationStep 3: Install Microsoft Dynamics AX Adapter on BizTalk Server 2009 Server

4.3.1 PURCHASE ORDER CREATIONWhen a purchase order is created in Microsoft Dynamics AX, the user will send it electronically from the Purchase order form. The BizTalk process should be able to read the purchase order from Microsoft Dynamics AX. BizTalk should convert the Microsoft Dynamics AX purchase order to a SAP sales order and place the order in the SAP environment. The following describes the process.

The purchase order is created in Microsoft Dynamics AX and Sent electronically is selected on the form.

This will place an XML message of the purchase order in Microsoft Dynamics AX Queue.

16


The BizTalk process uses the Microsoft Dynamics AX adapter and should pick up the message from Microsoft Dynamics AX Queue by leveraging a BizTalk map.

The message is converted to a SAP sales order XML message. To place a sales order into SAP, this paper uses a SAP RFC call, BAPI_SALESORDER_CREATEFROMDAT2. From the BizTalk project (within the Visual Studio project), the message schema of this BAPI can be exposed by using the SAP Adapter pack. This will also provide the SAP Port binding which sends and receive requests to SAP.

4.3.2 BIZTALK DESIGNA Visual Studio solution is developed to implement the solution. Three projects have been created in this solution to provide the Maps, Schemas and Orchestrations.

The following table displays the schemas needed for this action:

Schema name PurposeBAPI_SALESORDER_CREATEFROMDAT2 To create a sales order in SAPPurchaseOrderService_PurchaseOrder To read/update the purchase order in AX

Please note the tRfc schema is used to call the RFC in Transactional mode. In this case, a unique ID (transaction ID) is sent after the RFC call to commit the transaction. Otherwise, SAP will not create a sales order. In return, SAP will send a confirmation of committing the transaction so the process ensures a transaction is committed. The following are the minimum requirements for fields in the XML message for calling this RFC.

ORDER_HEADER_INDOC_TYPE “TA” This is the German code for “OR” which is a standard orderSALES_ORG The SAP sales

organizationThis can be the main company set in SAP

DISTR_CHANDIVISIONREQ_DATE_HPURCH_DATEPURCH_NO_CCURRENCYORDER_ITEMS_INMATERIALPLANTTARGET_QTYTARGET_QUORDER_PARTNERSPARTN_ROLEPARTN_NUMB

The following is a sample of the XML.<BAPI_SALESORDER_CREATEFROMDAT2 xmlns="http://Microsoft.LobServices.Sap/2007/03/Rfc/"> <ORDER_HEADER_IN> <DOC_TYPE xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/">TA</DOC_TYPE>

17


<SALES_ORG xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/">BP01</SALES_ORG> <DISTR_CHAN xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/">01</DISTR_CHAN> <DIVISION xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/">01</DIVISION> <REQ_DATE_H xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/">20100729</REQ_DATE_H> <PURCH_DATE xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/">20100722</PURCH_DATE> <PURCH_NO_C xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/">123456</PURCH_NO_C> <CURRENCY xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/">USD</CURRENCY> </ORDER_HEADER_IN> <ORDER_ITEMS_IN> <BAPISDITM xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/"> <MATERIAL>000000000000000001</MATERIAL> <PLANT>BP01</PLANT>

<TARGET_QTY>1</TARGET_QTY> <TARGET_QU>EA</TARGET_QU>

</BAPISDITM> </ORDER_ITEMS_IN> <ORDER_PARTNERS> <BAPIPARNR xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/"> <PARTN_ROLE>WE</PARTN_ROLE> <PARTN_NUMB>0000100000</PARTN_NUMB> </BAPIPARNR> </ORDER_PARTNERS> <RETURN/></BAPI_SALESORDER_CREATEFROMDAT2>

4.3.3 MAPPING AX PURCHASE ORDER TO SAP SALES ORDERA BizTalk map is leveraged to convert the input schema of a Microsoft Dynamics AX purchase order to a SAP sales order. The map is straight forward since you can find the required fields easily from the purchase order. PurchTable in Microsoft Dynamics AX maps to the Sales Order Request and PurchLine in the Line Items for the sales order. The map tDaxPO_to_sapSO.btm is available in the solution provided under DistributedDistribution.Map BizTalk project. Please note the SAP administrators may need to provide details of the Sales organization otherwise the request may fail.

4.3.4 BIZTALK ORCHESTRATIONThe following will describe the BizTalk orchestration to create a SAP sales order from a Microsoft Dynamics AX purchase order. The BizTalk orchestration will be triggered when a purchase order is

18


available in the Microsoft Dynamics AX Queue. Once the message is read by the BizTalk Orchestration, it checks to determine if it’s a new purchase order. If the purchase order is new, it will convert it to a SAP sales order with document type “TA”. Otherwise, it will be transformed to a SAP sales order of type “RE” which means the items are returns. In both cases, the BAPI_SALESORDER_CREATEFROMDAT2 is called in transaction mode. If a sales order creation is successfully done, then the same purchase order XML is updated so that the AIFPurchStatus element in the XML is changed from N/A to Sales Order Sent. The PurchaseOrderService_PurchaserOrder service of Microsoft Dynamics AX Application integration framework (AIF) is called. Before calling this service, the action of the service is set to create.

The following is the code needed to call the service:DAX_PO_Update_Request._purchaseOrder = xmlPO;DAX_PO_Update_Request(DynamicsAx5.Action) = "http://schemas.microsoft.com/dynamics/2008/01/services/PurchaseOrderService/update";DAX_PO_Update_Request(DynamicsAx5.SourceEndpoint) = "RemoteEP";DAX_PO_Update_Request(DynamicsAx5.DestinationEndpoint) = "LocalEP";DAX_PO_Update_Request(DynamicsAx5.MessageId) = System.String.Format("{0:B}", System.Guid.NewGuid());

xmlPO is the original Microsoft Dynamics AX purchase order that was received from the Queue. To update AIFPurchStatus field in this message, an approach such as custom .NET assembly that can traverse this element in the XML can be used. The following is the orchestration implemented for this paper:

19


This figure displays the first part of orchestration where it reads a purchase order asynchronously from Microsoft Dynamics AX Queue and creates a new or a return sales order by calling corresponding maps.

20


This figure displays the other part of the orchestration where the BAPI_SALESORDER_CREATEFROMDAT2 TRfc transaction is called to create a sales order and commits the transaction by sending the GUID.

21


This figure displays the last step in the orchestration where the purchase order status in the XML message is updated and a synchronous action (update) is called to update the purchase order in the Microsoft Dynamics AX.

4.3.5 SALES ORDER CONFIRMATIONAfter a sales order is confirmed in SAP, a sales order confirmation should be sent to Microsoft Dynamics AX. At a minimum, this confirmation should include a sales order ID for the corresponding purchase order created in Microsoft Dynamics AX and should be used to update the status of purchaser order in AX. In addition, the status should be updated when a delivery is processed and when an invoice is issued.

The SAP IDOCs should be setup to receive sales order confirmations, pre-delivery notifications and invoices. The Partner Profile describes how to configure an endpoint in SAP so the IDOCs are sent automatically to the BizTalk port for each of the processes mentioned. The following table displays the list of IDOCs for each process. (NOTE: Please check for the current version available for each IDOC operation.)

Operation IDOC NameSales Order Confirmation http://Microsoft.LobServices.Sap/2007/03/Types/Idoc/3/ORDERS05//700

Pre-Delivery Notification http://Microsoft.LobServices.Sap/2007/03/Idoc/3/DELVRY06//700/ReceiveInvoice http://Microsoft.LobServices.Sap/2007/03/Idoc/3/INVOIC02//700/Receive

4.3.6 RECEIVING IDOCS FROM SAP

22


All processes relevant to receive IDOCs from SAP are included in the EDI.Scn1 Solutions folder. Other processes are included in the Scn1 Solution folder. The following displays the EDI.Scn1 folder.

There are three projects under the EDI.Scn.1 folder: Maps Orchestrations Schemas

The following three IDOCs are received from SAP: Sales Order Confirmation Pre-Delivery Notification Invoice

4.3.7 CREATE MESSAGE SCHEMAS The following displays the steps to create message schemas for Sales Order Confirmation, Pre-Delivery Notification, and Invoice. 1. Navigate to the Visual Studio project2. Create a new Message Schema for Receiving Sales Order Confirmation using the SAP Adapter3. Right click the DistributedDistribution.EDISchemas project4. Select Add Generated Item5. On the Add Generated Item dialog box

a. Select Consume Adapter Service under the Categories boxb. Select Consume Adapter Service under the Visual Studio Installed templates inside

Templates Box and click on Add button.6. In the Consume Adapter Service dialog box, select sapBinding from the picklist list for the

Select a binding. Provide the endpoint, Uri, in the Configure a URI section and select the Configure button.

23


BizTalk Consume Adapter Service

7. In the Configure Adapter dialog box, select the Security tab and select Client credential type: from the picklist list. This paper uses Username type. Enter the User name and Password for the SAP environment and click OK.

24


BizTalk Configure Adapter

8. In the Consume Adapter Service dialog box, click the Connect button to connect the adapter to SAP.

9. Select Service (Inbound operations) from the Select contract type picklist list. The Select a category list will be refreshed with IDOC, RFC and TRFC nodes.

a. Navigate to "MATMAS>MATMAS05>MATMAS05.V3(700)b. Receive should appear in Available Categories and Operations:c. Click Received. Select Add

10. Check the Generate Unique schema types checkbox and provide any filename prefix for the IDOCs and click OK. (This will generate the Schemas needed to receive the Sales Order Confirmation and a binding metadata. We can use the binding metadata file to configure the SAP receive port where the IDOCs are sent electronically to BizTalk.)

11. Repeat the previous steps to generate the schemas for Delivery Notification and Invoice IDOCs.

4.3.8 CREATE GENERIC SCHEMAS The following displays the steps to create generic schemas for converting incoming IDOCs to common internal Schemas for BizTalk. This paper creates an intermediate schema to update Microsoft Dynamics AX information using this schema. This schema resides in a shared assembly which is used from both EDI.Scn1 projects as well as Scn1 projects. The assembly source code is under the Common Solution. 25


4.3.9 MAPPING SAP SALES ORDER CONFIRMATION TO POSO SCHEMAThis mapping converts sales order IDOCs (ORDER05) into a POSO instance. In this case, the QUALF field in the IDOCs under E2EDK02. If QUALF is equal 001, then the BELNR is the purchase order number. If the QUALF is equal 002, then the BELNR is the sales order number. The value of the POSO status field is changed to Sales Order Confirmed by using a concatenate function.

BizTalk Mapping Tool – Sales Order Confirmation.

26


4.3.10 MAPPING SAP SALES DELIVERY CONFIRMATION TO POSO SCHEMAIn this map, the POSO status field is changed to SalesOrderShipped and specifies the Quantity Now. This field can be used for partial delivery.

BizTalk Mapping Tool – Sales Delivery Confirmation.

4.3.11 INVOICE IDOCSBELNR (under E2EDK01005) is used. This contains the Invoice number from SAP and the Status Number is set to Invoiced.

27


BizTalk Mapping Tool – Invoice.

4.3.12 ORCHESTRATIONThe EDI Orchestrations are basically receiving IDOCs, sending IDOCs, and receiving confirmations in the SAP environment.

28


BizTalk Orchestration Scenario.

After the IDOCs are received from SAP endpoint, the response type can be set in the message assignment. In the first expression shape, the Received message to the TempXMLData is of type System.XML.XmlDocument. This XML data is used in the message assignment shape to create the Response Message which is a confirmation for the receiving of IDOCs.

Response = TempXMLData;Response(WCF.Action)= "http://Microsoft.LobServices.Sap/2007/03/Idoc/3/ORDERS05//700/Receive/response";

The same approach is used for the other two IDOCs which update the pre-delivery notification, invoice status, and IDs in the Microsoft Dynamics AX purchase order.

4.3.13 DEPLOYING FOR REGIONAL DISTRIBUTION SCENARIOIn this paper, a shared assembly has been created in Visual Studio which contains the internal Schema “POSO”. This schema is used in both Scn1 and EDI.Scn1 assemblies. Hence, a shared BizTalk application on BizTalk server, called SharedSchemas has been created. This is the only artifact it has for the POSO schema. Both EDI.Scenario1.DistributedDistribution and Scenario1.DistributedDistribution have added a reference to this application.

29


BizTalk Shared Schemas

4.3.14 CREATING SAP RECEIVE PORTS FOR IDOCsThe Binding file can be imported using mySAP adapter to create a receive port. However, a program ID must be provided for each IDOC in the endpoint configuration. These programId are defined at the SAP RFC Destination. Once the receive port for each IDOC is created, the port should be enabled so that SAP environment can find the endpoint. Otherwise, the SAP environment will not be able to find and send the endpoint and will display errors despite correct configurations.

Another important part of configuration includes setting the IDOCs type as Typed when reading IDOCs. Otherwise, the BizTalk adapter won’t recognize the schema type and won’t be able to find right subscriber. The following is a sample SAP endpoint URI that needs to be used to add a new receiving port/location for SAP IDOCs:

sap://Client=914;lang=EN@A/hcsap2950-1/01?ListenerGwHost=hcsap2950-1&ListenerGwServ=sapgw01&ListenerProgramId=salesOrderConfirmation

The ListenerGwHost, ListenerGwServ, and ListenerProgramId should be configured in the URI. Otherwise, the endpoint will fail to receive IDOCs.

The following displays the configuration needed on the SAP receive port to import a typed IDOC:

30


5. SCENARIO DETAILS

5.1 SCENARIO #1: CENTRAL ORGANIZATION IS PROVIDING GOODS TO ITS DISTRIBUTION SUBSIDIARY

A large company is running a different legacy system in its central operation and in some of its distribution facilities. This is a typical retail/distribution scenario where regional stores/distribution centers are replenished by central organization. Microsoft Dynamics AX is operated for the regional stores/distribution centers and the central distribution facility is the supplier. The regional stores/distribution centers can be considered as internal customers. This would also apply with a franchise that is operated with Microsoft Dynamics AX.

31


Scenario description: Regional stores/distribution centers generate purchase order of goods to replenish. The items in the regional stores/distribution centers are considered to be purchased from a

vendor which is the central organization. o In this case, the regional stores/distribution centers send a purchase order to the

central organization. At the central organization level, the purchase order becomes a sales order as it would be

delivered to a customer. Delivery and returns can be handled. Financials will follow the regular intercompany billing rules.

The following displays the scenario transactions that will be detailed in the following sections.

5.1.1 SYNCHRONIZATION OF ITEMS AND PRICE LIST The following two IDOCs are sent to BizTalk from SAP.

Price List Material Master

BizTalk transforms the files to the Item Master schema file to be readable by AIF in Microsoft Dynamics AX.

The item prices are created automatically when using AIF. This requires assigning a Costing Version to each generated record to ensure a default value for this purpose. The following is the navigation in Microsoft Dynamics AX: Inventory management> Item details> Price button. In addition, the Version field can be set with the following navigation: Inventory management>Setup>Parameters.

The following displays the Inventory parameters form in Microsoft Dynamics AX:

32


5.1.2 TRANSFORM PURCHASE ORDER INTO SALES ORDERThe purchase order is placed in the Gateway queue through AIF processing service in Microsoft Dynamics AX after the purchase order has been successfully created and sent electronically.

Step 1: Open the Account Payable module and the Purchase Order Details form.

The following displays a new purchase order in Microsoft Dynamics AX.

33


Step 2: Click Send electronically button on the header section and select the following: Select RemoteEP in the Endpoint ID field to specify where the document should go in

BizTalk. Select the purchase order number in the Purchase Order field.

Step 3: Click OK to add an unprocessed XML file for this purchase order to the Gateway queue. The Gateway queue is accessible from Basic>Periodic>Application Integration Framework> Queue manager.

The following displays the Queue manager form:

34


Step 4: The entry can be completed through a batch process or the following job to execute immediately. Run the job called runAIFSync to process the message in queue to be picked up by BizTalk.

After the job runAIFSync is run, the following fields are set: Channel Source endpoint

The message is now ready to be picked up by BizTalk. After the purchase order is send electronically, the message will be an outbound message and can be consumed by any external system including the BizTalk server.

The following displays the Queue manager with the Channel and Source endpoint fields set:

35


BizTalk also refers to the Gateway queue to periodically check for any messages available. The Gateway queue will read the message into the BizTalk message box. If the message is known to BizTalk, then BizTalk will start processing the message. In this scenario, the BizTalk server will receive a purchase order from the Gateway queue. BizTalk is configured to work with the purchase order schema and picks up the purchase order message.

The BAPI used in this transaction is BAPI_SALESORDER_CREATEFROMDAT2.

The following displays the orchestration of the purchase order:

36


BizTalk transforms the outbound Microsoft Dynamics AX purchase order into an inbound sales order message and calls the standard SAP BAPI to create the sales order in SAP.

Once the sales order is created, SAP users can process and confirm the sales order so a sales order confirmation can be sent to external parties.

5.1.3 TRANSMIT ORDER, ITEM/QUANTITY, DATE CONFIRMATIONThe SAP environment must be setup to send a IDOCs to BizTalk Logical System for sales order confirmation. The IDOCs will be sent to BizTalk which is listening to the SAP endpoint. The name of this IDOC is BA00 and contains the item, quantity, and date confirmation corresponding to the sales order.

The sales order confirmation includes the purchase order ID created by the sales office. BizTalk can use this purchase order ID to correlate the sales order confirmation to a purchase order in Microsoft Dynamics AX. BizTalk extracts the purchase order from Microsoft Dynamics AX and then updates the Corporate ERP field to “Sales order confirmed”. The following displays the updated Microsoft Dynamics AX Purchase order form with the Corporate ERP field equal to Sales order confirmed.

37


Microsoft Dynamics AX Purchase Order Screen – Sales Order is confirmed.

5.1.4 UPDATE SALES ORDER STATUS AND QUANTITIES (GOOD RETURN TO SALES RETURN)

Goods return would indicate the quantity of items received that are defective or damaged. For example, two items were defective and require a return while five items were ordered. A Microsoft Dynamics AX purchase order (return) would be returned to SAP with a negative quantity indicating the defective or damaged items. In SAP, the original sales order and the return order can be linked if the returns order is created with reference to the original sales order. The document flow assigns the original purchase order to the returns order. The original purchase order quantities for the individual goods are proposed automatically but can be changed for the proposed quantities, if necessary.

The process for the returns delivery on the returns order is slightly different. The delivery quantities in the returns delivery must correspond to the goods issue quantities in the goods issue document that was posted incorrectly.

In the next step, the Post "goods issue" (PGI) for the returns delivery is completed. The system automatically recognizes the returns delivery as goods receipt and clears the original goods issue posting by carrying out the reverse posting.

Please refer to section 5.1.2 for procedures. The procedures are the same except for the name of the BAPI type, BAPI_SALESORDER_CREATEFROMDAT2 with return type ‘RE’. A sales order with a new number range configured for the 'RE' order type gets created when the field DOC_TYPE in the header table for the BAPI is given the value 'RE’.

5.1.5 SEND INVOICEAfter the sales order is processed in SAP, an invoice will be issued for the sales office which will send an IDOC to BizTalk with billing details. The BizTalk will extract the corresponding purchase order and updates the Corporate ERP field. The following displays the Microsoft Dynamics AX Purchase order form with the Corporate ERP field set to Invoiced.

38


Microsoft Dynamics AX Purchase Order Screen – Purchase Order is invoiced.

6. CONCLUSIONThe Regional Distribution scenario detailed the Two-Tier ERP deployment approach where a large corporation would use a Tier 1 financial application such as Oracle or SAP to run its headquarters. The smaller entities such as subsidiaries, divisions, branches, departments, lines of businesses would standardize to use Microsoft Dynamics AX. Microsoft Dynamics AX allows the smaller entities to run their business processes with a globally available industry ready solution to take advantage its ease of use, flexibility, scalability, quick implementation and training that result in lower cost of ownership.

To take full advantage of this Two-Tier implementation strategy, Microsoft Dynamics AX proposes to directly connect to the corporate ERP system to streamline cross entity collaboration. This realistic scenario can be used as a template for implementations if the organization wants to connect local entities to the corporate ERP solution across Microsoft Dynamics AX and SAP.

39


40


The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, this document should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2010 Microsoft Corporation. All rights reserved.

Microsoft, Microsoft Dynamics, the Microsoft Dynamics logo, and [list all other Microsoft trademarks cited in the document, in alphabetical order. The trademark information that is included is dependent upon the content of the white paper. Visit http://lcaweb/default.htm to determine what products are trademarked.] are trademarks of the Microsoft group of companies.

Microsoft Dynamics is a line of integrated, adaptable business management solutions that enables you and your people to make business decisions with greater confidence. Microsoft Dynamics works like and with familiar Microsoft software, automating and streamlining financial, customer relationship, and supply chain processes in a way that helps you drive business success.

U.S. and Canada Toll Free (888) 477-7989Worldwide (1) (701) 281-6500www.microsoft.com/dynamics

http://lcaweb/default.htm