INTRODUCTION



-914400-1142365Microsoft Dynamics AXIntegration of SAP andMicrosoft Dynamics AX withMicrosoft BizTalk? ServerRegional Distribution Scenario: Parent company sells products to the sales officeWhite PaperThis 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, 2010dynamics/ax TOC \o "1-3" \h \z \u 1.INTRODUCTION PAGEREF _Toc274051437 \h 41.1BUSINESS TRANSACTIONS PAGEREF _Toc274051438 \h 41.1.1PURCHASE ORDER FROM MICROSOFT DYNAMICS AX TO SAP PAGEREF _Toc274051439 \h 51.1.2SHIPPING NOTIFICATION AND DELIVERY FROM SAP TO MICROSOFT DYNAMICS AX PAGEREF _Toc274051440 \h 51.1.3INVOICE DOCUMENT FROM SAP TO MICROSOFT DYNAMICS AX PAGEREF _Toc274051441 \h 52.SYSTEM SETTINGS AND MASTER DATA PAGEREF _Toc274051442 \h 62.1SAP CUSTOMIZATIONS PAGEREF _Toc274051443 \h 62.1.1CUSTOMIZING THE ORGANIZATIONAL STRUCTURE IN SAP PAGEREF _Toc274051444 \h 62.1.2CUSTOMIZING “SALES & DISTRIBUTION” IN SAP PAGEREF _Toc274051445 \h 72.1.3CUSTOMIZING “LOGISTICS EXECUTION” IN SAP PAGEREF _Toc274051446 \h 92.2SAP MASTER DATA PAGEREF _Toc274051447 \h 92.2.1SALES OFFICES AS CUSTOMERS TO PARENT COMPANY PAGEREF _Toc274051448 \h 92.2.2SALES OFFICES AS COMPANY CODES IN SAP PAGEREF _Toc274051449 \h 92.2.3PRODUCTS USED IN TRANSACTIONS PAGEREF _Toc274051450 \h 102.2.4PRICE LISTS PAGEREF _Toc274051451 \h 102.2.5CHART OF ACCOUNTS PAGEREF _Toc274051452 \h 102.3SETTING UP MICROSOFT DYNAMICS AX PAGEREF _Toc274051453 \h 102.3.1POST INSTALLATION SETUP PAGEREF _Toc274051454 \h 102.3.2CONFIGURING AIF ENDPOINT ID PAGEREF _Toc274051455 \h 122.3.3MICROSOFT DYNAMICS AX CUSTOMIZATIONS PAGEREF _Toc274051456 \h 123.MASTER DATA UPLOAD TO MICROSOFT DYNAMICS AX PAGEREF _Toc274051457 \h 133.1IDOC SETUP FOR MASTER DATA TRANSFER PAGEREF _Toc274051458 \h 144.MICROSOFT BIZ TALK SERVER PAGEREF _Toc274051459 \h 144.1INTERFACING TO AND FROM SAP PAGEREF _Toc274051460 \h 154.2INTERFACES PAGEREF _Toc274051461 \h 154.2.1SAP INTERFACE DEFINITIONS PAGEREF _Toc274051462 \h 154.2.2INTERFACE MAPPINGS PAGEREF _Toc274051463 \h 154.3SETTING UP BIZTALK PAGEREF _Toc274051464 \h 164.3.1PURCHASE ORDER CREATION PAGEREF _Toc274051465 \h 164.3.2BIZTALK DESIGN PAGEREF _Toc274051466 \h 164.3.3MAPPING AX PURCHASE ORDER TO SAP SALES ORDER PAGEREF _Toc274051467 \h 184.3.4BIZTALK ORCHESTRATION PAGEREF _Toc274051468 \h 184.3.5SALES ORDER CONFIRMATION PAGEREF _Toc274051469 \h 214.3.6RECEIVING IDOCS FROM SAP PAGEREF _Toc274051470 \h 214.3.7CREATE MESSAGE SCHEMAS PAGEREF _Toc274051471 \h 224.3.8CREATE GENERIC SCHEMAS PAGEREF _Toc274051472 \h 244.3.9MAPPING SAP SALES ORDER CONFIRMATION TO POSO SCHEMA PAGEREF _Toc274051473 \h 254.3.10MAPPING SAP SALES DELIVERY CONFIRMATION TO POSO SCHEMA PAGEREF _Toc274051474 \h 264.3.11INVOICE IDOCS PAGEREF _Toc274051475 \h 264.3.12ORCHESTRATION PAGEREF _Toc274051476 \h 274.3.13DEPLOYING FOR REGIONAL DISTRIBUTION SCENARIO PAGEREF _Toc274051477 \h 284.3.14CREATING SAP RECEIVE PORTS FOR IDOCs PAGEREF _Toc274051478 \h 295.SCENARIO DETAILS PAGEREF _Toc274051479 \h 305.1SCENARIO #1: CENTRAL ORGANIZATION IS PROVIDING GOODS TO ITS DISTRIBUTION SUBSIDIARY PAGEREF _Toc274051480 \h 305.1.1SYNCHRONIZATION OF ITEMS AND PRICE LIST PAGEREF _Toc274051481 \h 315.1.2TRANSFORM PURCHASE ORDER INTO SALES ORDER PAGEREF _Toc274051482 \h 325.1.3TRANSMIT ORDER, ITEM/QUANTITY, DATE CONFIRMATION PAGEREF _Toc274051483 \h 365.1.4UPDATE SALES ORDER STATUS AND QUANTITIES (GOOD RETURN TO SALES RETURN) PAGEREF _Toc274051484 \h 375.1.5SEND INVOICE PAGEREF _Toc274051485 \h 376.CONCLUSION PAGEREF _Toc274051486 \h 38INTRODUCTIONLarge 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.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.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.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. 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 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.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.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. 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.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: SPROSAP Implementation guide: Enterprise Structure- DefinitionIMG AreaActivityDescriptionFinancial AccountingDefine company code CUSCreate 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 CEUThe 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- GeneralDefine plant CUSCreate a site which represents the operating area of the parent companyDefine division 00A division is an organizational part of the sales area through which products are sold to customers.Sales & DistributionDefine Sales Organization CUSAll sales are registered on this organizational level.Define Distribution Channel 12Part of sales area.Materials ManagementDefine Storage Location 0001Physical location where stock is kept.Logistics ExecutionDefine Shipping Point CUSPoint from which deliveries leave the plant.SAP Transaction: SPROSAP Implementation guide: Enterprise Structure- AssignmentIMG AreaActivityDescriptionFinancial AccountingAssign company code CUS to credit control area 1000Credit control area 1000 is the standard IDES control area for Europe.ControllingAssign company code CUS tocontrolling area 1000Activate 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- GeneralAssign plant CUS to company code CUSA plant belongs to one company codeSales & DistributionAssign sales organization CUS to company code CUSLink financial accounting (company code level) to the sales activities.Assign distribution channel 12 to sales organization CUSDistribution 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/00Assign sales organization –distribution channel – plantDefine the plant that will provide goods for the sales area.Logistics ExecutionAssign shipping point CUS to plantCUSA shipping point is part of a plant.SAP Transaction FS00Change reconciliation account for vendorReconciliation 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.CUSTOMIZING “SALES & DISTRIBUTION” IN SAPThe following three sales documents are used in the scenario:Sales order confirmationSales invoiceDelivery NoteThe 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.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 ConfirmationORStandard OrderBA00Order ConfirmationV10000Order OutputORDRSPPurchase order / order confirmationORDERS05Purchasing/SalesAs 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 InvoicesBilling TypeF2InvoiceOutput typeRD00InvoiceOutput Determination ProcedureV10000Billing OutputMessage TypeINVOICInvoice/Billing DocumentBasic TypeINVOIC01Invoice/Billing documentCUSTOMIZING “LOGISTICS EXECUTION” IN SAPThe 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.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.SALES OFFICES AS CUSTOMERS TO PARENT COMPANYCustomer master recordCEUIn 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.SALES OFFICES AS COMPANY CODES IN SAPCompany codeCEUSales 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.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 records000000000000000001000000000000000012000000000000000015000000000000000016000000000000000017000000000000000018000000000000000019PRICE 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. 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 AccountsINTSETTING 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.POST INSTALLATION SETUP Setup Microsoft BizTalk ManagementIn Microsoft Dynamics AX, go to Basic>Setup> Application Integration Framework>Global settings to open the Integration Framework global settings formSelect Ignore ‘Record Version’ for updates fieldBy 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.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: NoneCancelledSalesOrderConfirmedSalesOrderSentSalesOrderShippedReceivedInvoicedBackorderReceiptsListPurchaseOrderShippedQtyUpdatedPayInvoicedSalesOrderReturnedCurrently, a trigger is setup for the following Corporate ERP field values:PurchaseOrder: Do “Purchase Order” postingSalesOrderConfirmed: Do “Purchase Order” postingInvoiced: Do “Invoice” postingNOTE: The other values can be used as placeholders to attach actions to them.The following is an additional setup step: 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.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.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.The following shows the window when the Send electronically button is selected.Microsoft Dynamics AX Send Document Electronically Screen.MASTER DATA UPLOAD TO MICROSOFT DYNAMICS AXFor this scenario, the Item Master and its inter-company price only are interfaced with Microsoft Dynamics AX.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. (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)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.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. INTERFACESThe interfaces for the Microsoft Dynamics ERP Two-Tier Connector are summarized below:InterfaceSourceDestination1. Materials (IDOC MATMAS05)SAPMicrosoft Dynamics AX2. Customers (IDOC DEBMAS03)SAPMicrosoft Dynamics AX3. Purchase Order (BAPI_CREATESALESORDER_FROMDAT2)Microsoft Dynamics AXSAP4. Shipment Notification (IDOC DELVRY06)SAPMicrosoft Dynamics AX5. Invoice (IDOC INVOIC02)SAPMicrosoft Dynamics AX6. Sales Order Confirmation (IDOC ORDERS05)SAPMicrosoft Dynamics AXSAP 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. 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.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 ServerPURCHASE 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.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 TALK 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 namePurposeBAPI_SALESORDER_CREATEFROMDAT2To create a sales order in SAPPurchaseOrderService_PurchaseOrderTo read/update the purchase order in AXPlease 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_ORGThe SAP sales organizationThis can be the main company set in SAPDISTR_CHANDIVISIONREQ_DATE_HPURCH_DATEPURCH_NO_CCURRENCYORDER_ITEMS_INMATERIALPLANTTARGET_QTYTARGET_QUORDER_PARTNERSPARTN_ROLEPARTN_NUMBThe following is a sample of the XML.<BAPI_SALESORDER_CREATEFROMDAT2 xmlns=""> <ORDER_HEADER_IN> <DOC_TYPE xmlns="">TA</DOC_TYPE> <SALES_ORG xmlns="">BP01</SALES_ORG> <DISTR_CHAN xmlns="">01</DISTR_CHAN> <DIVISION xmlns="">01</DIVISION> <REQ_DATE_H xmlns="">20100729</REQ_DATE_H> <PURCH_DATE xmlns="">20100722</PURCH_DATE> <PURCH_NO_C xmlns="">123456</PURCH_NO_C> <CURRENCY xmlns="">USD</CURRENCY> </ORDER_HEADER_IN> <ORDER_ITEMS_IN> <BAPISDITM xmlns=""> <MATERIAL>000000000000000001</MATERIAL> <PLANT>BP01</PLANT> <TARGET_QTY>1</TARGET_QTY> <TARGET_QU>EA</TARGET_QU> </BAPISDITM> </ORDER_ITEMS_IN> <ORDER_PARTNERS> <BAPIPARNR xmlns=""> <PARTN_ROLE>WE</PARTN_ROLE> <PARTN_NUMB>0000100000</PARTN_NUMB> </BAPIPARNR> </ORDER_PARTNERS> <RETURN/></BAPI_SALESORDER_CREATEFROMDAT2>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 TALK 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 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) = "";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:?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.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.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.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.)OperationIDOC NameSales Order Confirmation Notification IDOCS FROM SAPAll 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:MapsOrchestrationsSchemasThe following three IDOCs are received from SAP: Sales Order ConfirmationPre-Delivery Notification InvoiceCREATE MESSAGE SCHEMAS The following displays the steps to create message schemas for Sales Order Confirmation, Pre-Delivery Notification, and Invoice. Navigate to the Visual Studio projectCreate a new Message Schema for Receiving Sales Order Confirmation using the SAP AdapterRight click the DistributedDistribution.EDISchemas projectSelect Add Generated ItemOn the Add Generated Item dialog boxSelect Consume Adapter Service under the Categories boxSelect Consume Adapter Service under the Visual Studio Installed templates inside Templates Box and click on Add button.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 Talk Consume Adapter ServiceIn 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 Talk Configure Adapter In the Consume Adapter Service dialog box, click the Connect button to connect the adapter to SAP.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.Navigate to "MATMAS>MATMAS05>MATMAS05.V3(700)Receive should appear in Available Categories and Operations: Click ReceiveSelect AddCheck 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.) Repeat the previous steps to generate the schemas for Delivery Notification and Invoice IDOCs.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. 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 Talk Mapping Tool – Sales Order Confirmation.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 Talk Mapping Tool – Sales Delivery Confirmation.INVOICE IDOCSBELNR (under E2EDK01005) is used. This contains the Invoice number from SAP and the Status Number is set to Talk Mapping Tool – Invoice.ORCHESTRATIONThe EDI Orchestrations are basically receiving IDOCs, sending IDOCs, and receiving confirmations in the SAP Talk 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)= "";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.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 Talk Shared SchemasCREATING 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=salesOrderConfirmationThe 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:SCENARIO DETAILS SCENARIO #1: CENTRAL ORGANIZATION IS PROVIDING GOODS TO ITS DISTRIBUTION SUBSIDIARYA 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. 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. 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.SYNCHRONIZATION OF ITEMS AND PRICE LIST The following two IDOCs are sent to BizTalk from SAP.Price ListMaterial MasterBizTalk 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: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.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: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:ChannelSource endpointThe 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: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: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. 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.Microsoft Dynamics AX Purchase Order Screen – Sales Order is confirmed.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’.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.Microsoft Dynamics AX Purchase Order Screen – Purchase Order is invoiced.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.-711205422265The 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 plying 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 to determine what products are trademarked.] are trademarks of the Microsoft group of companies. 00The 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 plying 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 to determine what products are trademarked.] are trademarks of the Microsoft group of companies. -1187453493135Microsoft 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-6500dynamics00Microsoft 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-6500dynamics5029200863219040373309098280 00 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download