You are on page 1of 39
Integration of SAP and Microsoft Dynamics AX with Microsoft BizTalk® Server Regional Distribution Scenario: Parent
Integration of SAP and Microsoft Dynamics AX with Microsoft BizTalk® Server Regional Distribution Scenario: Parent

Integration of SAP and Microsoft Dynamics AX with Microsoft BizTalk® Server

Regional Distribution Scenario:

Parent company sells products to the sales office

White 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 between Microsoft® 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

by Microsoft Corporation in collaboration with Hitachi Consulting. Date: September, 2010 www.microsoft.com/dynamics/ax

1.

INTRODUCTION

4

1. INTRODUCT ION 4 1.1 BUSINESS TRANSACTIONS 4 1.1.1 PURCHASE ORDER FROM MICROSO FT DYNAMICS AX

1.1

BUSINESS TRANSACTIONS

4

1.1.1

PURCHASE ORDER FROM MICROSOFT DYNAMICS AX TO SAP

5

1.1.2

SHIPPING NOTIFICATION AND DELIVERY FROM SAP TO MICROSOFT DYNAMICS AX 5

1.1.3

INVOICE DOCUMENT FROM SAP TO MICROSOFT DYNAMICS AX

5

2.

SYSTEM SETTINGS AND MASTER DATA

6

2.1

SAP CUSTOMIZATIONS

6

2.1.1

CUSTOMIZING THE ORGANIZATIONAL STRUCTURE IN SAP

6

2.1.2

CUSTOMIZING “SALES & DISTRIBUTION” IN SAP

7

2.1.3

CUSTOMIZING “LOGISTICS EXECUTION” IN SAP

9

2.2

SAP MASTER DATA

9

2.2.1

SALES OFFICES AS CUSTOMERS TO PARENT COMPANY

9

2.2.2

SALES OFFICES AS COMPANY CODES IN SAP

9

2.2.3

PRODUCTS USED IN TRANSACTIONS

10

2.2.4

PRICE LISTS

10

2.2.5

CHART OF ACCOUNTS

10

2.3

SETTING UP MICROSOFT DYNAMICS AX

10

2.3.1

POST INSTALLATION SETUP

10

2.3.2

CONFIGURING AIF ENDPOINT ID

12

2.3.3

MICROSOFT DYNAMICS AX CUSTOMIZATIONS

12

3. MASTER DATA UPLOAD TO MICROSOFT DYNAMICS AX

3.1 IDOC SETUP FOR MASTER DATA TRANSFER

4. MICROSOFT BIZ TALK SERVER

13

14

14

4.1

INTERFACING TO AND FROM SAP

15

4.2

INTERFACES

15

4.2.1

SAP INTERFACE DEFINITIONS

15

4.2.2

INTERFACE MAPPINGS

15

4.3

SETTING UP BIZTALK

16

4.3.1

PURCHASE ORDER CREATION

16

4.3.2

BIZTALK DESIGN

16

4.3.3

MAPPING AX PURCHASE ORDER TO SAP SALES ORDER

18

4.3.4

BIZTALK ORCHESTRATION

18

4.3.5

SALES ORDER CONFIRMATION

21

4.3.6

RECEIVING IDOCS FROM SAP

21

4.3.7

CREATE MESSAGE SCHEMAS

22

4.3.8

CREATE GENERIC SCHEMAS

24

4.3.9

MAPPING SAP SALES ORDER CONFIRMATION TO POSO SCHEMA

25

4.3.10

MAPPING SAP SALES DELIVERY CONFIRMATION TO POSO SCHEMA

26

4.3.11

INVOICE IDOCS

26

4.3.12

ORCHESTRATION

27

4.3.13

DEPLOYING FOR REGIONAL DISTRIBUTION SCENARIO

28

4.3.14

CREATING SAP RECEIVE PORTS FOR IDOCs

29

2

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

5.

SCENARIO DETAILS

30

5. SCENARIO DETAILS 30 5.1 SCENARIO #1: CENTRAL ORGANIZATION IS PROVIDING GOODS TO ITS DISTRIBUTION SUBSIDIARY

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

SUBSIDIARY

30

5.1.1 SYNCHRONIZATION OF ITEMS AND PRICE LIST

31

5.1.2 TRANSFORM PURCHASE ORDER INTO SALES ORDER

32

5.1.3 TRANSMIT ORDER, ITEM/QUANTITY, DATE CONFIRMATION

36

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

RETURN)

37

5.1.5

SEND INVOICE

37

6. CONCLUSION

3

38

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

1.

INTRODUCTION

1. INTRODUCTION Large enterprises consist of multiple small entitie s such as subsidiaries, branches, locations, and

Large 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.

sales office and parent are shown in the figure below. 4 MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR

4

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

In this scenario, the SAP parent and Microsoft Dynamics AX sales office essentially have a

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 SAP

In 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 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 AX

Since 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.

5

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

2.

SYSTEM SETTINGS AND MASTER DATA

2. SYSTEM SETTINGS AND MASTER DATA The business transactions described above depend on system settings and

The 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 CUSTOMIZATIONS

In 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 SAP

A 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

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

6

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

SAP Implementation guide: Enterprise Structure- Assignment IMG Area Activity Description Financial

SAP Implementation guide: Enterprise Structure- Assignment

IMG Area

Activity

Description

Financial Accounting

Assign company code CUS to credit control area 1000

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

Controlling

Assign company code CUS to controlling 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 sales organization CUS

Set up sales area CUS/12/00

Assign sales organization – distribution channel – plant

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

Logistics Execution

Assign shipping point CUS to plant CUS

A

shipping point is part of a plant.

SAP Transaction FS00

Change 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 SAP

The following three sales documents are used in the scenario:

Sales order confirmation

Sales invoice

Delivery Note

7

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

The sales order confirmation, delivery note and the sales invoice used in the scenario are

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.

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 Order

BA00

Order Confirmation

V10000

Order Output

ORDRSP

Purchase order / order confirmation

ORDERS05

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

8

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

Billing Type F2 Invoice Output type RD00 Invoice Output Determination Procedure V10000 Billing

Billing Type

F2

Invoice

Output type

RD00

Invoice

Output Determination Procedure

V10000

Billing Output

Message Type

INVOIC

Invoice/Billing Document

Basic 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 DATA

Besides 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

Customer master record

Customer master record CEU

CEU

Customer master record CEU
Customer master record CEU

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

Company code

Company code CEU

CEU

Company code CEU
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.

9

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

2.2.3

PRODUCTS USED IN TRANSACTIONS

2.2.3 PRODUCTS USED IN TRANSACTIONS The following table displays the material master records that have been

The 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

000000000000000001

 

000000000000000012

 

000000000000000015

 

000000000000000016

 

000000000000000017

 

000000000000000018

 

000000000000000019

2.2.4 PRICE LISTS

One 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 ACCOUNTS

The 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

Chart of Accounts

Chart of Accounts INT

INT

Chart of Accounts INT
Chart of Accounts INT

2.3 SETTING UP MICROSOFT DYNAMICS AX

The 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.

10

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

AIF Global Settings. A trigger can be set for all or some of the Corporate
AIF Global Settings. A trigger can be set for all or some of the Corporate

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:

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

11

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

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

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.

total line amounts are copied from the incoming AIF file. AIF Account Payable Parameters. 2.3.2 CONFIGURING

AIF Account Payable Parameters.

2.3.2 CONFIGURING AIF ENDPOINT ID

The 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 CUSTOMIZATIONS

Four 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.

12

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

The Send electronically button has been added to the Purchase order form to send the

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.

form with the Send electronically button in the header. Microsoft Dynamics AX Purchase Order. The following

Microsoft Dynamics AX Purchase Order.

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

window when the Send electronically button is selected. Microsoft Dynamics AX Send Document Electronically Screen.

Microsoft Dynamics AX Send Document Electronically Screen.

3. MASTER DATA UPLOAD TO MICROSOFT DYNAMICS AX

For this scenario, the Item Master and its inter-company price only are interfaced with Microsoft Dynamics AX.

13

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

3.1

IDOC SETUP FOR MASTER DATA TRANSFER

3.1 IDOC SETUP FOR MASTER DATA TRANSFER A partner profile should be created in SAP system

A 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 SERVER

The 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.

between SAP, BizTalk, and Microsoft Dynamics AX. 14 MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL

14

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

4.1

INTERFACING TO AND FROM SAP

4.1 INTERFACING TO AND FROM SAP There are two interfacing methods used:  IDOC: Outbound IDOCs

There 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 than BAPIs 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.

4.2 INTERFACES

The interfaces for the Microsoft Dynamics ERP Two-Tier Connector are summarized below:

Interface

Source

Destination

1. Materials (IDOC MATMAS05)

SAP

Microsoft Dynamics AX

2. Customers (IDOC DEBMAS03)

SAP

Microsoft Dynamics AX

3. Purchase Order (BAPI_CREATESALESORDER_FROMDAT2)

Microsoft Dynamics AX

SAP

4. Shipment Notification (IDOC DELVRY06)

SAP

Microsoft Dynamics AX

5. Invoice (IDOC INVOIC02)

SAP

Microsoft Dynamics AX

6. 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.

15

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

4.3

SETTING UP BIZTALK

4.3 SETTING UP BIZTALK This section discusses the steps for setting up BizTalk for this Regional

This 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 Server Step 2: Add BizTalk Adapter Pack 2.0 on the Existing BizTalk 2009 Installation Step 3: Install Microsoft Dynamics AX Adapter on BizTalk Server 2009 Server

4.3.1 PURCHASE ORDER CREATION

When a purchase order is created in Microsoft Dynamics AX, the user will send it electronically from

the Purchase order form.

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 BizTalk process should be able to read the purchase order from

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 SAP.

4.3.2

BIZTALK DESIGN

A 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

Purpose

BAPI_SALESORDER_CREATEFROMDAT2

To create a sales order in SAP

PurchaseOrderService_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_IN

DOC_TYPE

“TA”

This is the German code for “OR” which is a standard order

SALES_ORG

The SAP sales organization

This can be the main company set in SAP

DISTR_CHAN

DIVISION

16

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

REQ_DATE_H PURCH_DATE PURCH_NO_C CURRENCY ORDER_ITEMS_IN MATERIAL PLANT TARGET_QTY

REQ_DATE_H

PURCH_DATE

PURCH_NO_C

CURRENCY

ORDER_ITEMS_IN

MATERIAL

PLANT

TARGET_QTY

TARGET_QU

ORDER_PARTNERS

PARTN_ROLE

PARTN_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>

<SALES_ORG

xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/">BP01</SALES_OR

G>

<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</PURC

H_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>

17

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

</ BAPIPARNR > </ ORDER_PARTNERS > < RETURN /> </ BAPI_SALESORDER_CREATEFROMDAT2 > 4.3.3

</BAPIPARNR> </ORDER_PARTNERS> <RETURN/>

</BAPI_SALESORDER_CREATEFROMDAT2>

4.3.3 MAPPING AX PURCHASE ORDER TO SAP SALES ORDER

A

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 ORCHESTRATION

The 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.

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.

In both cases, the

The following is the code needed to call the service:

DAX_PO_Update_Request

DAX_PO_Update_Request(DynamicsAx5.Action) =

purchaseOrder

= xmlPO;

"http://schemas.microsoft.com/dynamics/2008/01/services/PurchaseOrderServi

ce/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:

18

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

This figure displays the first part of orchestrat ion where it reads a purchase order
This figure displays the first part of orchestrat ion where it reads a purchase order

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.

19

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

This figure displays the other part of the orchestration where the BAPI_SALESORDER_CREATEFROMDAT2 TRfc transaction is
This figure displays the other part of the orchestration where the BAPI_SALESORDER_CREATEFROMDAT2 TRfc transaction is

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.

20

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

This figure displays the last step in the orchestr ation where the purchase order status
This figure displays the last step in the orchestr ation where the purchase order status

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 CONFIRMATION

After 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 Name

Sales 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/Receive

Invoice

http://Microsoft.LobServices.Sap/2007/03/Idoc/3/INVOIC02//700/Receive

4.3.6 RECEIVING IDOCS FROM SAP

21

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

All processes relevant to receive IDOCs from SAP are included in the EDI.Scn1 Solutions folder.

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.

folder. The following displays the EDI.Scn1 folder. There are three projects under the EDI.Scn.1 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 project

2. Create a new Message Schema for Receiving Sales Order Confirmation using the SAP Adapter

3. Right click the DistributedDistribution.EDISchemas project

4. Select Add Generated Item

5. On the Add Generated Item dialog box

a. Select Consume Adapter Service under the Categories box

b. 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.

22

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

BizTalk Consume Adapter Service 7. In the Configure Adapter dialog box, select the Security tab
BizTalk Consume Adapter Service 7. In the Configure Adapter dialog box, select the Security tab

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.

23

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

BizTalk Configure Adapter 8. In the Consume Adapter Service dialog box, click the Connect button
BizTalk Configure Adapter 8. In the Consume Adapter Service dialog box, click the Connect button

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 Receive

d. 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

24

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

which is used from both EDI.Scn1 projects as well as Scn1 projects. The assembly source

which is used from both EDI.Scn1 projects as well as Scn1 projects. The assembly source code is under the Common Solution.

The assembly source code is under the Common Solution. 4.3.9 MAPPING SAP SALES ORDER CONF IRMATION

4.3.9 MAPPING SAP SALES ORDER CONFIRMATION TO POSO SCHEMA

This mapping converts sales order IDOCs (ORDER05) into a POSO instance. In this case, the

