You are on page 1of 39

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

1.

INTRODUCTION ................................................................................................ 4

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

3.1 IDOC SETUP FOR MASTER DATA TRANSFER ...................................................................... 14

4.

MICROSOFT BIZ TALK SERVER ................................................................... 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.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 ................................................................................................. 38

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

1.

INTRODUCTION

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.

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

In this scenario, the SAP parent and Microsoft Dynamics AX sales office essentially have a vendorcustomer 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.

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

2.

SYSTEM SETTINGS AND MASTER DATA

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.

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.

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.

Logistics- General

Sales & Distribution

SAP Transaction: SPRO


6

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

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

Assign sales organization


CUS to company code CUS

Sales & Distribution

Assign distribution channel 12


to sales organization CUS
Assign division 00 to sales
organization CUS
Set up sales area CUS/12/00
Assign sales organization
distribution channel plant
Logistics Execution

Assign shipping point CUS to


plant
CUS

Link financial accounting (company code level) to


the sales activities.
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.
Define the plant that will provide goods for the sales
area.
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 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
V10000
ORDRSP
ORDERS05

Order Confirmation
Order Output
Purchase order / order confirmation
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
Output type
Output Determination
Procedure
Message Type
Basic Type

2.1.3

F2

Invoice
RD00
V10000

Invoice
Billing Output

INVOIC
INVOIC01

Invoice/Billing Document
Invoice/Billing document

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

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

2.2.2

SALES OFFICES AS COMPANY CODES IN SAP

Company code

CEU

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

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

2.2.3 PRODUCTS USED IN TRANSACTIONS


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

2.3

INT

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 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 following is an additional setup step:
o In the Accounts payable parameters form, select Copy all dollar values from
incoming AIF file field to ensure the sales prices, discounts and total line amounts are
copied from the incoming AIF file.

AIF Account Payable Parameters.


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

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

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.

14

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

4.1

INTERFACING TO AND FROM SAP

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 BAPIs and IDOCs:
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
transactions 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
1. Materials (IDOC MATMAS05)
2. Customers (IDOC DEBMAS03)
3. Purchase Order (BAPI_CREATESALESORDER_FROMDAT2)
4. Shipment Notification (IDOC DELVRY06)
5. Invoice (IDOC INVOIC02)
6. Sales Order Confirmation (IDOC ORDERS05)

Source
SAP
SAP
Microsoft Dynamics AX
SAP
SAP
SAP

Destination
Microsoft Dynamics AX
Microsoft Dynamics AX
SAP
Microsoft Dynamics AX
Microsoft Dynamics AX
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

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

To create a sales order in SAP


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
SALES_ORG

TA
The SAP sales
organization

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


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
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 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 its a new purchase order. If the purchase order is new, it will
convert it to a SAP sales order with document type TA. Otherwise, it will be transformed to a SAP
sales order of type RE which means the items are returns. In both cases, the
BAPI_SALESORDER_CREATEFROMDAT2 is called in transaction mode. If a sales order creation is
successfully done, then the same purchase order XML is updated so that the AIFPurchStatus
element in the XML is changed from N/A to Sales Order Sent. The
PurchaseOrderService_PurchaserOrder service of Microsoft Dynamics AX Application integration
framework (AIF) is called. Before calling this service, the action of the service is set to create.
The following is the code needed to call the service:
DAX_PO_Update_Request._purchaseOrder = xmlPO;
DAX_PO_Update_Request(DynamicsAx5.Action) =
"http://schemas.microsoft.com/dynamics/2008/01/services/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 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 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 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
Invoice

http://Microsoft.LobServices.Sap/2007/03/Idoc/3/DELVRY06//700/Receive
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.
Other processes are included in the Scn1 Solution folder. The following displays the EDI.Scn1
folder.

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


Maps
Orchestrations
Schemas
The following three IDOCs are received from SAP:

Sales Order Confirmation


Pre-Delivery Notification

Invoice

4.3.7 CREATE MESSAGE SCHEMAS


The following displays the steps to create message schemas for Sales Order Confirmation, PreDelivery Notification, and Invoice.
1.
2.
3.
4.
5.

Navigate to the Visual Studio project


Create a new Message Schema for Receiving Sales Order Confirmation using the SAP Adapter
Right click the DistributedDistribution.EDISchemas project
Select Add Generated Item
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 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 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 code is
under the Common Solution.

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. If QUALF is equal 001, then the BELNR is the purchase
order number. If the QUALF is equal 002, then the BELNR is the sales order number. The value of
the POSO status field is changed to Sales Order Confirmed by using a concatenate function.

BizTalk Mapping Tool Sales Order Confirmation.


25

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

4.3.10 MAPPING SAP SALES DELIVERY CONFIRMATION TO POSO SCHEMA


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

BizTalk Mapping Tool Sales Delivery Confirmation.

4.3.11 INVOICE 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 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 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 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 wont recognize the schema type and wont 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=hcsap29501&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 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 items in the regional stores/distribution centers are considered to be purchased from a
vendor which is the central organization.
o In this case, the regional stores/distribution centers send a purchase order to the
central organization.
At the central organization level, the purchase order becomes a sales order as it would be
delivered to a customer.
Delivery and returns can be handled.
Financials will follow the regular intercompany billing rules.
The following displays the scenario transactions that will be detailed in the following sections.

5.1.1 SYNCHRONIZATION OF ITEMS AND PRICE LIST


The following two IDOCs are sent to BizTalk from SAP.
Price List
Material Master
BizTalk transforms the files to the Item Master schema file to be readable by AIF in Microsoft
Dynamics AX.
The item prices are created automatically when using AIF. This requires assigning a Costing Version
to each generated record to ensure a default value for this purpose. The following is the navigation in
Microsoft Dynamics AX: Inventory management> Item details> Price button. In addition, the
Version field can be set with the following navigation: Inventory management>Setup>Parameters.
The following displays the Inventory parameters form in Microsoft Dynamics AX:
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 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:
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:

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 to execute
immediately. Run the job called runAIFSync to process the message in queue to be picked up by
BizTalk.

After the job runAIFSync is run, the following fields are set:
Channel
Source endpoint
The message is now ready to be picked up by BizTalk. After the purchase order is send
electronically, the message will be an outbound message and can be consumed by any external
system including the BizTalk server.
The following displays the Queue manager with the Channel and Source endpoint fields set:

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
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 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 AX Purchase order form with the Corporate ERP field equal to Sales order confirmed.

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

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO