MicrosoftDynamics White Paper AX SAP Regional Distribution PDF

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

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

MicrosoftDynamics White Paper AX SAP Regional Distribution PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MicrosoftDynamics White Paper AX SAP Regional Distribution PDF

Uploaded by

Copyright:

Available Formats

Integration of SAP and

Microsoft Dynamics AX with

Date: September, 2010

1.1 BUSINESS TRANSACTIONS ....................................................................................................... 4

SYSTEM SETTINGS AND MASTER DATA ...................................................... 6

2.1 SAP CUSTOMIZATIONS .............................................................................................................. 6

MASTER DATA UPLOAD TO MICROSOFT DYNAMICS AX......................... 13

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

MICROSOFT BIZ TALK SERVER ................................................................... 14

4.1 INTERFACING TO AND FROM SAP ......................................................................................... 15

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

SCENARIO DETAILS ...................................................................................... 30

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

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

1.1.1 PURCHASE ORDER FROM MICROSOFT DYNAMICS AX TO SAP

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

SYSTEM SETTINGS AND MASTER DATA

Define company code CUS

Create a company code for the parent company.

Define company code CEU

The Microsoft Dynamics AX sales offices are

Define plant CUS

Create a site which represents the operating area of

A division is an organizational part of the sales area

Define Sales Organization CUS

All sales are registered on this organizational level.

Define Distribution Channel 12

Part of sales area.

Define Storage Location 0001

Physical location where stock is kept.

Define Shipping Point CUS

Point from which deliveries leave the plant.

Sales & Distribution

SAP Transaction: SPRO

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

SAP Implementation guide: Enterprise Structure- Assignment

Assign company code CUS to

Credit control area 1000 is the standard IDES control

Assign company code CUS to

Activate cost accounting functionality for the company

Assign plant CUS to company

A plant belongs to one company code

Assign sales organization

Sales & Distribution

Assign distribution channel 12

Assign shipping point CUS to

Link financial accounting (company code level) to

SAP Transaction FS00

Reconciliation accounts for a vendor or customer are

2.1.2 CUSTOMIZING SALES & DISTRIBUTION IN SAP

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

CUSTOMIZING LOGISTICS EXECUTION IN SAP

SAP MASTER DATA

SALES OFFICES AS CUSTOMERS TO PARENT COMPANY

Customer master record

SALES OFFICES AS COMPANY CODES IN SAP

MICROSOFT DYNAMICS AX TWO-TIER CONNECTOR REGIONAL DISTRIBUTION SCENARIO

2.2.3 PRODUCTS USED IN TRANSACTIONS

2.2.4 PRICE LISTS

2.2.5 CHART OF ACCOUNTS

SETTING UP MICROSOFT DYNAMICS AX