QUALF field in the IDOCs under E2EDK02.

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.

If QUALF is equal 001, then the BELNR is the purchase

If QUALF is equal 001, then the BELNR is the purchase BizTalk Mapping Tool – Sales

BizTalk Mapping Tool – Sales Order Confirmation.

25

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

4.3.10

MAPPING SAP SALES DELIVERY CONFIRMATION TO POSO SCHEMA

MAPPING SAP SALES DELIVERY CO NFIRMATION TO POSO SCHEMA In this map, the POSO status field

In this map, the POSO status field is changed to SalesOrderShipped and specifies the Quantity Now. This field can be used for partial delivery.

Quantity Now. This field can be used for partial delivery. BizTalk Mapping Tool – Sales Delivery

BizTalk Mapping Tool – Sales Delivery Confirmation.

4.3.11 INVOICE IDOCS

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

26

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

BizTalk Mapping Tool – Invoice. 4.3.12 ORCHESTRATION The EDI Orchestrations are basically receiving IDOCs, sending
BizTalk Mapping Tool – Invoice. 4.3.12 ORCHESTRATION The EDI Orchestrations are basically receiving IDOCs, sending

BizTalk Mapping Tool – Invoice.

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

27

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

BizTalk Orchestration Scenario. After the IDOCs are received from SAP endpoint, the response type can
BizTalk Orchestration Scenario. After the IDOCs are received from SAP endpoint, the response type can

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/res

ponse";

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 SCENARIO

In 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.

28

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

BizTalk Shared Schemas 4.3.14 CREATING SAP RECEIVE PORTS FOR IDOCs The Binding file can be
BizTalk Shared Schemas 4.3.14 CREATING SAP RECEIVE PORTS FOR IDOCs The Binding file can be

BizTalk Shared Schemas

4.3.14 CREATING SAP RECEIVE PORTS FOR IDOCs

The 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:

29

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

5. SCENARIO DETAILS 5.1 SCENARIO #1: CENTRAL ORGANIZA TION IS PROVIDING GOODS TO ITS DISTRIBUTION
5. SCENARIO DETAILS 5.1 SCENARIO #1: CENTRAL ORGANIZA TION IS PROVIDING GOODS TO ITS DISTRIBUTION

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.

30

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

Scenario description:  Regional stores/distribution centers generate purchase order of goods to replenish.  The

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.

that will be deta iled in the following sections. 5.1.1 SYNCHRONIZATION OF ITEMS AND PRICE LIST

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:

31

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

5.1.2 TRANSFORM PURCHASE ORDER INTO SALES ORDER The purchase order is placed in the Gateway
5.1.2 TRANSFORM PURCHASE ORDER INTO SALES ORDER The purchase order is placed in the Gateway

5.1.2 TRANSFORM PURCHASE ORDER INTO SALES ORDER

The 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.

32

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

Step 2: Click Send electronically button on the header section and select the following: 
Step 2: Click Send electronically button on the header section and select the following: 

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.

the purchase order number in the Purchase Order field. Step 3: Click OK to add an

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:

33

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

Step 4: The entry can be completed through a batch process or the following job
Step 4: The entry can be completed through a batch process or the following job

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.

to process the message in queue to be picked up by BizTalk. After the job runAIFSync

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:

34

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

BizTalk also refers to the Gateway queue to periodically check for any messages available. The
BizTalk also refers to the Gateway queue to periodically check for any messages available. The

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:

35

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

BizTalk transforms the outbound Microsoft Dynamics AX purchase order into an inbound sales order message
BizTalk transforms the outbound Microsoft Dynamics AX purchase order into an inbound sales order message

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 CONFIRMATION

The 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

36

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

the Corporate ERP field to “Sales order confirmed”. The following displays the updated Microsoft Dynamics

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.

the Corporate ERP field equal to Sales order confirmed. Microsoft Dynamics AX Purchase Order Screen –

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 INVOICE

After 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.

37

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

Microsoft Dynamics AX Purchase Order Screen – Purchase Order is invoiced. 6. CONCLUSION The Regional
Microsoft Dynamics AX Purchase Order Screen – Purchase Order is invoiced. 6. CONCLUSION The Regional

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

6.

CONCLUSION

The 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.

38

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

Microsoft Dynamics is a line of integrated, adaptable business management solutions that enables you and

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-7989 Worldwide (1) (701) 281-6500 www.microsoft.com/dynamics

39

Worldwide (1) (701) 281-6500 www.microsoft.com/dynamics 39 MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO

(701) 281-6500 www.microsoft.com/dynamics 39 MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR – REGIONAL DISTRIBUTION SCENARIO