MX supports account data sync from ERP which includes basic account data (Customer ID, VATID), its addresses, and sales area information.
To control the number of accounts available for synchronization from ERP to MX database view need to be created in the ERP system. Using this view one can filter on account ERP Data (more on this later in the document) and thus reduce the number of customers (accounts) synced to MX.
Important: MX uses a URI to uniquely identify each customer/account object. The URI includes the hostname of the ERP system (source system) plus the customer/object ID to make it unique per customer/object. The hostname is found from the destination ECC_RFC_DESTINATION and follows the pattern of hostname and client.
For example, an account URI would look like:
- prod is the ERP hostname and comes from jco.client.ashost or jco.client.mshost
- 800 is the client and comes from client.client
- The account is the name of the type of the object in MX
- 123456 is the customer id.
*Note that in MX Account and Customer are used interchangeably.
Data Selection/ Filtration in ERP
MX uses database views in ERP to check which objects should be synced to MX. This is also applicable to account sync. We recommend maintaining all the views below at one time.
Database views in ERP can be created using transaction SE11
Tip: Database filters might return duplicated records since ERP does not support DISTINCT concept when creating views. This is currently handled on the MX side where duplicates are eliminated.
Account Sync Procedure
For this sync to work first create database view “Z_ISS_CUSTOMER” with columns
- “MANDT”, “KUNNR”, “VKORG”, “VTWEG”,” SPART”.
In case the account sales area information is needed to be synced from the view.
- “MANDT”, “KUNNR”
In case the account sales area information is not needed from the view.
This view is based on standard ERP tables “KNA1” and “KNVV”. Using this view one can also do the pre-filtering of accounts/customers in ERP which are to be synced to MX.
Depending on the filter conditions the view might need to perform a join on different tables and a set of selection conditions.
Those filters need to be applied depending on the business case of the customer. In Mind recommends to carefully put in selection the customer that should be made available in MX system as this impacts the performance of data sync. Larger the set of data more time it will take to complete the sync and more database usage on the MX side.
Important: Enable setting SettingERPAccountSyncWithSalesAreaFromView, to sync sales area information from the ERP database view. Alternatively, MX will use BAPI to read this information more in Section 184.108.40.206.
With SELECTED Sales Area Information (Setting is ON)
If setting SettingERPAccountSyncWithSalesAreaFromView is ON, MX will also try to sync the sales area information from ERP. The following fields need to be mandatory created in the database view: KUNNR, VKORG, VTWEG, SPART. Any additional fields are in general ignored. The database view preparation is already covered in Section 2.3.2.
With ALL Sales Area Info (Setting is OFF)
In case only account information is required or if the setting SettingERPAccountSyncWithSalesAreaFromView is OFF. The only mandatory field in the database view is KUNNR. The additional fields are in general ignored.
However, this does not mean that MX will not synchronize the sales area for the customer. Users have the option to maintain the sales area in database view or MX will sync ALL sales areas of the customer using alternate BAPI: BAPI_CUSTOMER_GETSALESAREAS.
Manual and Explicit Customer Synchronization
To explicitly synchronize a customer one can go to System processes→ ERP synchronization → Sync Specific object.
Select Account and provide the full customer/account ID. This is shown below:
Background Account Synchronization
One can also run background sync by going to System processes→ ERP synchronization clicking sync button and selecting the below option.
Background Account Synchronization System Task
One can also set up a system task to run the account sync in the background. This can be done from Administration→ System Task → create a new task with a cron expression string and using the task resource AccountSyncJob
Note that there is no delta sync in ERP Account/Customer synchronization. The reason being there is no correct way to know the last changed date on an account. In this case, setting up an account sync job may consume some system resources depending on the number of ERP customers to sync.
Prerequisites (Basic Data Points)
- Country Region
- Sales Org
- Distribution Channel
- Sales Office
- Inco Terms
- Payment Terms
- Partner Function
Note that: These data points with ERP IDs need to maintain in advance before account sync.
Partner Function Sync
Together with the account, MX also provides functionality to synchronize partner functions defined for Account from ERP
MX read directly from the ERP table “KNVP” to get all the partner functions of the account. However, MX will create partner functions for the sales info/area (sales org, distribution channel, and division) that maintained in the system.
Only two sales areas maintained in MX as per the below screenshot.
Below is the content of the KNVP table for account “1000” in the ERP system. Since only two sales areas are maintained in the system, partner functions that are maintained in these two sales areas will be synced into the MX system as per highlighted within the orange box.
For example, the below screenshot is the partner function master data maintained in the system. In this case, you will notice that “RE” is not maintained as a partner function ERP ID. Only some partner functions are maintained in MX. This provides the customization functionality of only certain partner functions that can be synchronized into MX.
Usage of Partner Function
There is standard functionality provided to copy account partner functions of the same sales area as quote partner function during quote creation as well as quote copy. This can be done by enabling setting “SettingAddAccountKeyPartnersToQuote”. If more than one partner function records found for the same sales area, some logic is applied in choosing a key partner. The partner function set as “Default” is the highest priority, followed by the increasing order of position. If no “Default” is found, the partner function with the least position number will be picked up as a partner.
If the user does not want to use the standard implementation, he or she may define his/her own logic of choosing a default partner in the post quote creation groovy script.
In case, the user wants to use standard implementation together with a custom implementation, the sequencing should be as below:
- Standard implementation: adding all partner functions from Account to Quote of the same sales area.
- Post Quote creation script: additional defaulting.
But in this case, the user/consultant should be responsible to make sure of non-duplicate partner function records.
The partner function sync is only supported for partner function with partner function type “Account” and “User” and not supported for others such as “Contact”.