ERP Integration

1 Introduction

The system administration guide contains key information to explain how In Mind Cloud Manufacturing Sales Platform (MSP) ERP Guide effectively. The guide provides the concepts and detailed definition of the functions, aiming to enable administrator to have sufficient knowledge to setup the function with minimal supervision.

The document will be continually edited and updated based on latest product releases. Taking into the consideration of expensive effort keeping the document updated and effective usage of it, only major and complex features are covered.

To better illustrate how to setup certain feature, some examples are given. It also contains the steps linked to relevant screens. Each step contains actions which the administrator needs to perform to complete the setup.

This administration guide is based on Manufacturing X (MX) release version 1902.

Enjoy!

The Product Engineering Team

2 MSP to SAP ERP Integration

SAP ERP integration is the back bone of In Mind Sales platform. It is used to leverage the existing data in SAP ERP. Customers can bring into In Mind Sales platform variety of data points from SAP ERP. This includes Materials, Material Classification data, Characteristics, Classes, Unit of Measures, Sales Texts, Material substitution data etc.

The integration is built on standard SAP BAPI for purpose of information exchange and is supported on the SAP Cloud platform by Connectivity Service. More on this in Section Integration Set Up.

The integration is bidirectional. Sales Platform not only consumes data from ERP, but also creates data in it. This includes creating Sales Quote, Sales Orders. For made to order process MSP also creates materials and its bill of material into ERP. In addition to this the integration supports custom features, to give a few examples: credit limit check, custom field selection etc.

Figure 1-Logical Diagram Of ERP Integration
Figure 1-Logical Diagram Of ERP Integration

From the process point of view, SAP ERP integration covers everything from consuming master data, synchronizing product, to simulate sales order pricing to sales order creation and more.

As a general flow to build up to a sales process in MSP this can be visualized as follows:

This image shows the break of various components touched in MSP SAP Integration

Figure 2 - Components Of ERP Integration
Figure 2 - Components Of ERP Integration

2.1 Integration Set Up

2.1.1 SAP Cloud Connector

SAP Cloud connector also known as SCC, is a free software made available by SAP to help connect accounts in SAP Cloud Platform to backend SAP ERP systems. The Cloud Connector is a standalone application which runs on a separate host in customer VPN. It provides a secure tunnel connection between SAP CP account to SAP Back end system (ERP). For more information please visit site:

https://cloudplatform.sap.com/capabilities/product-info.SAP-Cloud-Platform-Connectivity.43bdae3a-bec5-4c47-83ed-44197926b024.html

The software can be downloaded and installed from SAP Hana Cloud Platform Tool site: https://tools.hana.ondemand.com/

Usage and configuration can be done by following the official documentation at

https://help.hana.ondemand.com/cloud_portal_opsoc/frameset.htm?e90bb056d2f7491b83fa21e8974a9102.html

Also, at

https://blogs.sap.com/2015/07/13/cloud-connector-a-brief-guide-for-beginners/

Figure 3 - SAP Cloud Connector Setup
Figure 3 - SAP Cloud Connector Setup

2.1.2 SAP Cloud Platform Set up using SAP Cloud Connector

Once the cloud connector installation is completed the SAP Cloud platform account details needs to be registered inside it. After performing this set up the cloud connector will internally create a tunnel connection with the target SAP Cloud Platform account as shown below:

Figure 5 - Registered Cloud Connector in SAP CP
Figure 5 - Registered Cloud Connector in SAP CP
Figure 6 - Destination In SAP CP
Figure 6 - Destination In SAP CP

Next, one can start to create RFC destination. This can be done either on the account level or on the application level. Note that all account level destinations are available to all its application. But not the other way around. We recommend creating application level destinations so that the applications can connect to QA or PROD ERP systems as needed. Destinations in the SAP Cloud Connector.

2.2 MSP ERP Integration

2.2.1 BAPI Overview

MSP ERP integration makes use of several BAPIs from ERP system. These need to be whitelisted in the SAP Cloud Connector (SCC). The list of such BAPI along with the need is as follows:

BAPI NameOrder Creation/ SimulationData SyncProduct SyncCustom Table SyncMaterial/BOM/
Routing Create
SSC
BAPI_CHARACT_GETDETAILXX
BAPI_CLASS_READXX
BAPI_INQUIRY_CREATEFROMDATA2X
BAPI_QUOTATION_CREATEFROMDATA2X
BAPI_SALESORDER_CREATEFROMDAT2X
BAPI_SALESORDER_SIMULATEX
COD_SALESORDER_SIMULATEX
BAPI_MATERIAL_AVAILABILITY
BAPI_MATERIAL_GETALLX
BAPI_MATERIAL_GET_PRODUCTHIERX
xBAPI_TRANSACTION_COMMITXX
CLAF_CLASSIFICATION_OF_OBJECTSX
COM_CFG_READ_PRODUCT_VARIANTX
COM_CFG_READ_VARCOND_DESCR
EXTRACT_DATAX
RFC_READ_TABLEXX
SELECT_COUNTX
RFC_READ_TEXTX
BAPI_MATERIAL_EXISTENCECHECKX
BAPI_ROUTING_EXISTENCE_CHECKX
BAPI_MAT_BOM_EXISTENCE_CHECKX
BAPI_MATERIAL_SAVEDATAX
BAPI_MATERIAL_GETINTNUMBERX
BAPI_MATINSPCTRL_SAVEREPLICAX
BAPI_MATERIAL_BOM_GROUP_CREATEX
BAPI_ROUTING_CREATEX

Figure 7 – List of Bapi used in MSP

2.2.2 ERP RFC User

ECC integration is conducted via Remote Function Calls (RFC) that are recommended to be executed by a distinct ERP user. This user needs some permissions in order to execute RFC modules.

A new user can be created using (Transaction SU01) and subsequently the permissions should be assigned.

2.2.2.1 Create new single role e.g. ‘Z_ISS_RFC’ (Transaction PFCG)

1 Depending on used document types

2 BAPI SD_SALES_DOCU_MAINTAIN needs to be patched in current SAP releases to enable transfer of manually entered pricing conditions

3 See SAP Note 177

4 Depending on installed add-ons this could also be /SLCC/EXTRACT_DATA or /SLCE/EXTRACT_DATA

5 Doesn’t work by default in SAP_AP releases >=23

6 Doesn’t work by default if support package SAPKNA7032 is installed (sap note 1995783)

2.2.2.2 Change Authorization Data (without template)

Manually add Authorization Objects:

    • for SSC product configuration
      • C_TCLA_BKA (configuration)
      • C_TCLS_BER (configuration)
      • C_TCLS_MNT (configuration)
      • K_KEKO (variant prices)
      • S_RFC (KB export)
      • S_TABU_DIS (KB export)
    •  for sales order/quote creation or simulation
      • V_VBAK_AAT (sales doc)
      • V_VBAK_VKO (sales doc)
    • for replication of ERP non-configurable material master
      • M_MATE_STA (to pull material master, display C, K, V for STATM)

Select Edit – Insert authorizations – from profile: S_A.SCON

Change Authorization Data

Grant full authorization of each object or restrict to generate and save single role.

E.g. company code, sales doc type, division….

2.2.2.3 Edit RFC-User and ‘Z_ISS_RFC’ to Roles (SU01)

For debugging of e.g. a specific BAPI call switch RFC user to ‘Dialog’-Mode and add role SAP_BC_DWB_ABAPDEVELOPER to access SE37 with RFC user.

For changed authorizations, refer to SAP system trace to record authorization checks (ST01), cf. http://help.sap.com/saphelp_nw73ehp1/helpdata/en/92/7ac87d293a47d8a17368c9f45661f4/content.htm.

2.3 Product Data Sync

MSP supports product data sync from ERP to MSP which includes sync of units of measurement, basic product data (Material ID, Material Basic Data Text), Product/Material classification data, product sales text and Product Variants.

To better control this from ERP side and to restrict the number of products going into target MSP, views are needed to be created in ERP system which act as a filter on top of ERP Data (more on this later in the document).

The product sync is split into two parts, first (initial) product data sync and second (subsequent) delta product sync which allows sync of newly added or changed materials from ERP system. The changes are recognized based on the last change date in ERP.

MSP uses a URI to uniquely identify each object. The materials and other objects coming from ERP are identified by a URI that includes the hostname of the ERP system (source system) plus the material/object ID to make a unique URI per material/object. The hostname is found from the destination ECC_RFC_DESTINATION and follows the pattern of hostname and client.

 

For example, a material URI would look like:

http://imc.prod/800/Product#000000000000123456

where

  • prod is the ERP hostname and comes from jco.client.ashost or jco.client.mshost
  • 800 is the client and comes from client.client
  • Product is the name of type of the object
  • 123456 is the material id.

*Note that in MSP Product and Material are used interchangeably.

Important: For materials synchronized from ERP the linkage with its Unit of Measure is done based on URI only. Unit of Measurement (UoM) also has a similar URI. For the purpose of linking the two together. It is advised that UOM be first synchronized from ERP before starting with the Product sync.

To start product data synchronize go to:

Administration-> Data Synchronization -> ERP Data Synchronization

Order to Synchronize Data

First sync all Unit of Measurement and Product Hierarchy (optional).

Next start syncs of Product together with classified* data. Enable the setting SettingProductSyncDownloadClassification if classification data is needed. If enabled, products are synced together with their classified data which includes the classification class and characteristic values.

The data sync first synchronize the characteristics, followed by the classes, followed by product itself and finally product classification.

As in ERP the classification data can be maintained in various classes. The setting SettingClassificationToLoad is useful in listing which class type (class name) to use for classification data, default is class type 001.

The following data points are extracted from ERP system:

  • Unit of Measure
    • Short text (imported as label) in all maintained languages.
    • All unit of measurements maintained in ERP system.

 

  • Material Hierarchy
    • Material hierarchy maintained in ERP system.
    • Short text (imported as label) in all maintained languages.
    • Hierarchy id is mapped to objectERPId.

 

  • Material
    • Product (materials) maintained in ERP system.
    • Short text (imported as label) in all maintained languages.
    • Base texts (imported as description) in all maintained languages.
    • Sales text (if the setting is on)
    • Unit of measurement
    • Product hierarchy (imported as product category).
    • Deletion flag (mapped to product status)
    • Material number (mapped to objectERPId)
    • Last Change Date

 

  • Classifications
    • Classifications (knowledgebase) maintained in ERP system.
    • Short text (imported as label) in all maintained languages.
    • Long text (imported as description) in all maintained languages.
    • Class name mapped to objectName
    • Last change date

 

  •  Characteristics
    • Characteristics maintained in ERP system.
    • Short text (imported as label) in all maintained languages.
    • Characteristic name mapped to objectName.
    • Last Change Date
  • Characteristics Value
    • Short text (imported as label) in all maintained language.
    • Characteristic value mapped to objectName.

 

  •  Custom Table View

Not part of product data syncs however useful in synchronizing any custom /standard table from ERP. See Internal Price Engine Guide for more information.

The relation between MSP and ERP is mapped as follow:

Figure 9 - Relation Between MSP and ERP Entities
Figure 9 - Relation Between MSP and ERP Entities

Used BAPI’s:

  • RFC_READ_TABLE
  • BAPI_MATERIAL_GET_PRODUCTHIER
  • BAPI_CHARACT_GETDETAIL
  • BAPI_CLASS_READ
  • BAPI_MATERIAL_GETALL
  • CLAF_CLASSIFICATION_OF_OBJECTS

 

Limitations:

  • Only hierarchy nodes referenced by products are fetched.
  • Only one material class (class type 001 or another) is taken into consideration for classification.
  • The product variant is considered on top/separately.
  • During product sync no relationship between hierarchy nodes is maintained so hierarchy tree is not available.
  • No long texts fetched for characteristic values.
  • No units fetched for characteristics.
  • No class hierarchy information is fetched.
  • Inherited characteristics are not considered during product sync.
  • Time and date characteristics are fetched as string values only.

2.3.1 Data Selection / Filtration in ERP

MSP uses databases views in ERP to check which objects should be synced to MSP. This is applicable to products, classes and characteristics sync. We recommend maintaining all the views below at one time.

Database views in ERP can be created using transaction SE11.

*: Database filters might return duplicated records since ERP does not support DISTINCT concept when creating views. This is currently handled on MSP side where duplicates are eliminated.

2.3.2 Product Sync Procedure

Create database view “Z_ISS_MAT” with columns “MANDT”, “MATNR” and “LAEDA” in ERP. This view is based on standard erp table “MARA”. This view can do the pre-filtering of products/materials in ERP which are to be synced to MSP.

Product Sync Procedure

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 product that should be made available in MSP system as this impacts the performance of data sync. Larger the set of data more time it will take to complete the sync. Also, if the products are not sales relevant do not sync them to MSP.

2.3.3 Manual and Explicit Material Synchronization

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 product that should be made available in MSP system as this impacts the performance of data sync. Larger the set of data more time it will take to complete the sync. Also, if the products are not sales relevant do not sync them to MSP.

Figure 10 - Example: Selection Condition
Figure 10 - Example: Selection Condition

System Processes -> Products Synchronization->Click on download button. Add ERP ID of the materials fully qualified that is with leading zeros in case the material id/name is numeric.

Figure 11 -Sync Specific Material From ERP
Figure 11 -Sync Specific Material From ERP

The screen shot above shows the example where the material ID’s INV_266765, INV_266764, INV_266763 and 000000000000123456 are to be synced from ERP system.

Material ID Sync from ERP

2.3.4 Background Product Synchronization

In the main product sync the products can be synchronized in background using:

System Processes-> Synchronize products and selecting Run in background parameter.

Figure 12 - Run Material Sync in background
Figure 12 - Run Material Sync in background

2.3.5 Background Product Sync System Task

One can also set up a system task to run the product sync in background. This can be done from Administration-> System Task -> create new task with a cron expression string and using the task resource ProductSyncJob

Background Product Sync

More information on cron expression: https://www.freeformatter.com/cron-expression-generator-quartz.html

Some of the settings that effect the Product Sync Job:

SettingProductSyncDownloadProductsSetting to enable sync of products in background system tasks
SettingProductSyncDownload

Classification

Setting to enable sync of classification data of the products. Should be enabled before the start of product sync
SettingClassificationToLoadSetting to override which classtype to load the classification data for. Default is 001
SettingProductSyncBatchSizeSetting to setup a batch size for product sync.
SettingProductSyncBatchSyncInactiveSetting to also sync mark for deleted products in ERP
SettingProductSyncBatchMarkAsExportToCRMSetting to enable the flag export to crm on products synced from ERP
SettingUseDisplayMatNoFromBAPIForObjectName

(Deprecated: since 1902 In general MXP now applies the product object name by removing prefix zeros from the material number.)

If true would make the 18-digit numeric material number coming from erp to remove prefix zeros.

That is a material number like

000000001234567800

Would become 1234567800 for the object name of the product.

 

2.3.6 ERP Material Class Sync Procedure

For syncing the classification data of the material, the following steps need to be undertaken in ERP.

Create database view “Z_ISS_CLASSES” with columns MANDT, CLINT, KLART, CLASS and VDATU in ERP. This is based on standard table “KLAH”. It’s needed to control the pre-filtering of classes in ERP which are to be synced.

ERP Material Class

One can set the filtering conditions in this view. An example: Created by a User and class type:

ERP Material Class

2.3.7 Manual Class Synchronization

To synchronize individual class in ERP system. Follow the steps as listed in screen shot below:

Figure 13 - Sync Specific Class from ERP
Figure 13 - Sync Specific Class from ERP

2.3.8 ERP Characteristic Sync Procedure

For syncing the Class characteristic data, following steps need to be undertaken in ERP.

Create database view “Z_ISS_CHARAC” with columns MANDT, ATINN, ADZHL, ATNAM and VDATU in ERP. This is based on standard table “CABN”. It’s needed to control the pre-filtering of characteristic in ERP which are to be synced.

ERP Characteristic Sync
ERP Characteristic Sync

Example of a filter criteria:

ERP Characteristic Sync

2.3.9 Manual Characteristic Synchronization

To synchronize individual characteristic in ERP system, use the process as shown in screens shot below.

2.3.10 Product sales text sync

In ERP system material sales text is maintained in a way that they are org unit and distribution channel specific.

Product sales text is governed by SettingProductSyncDownloadProductSalesText Boolean setting. If this setting is on, sales text is synced along with the product sync. RFC_READ_TEXT BAPI is used to read sales text from ERP system. This BAPI needs to be enabled from SAP Cloud Connector.

MVKE and LANGUAGEKEYS lookup tables in MSP are also used in the sync process. MVKE contains records on product, sales org and distribution channel relationship. Data for this table can be directly synced from the corresponding ERP table (if the data is too much, a view can be created in ERP system with some filtering criteria and then from that view data can be synced) or can be maintained manually. LANGUAGEKEYS table is used to maintain the mapping between language key and corresponding 2-character SAP language code. T002 is the corresponding table from ERP system.

Field NameDescription
MATNRProduct ERP ID / Material number
VKORGSales org ERP ID
VTWEGDistribution Channel ERP ID

MVKE Lookup Table

 

Field NameDescription
SPRASLanguage key
LAISO2-character SAP language code

LANGUAGEKEYS Table

 

Sales Orgs, distribution channels and languages need to be maintained in MSP along with their ERP IDs. Also note that although in ERP system sales text may be maintained for several languages, in the sync process only the languages maintained in MSP are considered.

2.3.10.1 Usage of product sales text in MSP

Product’s sales text can be viewed under product’s General Information -> Sales Labels,

Usage of Product Sales

Here ERP Id is the combination of the ERP Ids of product, sales org and distribution channel.

 

Sales text of a product can also be viewed from the product catalogue given that the product catalog is launched from within the quote and sales org and distribution channel are maintained for the quote. MSP figures out the sales text with the combination of sales org and distribution channel of the quote and the locale language of the current logged in user.

 

Sales text in product catalog view,

Sales Text in Product Catalog

Sales text from product details view,

Sales Text From Product Details
Sales Text From Product Details

Once product is added to the quote, sales quote can also be viewed from line item view.

Sale Text Viewed From Line
Sale Text Viewed From Line
2.3.10.2 Extension points in sales text reading

A groovy extension point is made available to map the user’s locale language to sales text language. UserLangToTextLangMappingScript can be used to code any custom logic for the mapping. If a script is present, the system will execute the script to figure out sales text language, else it will use user’s localise language.

Sample script:

/* This script determines sales text language for a given user language. This will be executed at the time of reading the sales text in CPQ.

*

* Binding objects

*  userLanguage : String // String representing user’s language(“en” for example)

*  textType : String // String representing text type (“SALES_TEXT” for example)*

*/

if (textType.equals(“SALES_TEXT”)) {

return “en_sg”;

}

return userLanguage;

2.3.11 Synchronization history

Figure 15 - Sync History in MSP
Figure 15 - Sync History in MSP

If any of the above synchronizations are triggered, MSP will generate a synchronization status report as shown below, Section Usage of Cstic and Class in MSP.

2.4 Usage of Cstic and Class in MSP

The synchronized characteristics and classes are created as Dynamic Attributes and KnowledgeBase Classes in MSP.

The Dynamic Attribute are of two types, Dynamic Data Attribute (DDA) and Dynamic Symbolic Attribute (DSA).

If characteristics and classes are synced together with product and that product has material classification in ERP system, the classified product is created, and all the characteristic values are saved as dynamic attribute values of the product inside the knowledgebase. There are two main use cases of these synced data.

  • These dynamic attribute values can be used to search classified products with the help of product finder in MSP.
  • These dynamic attributes can be reused to create a new product in MSP.
Figure 16 - List of Dynamic Attributes in MSP
Figure 16 - List of Dynamic Attributes in MSP
Figure 17 - List of KB classes in MSP
Figure 17 - List of KB classes in MSP

Model -> Attribute Management lists all the dynamic attributes in the system.

2.4.1 Product Finder MSP / Variant Matching SAP

Product finder is a convenient feature for users to find configurable to classified products based on the characteristic/Dynamic Attribute values. A “product finder product” or a “configurable product” (having the attributes of the product that a user is searching for) is used to specify the attributes and then to find matching products. The functionality is exposed as an extension in the product configuration page and the search results are limited to 50 products.

The idea is that the user may specify more attributes to narrow down the search.

This feature makes use of classified data coming from SAP ERP. Once the Products and their classification is synchronized from ERP, each classified material (a material having classification data) gets its classification stored in a KB Snapshot object on MSP side.

To check this, go to the detail page of the product and Knowledgebase-> Snapshot.

Figure 18 - Product Snapshot in MSP
Figure 18 - Product Snapshot in MSP

Click on the snapshot to see the details:

Figure 19 - Snapshot Detail in MSP
Figure 19 - Snapshot Detail in MSP

It is important to note that this classification can also be from other Class Types. Apart from data sync and putting a “product finder KB in MSP” or using a configurable product from ERP directly, no other setting is needed to set up the Product Finder feature. The logic works like the variant matching in ERP. For a configurable product the user selects the dynamic attributes in the configuration page on the Quote in MSP.

Doing so the user can click on the search button as shown below to find the matching products.

Figure 20 - Product Finder Details
Figure 20 - Product Finder Details

Of the matched products user can choose to add them to the quote or replace the existing configurable product with one or more of them.

2.4.2 Apply Classified Product Configuration to Configurable Product

Apply classified product configuration to configurable product is inverse of product finder/variant matching. Here the configuration of a classified product is taken and applied on to the configurable products.

This feature is available by clicking on Actions-> Apply Configuration

Figure 21 - Apply Classified Configuration to Configurable Product
Figure 21 - Apply Classified Configuration to Configurable Product

Next, product catalog opens, and one can choose any product from the catalog. MSP will try to match the classification DAs of the selected product to the DAs of the configurable product and apply the values.

Result configuration applied:

Result Configuration Result
Result Configuration Result

2.4.3 Date Sync Procedure: For costing, Custom usage

Next, product catalog opens, and one can choose any product from the catalog. MSP will try to match the classification DAs of the selected product to the DAs of the configurable product and apply the values.

Result configuration applied:

Figure 22 - Lookup Table In MSP
Figure 22 - Lookup Table In MSP

One can create a new table or update the details in an existing table.

The ERP Id is the table/view name in ERP.

For more details please check the Internal Price Engine Guide which explains this topic in more detail.

2.5 Pricing Simulation in SAP ERP

This is a pricing scenario where the MSP is used for quotation and configuration but for pricing ERP is used directly. It is also known as external pricing, external because the pricing happens outside of MSP, in ERP system. MSP user can do price simulation in ERP to get the individual price of sales items and the quotation price together with pricing conditions. All the pricing conditions, pricing procedures and the determination of pricing procedure is maintained in SAP ERP system. This BAPI based pricing simulation makes uses of different BAPI’s depending on implementation. The result of pricing simulation is sales item price, quotation price, pricing condition and scheduled delivery items.

There are three main use cases:

  • The first one is when a customer wants to use non-configurable products in quotation, is using SAP Cloud for Customer (CFC), has SAP CFC add-on installed on their ERP. In this case MSP uses BAPI COD_SALESORDER_SIMULATE. This BAPI supports features such as credit limit check and delivery information. However, it does not support passing of configuration data to ERP.
  • The second use case is when customer uses ERP product models in MSP, the products/items in quote are a combination of configurable and non-configurable products. Configuration Engine in use is SSC (to render product models coming from ERP). In this case MSP uses BAPI_SALESORDER_SIMULATE to do price simulation. This BAPI accepts the configuration of the configurable products, and pricing conditions. However, it does not support customer credit limit check.
  • The third use case is like the second one with only one major difference. In this case MSP uses its on-product models for configurable products. Classified product and pricing conditions from ERP can still be used.

2.5.1 Price Simulation with The Usage of Cloud for Customer Add-on BAPI

Price Simulation with the usage of Cloud for Customer Add-on BAPI (COD_SALESORDER_SIMULATE – BAPI 1). Note that this BAPI cannot be used with Variant Configuration.

2.5.2 Price Simulation with The Usage of Standard BAPI

Price Simulation with the usage of standard BAPI (BAPI_SALESORDER_SIMULATE – BAPI 2). It is especially useful with the use of SSC (Solution Sales Configuration). It is helpful in case customer has written custom code in pricing logic on ERP side. Calling pricing simulation gets the pricing logic in ERP executed. This BAPI can be used together with Variant Configuration (LO_VC) or with MSP configuration logic.

2.5.3 BAPI Overview

These two BAPIs works for pricing simulation and most of the input and output parameters are the same. However, the following data points/features are not supported in BAPI_SALESORDER_SIMULATE.

  • CREDIT_LIMIT (Credit limit of an account)
  • CREDIT_EXPOSURE_AMOUNT (Exposure amount of an account)
  • CREDIT_EXCEEDED_AMOUNT (Exceeded amount of an account)
  • NET_PRICE (Unit Price of Sales Item)
  • NET_VAL_HD (Total Price of Quote)
2.5.3.1 Import Parameters
Import Parameters

Summary of Import Parameters (Parameter to be passed to external pricing):

ParameterMandatory/ OptionalDescriptionBAPI Applied
AccountMandatoryERP ID of account must be maintained in MSP. This account ERP ID is also used as partner BUYER_PARTY and SHIP_TO_PATY.1,2
Sales Document TypeMandatoryERP ID of sales document type must be maintained in MSP.1,2
Sales OrganizationMandatoryERP ID of sales organization must be maintained in MSP.1,2
Distribution ChannelMandatoryERP ID of distribution channel must be maintained in MSP.1,2
Shipping ConditionOptionalERP ID of shipping condition must be maintained in MSP
DivisionOptionalERP ID of division must be maintained in MSP.1,2
Request Delivery DateOptionalQuote requested date.1,2
Pricing DateOptionalQuote pricing date.1,2
Valid from DateOptionalEither quote effective date or quote creation date.1,2
Valid to DateOptionalSales document expiry date.1,2
CurrencyOptionalEven though currency is optional in BAPI call, if we do not pass currency, default currency defined in ERP is used which can lead to wrong pricing values.1,2
ProductsOptionalExternal pricing will skip on the product that does not have ERP ID.

External pricing will skip on the product that is marked as not to export to ERP.

External pricing will skip on the product if the product is marked as optional (i.e., “salesItemOptional” is   true).

1,2
Price ItemsOptionalPrice Item can be of two different types, header price Items and item Price Items. MSP allows manually created price items to export to external system and let them involve in pricing. The ERP IDs of these manually created price item must be maintained in MSP system.1,2
Price GroupOptionalERP ID of price group must be maintained in MSP system.1,2
Price ListOptionalERP ID of price list must be maintained in MSP system.1,2
Variant ConfigurationOptionalApplicable only to BAPI_SALESORDER_SIMULATE.2
Import Parameters
2.5.3.2 Export Parameters

Summary of Export Parameters (Return Value from external pricing)

ParameterDescriptionBAPI Applied
Price ItemPrice Item belongs to both Header level and Item level. These price Items with correct ERP ID needs to be maintained in MSP beforehand.1,2
Document Header Net ValueTotal value of quote price returned from external system.1
Item Header Unit PriceUnit price for each of the sales items from external system.1
Item Header Net ValueTotal price for each of the sales items from external system. The value is already multiplied with the quantity.1,2
Schedule Line ItemEach of schedule line items contain delivery date, delivery time together with required quantity and confirm quantity.1,2
MessagesMSP show all the messages (success, error and warning) as notification from ERP system without filtering.1,2

Figure 23 -Summary of Export Parameters (Return value from external pricing)

Note:

Price simulation with variant configuration only returns item header net value. It does not return item header net price and document header net value. However, MSP is adding up all the item header net values to yield document header net value which is quotation price.

Ref: 1 refers to COD_SALESORDER_SIMULATE. 2 refers to BAPI_SALESORDER_SIMULATE.

2.6 MTO Process

For manufacturing customer there is a need to quote and sell standard or configurable products. However, they also do made-to-order products. In this process they start with a dummy material/product that is used to capture the requirements and from there on developed into a quote specific sale BOM with costing.

The other items in the quote could be existing ERP materials which make up the finished product that the customer is trying to quote using the dummy material. That is the dummy material can be thought of as a finished product that is eventually quoted, its sub line items in the quote are part of its assembly and hence the finished good can also be called as an assembly.

The quote might get accepted or rejected and because of this not all such dummy assemblies/finished goods are created in ERP. Because the rejected ones will just sit there with no further action on them plus it is a bit more expensive to do this in ERP from time and money point of view. The customer would need to undertake a custom programming initiative to keep clear of what is custom and what is not. That’s why the MSP platform is an ideal option to create such quotes with assemblies. MSP is built to have such capability to manage the dummy products, quotes with assemblies and if the quote gets accepted the follow-on process of moving this quote from MSP to ERP.

As the quote contains an assembly comprising of dummy and actual products. The first part of this process is to create the dummy material as an actual material in ERP. Here also there are two cases and a brief mention about this is necessary. The new material that the user wants to create from a Quote could be created with in MSP or ERP, this is a process choice and depends on business case. However, for the purpose of this guide we stick with material creation in ERP.

The second step in MTO process is to create a production bill of material for the dummy material that was created in ERP in step one. This bill of material contains all the sub line items materials from the MSP quote. These subline materials already exist in ERP as standard materials.

The next optional step is to also create material routing in ERP. Material routing is the time and resources taken to assemble this assembly. That is physical labour, machine and time spent on really building (or assembling) the material. MSP provides steps in Internal Price Engine to compute this material routing during quotation process, because the material routing adds up into the costing of the assembly.

The last step of the MTO process is order creation. Here the order is created with same sales specific data as the quote has plus with an option to only include the finished product into the order. This finished product is the one that was created in step one.

2.6.1 Material Creation in SAP

Quotation in MSP can start with the dummy product. Once the quotation is accepted, the dummy product in MSP can be created in ERP as a new material.

To launch this module, go to: Quote-> ERP Helpers-> Material and click on the listed material, the logic that which materials will be allowed to be created is based on the flag on the product in MSP. Each product in ERP has a product type and the product types with flag isMaterialCreationRelevant true are shown in the above view. In addition, the product should not have an ERP id assigned else it is considered already created in ERP.

All the data points related to material creation such as industry sector, plant, unit of measure, material group, item category and so on need to be maintained in ERP system as master data in advance. Moreover, these master data related to material creation must be maintained in MSP system before material creation. The mandatory data points can be different and is case by case basis to individual ERP.

ERP ID of newly created material is saved as ERP ID of the sales item in MSP system as a token of material creation, listing that the item is moved to ERP.

Used BAPIs:

  • BAPI_MATERIAL_GETINTNUMBER
  • BAPI_MATERIAL_SAVEDATA
  • BAPI_MATINSPCTRL_SAVEREPLICA

The below screen shot shows the various data points required in material creation.

Figure 24 - Input Data Preparation for Material Creation
Figure 24 - Input Data Preparation for Material Creation
Figure 25 - After Material Creation in MSP
Figure 25 - After Material Creation in MSP
Figure 26 - Newly Created Material in SAP ERP
Figure 26 - Newly Created Material in SAP ERP

2.6.2 Material BOM Creation in SAP

Next step for MTO process is to create bill of materials for the newly created material in SAP ERP. ERP supports several BOM types, however MSP supports only creation of Production BOM in ERP system. For this purpose, MSP supports another flag on product type: isBOMCreationRelevant this flag enables MSP to find those materials in sub line item that need to be part of BOM of the material created in first step.

 

The process also checks if the BOM is already created or not and in case created it does not allow the BOM to be created again. Secondly, it checks whether all the materials included in BOM are existing in ERP system.

The BOM usage type is production BOM (1) and BOM is created in status active. Plant is mandatory parameter for BOM creation. To assert again only those sales item whose product type is marked as isBOMCreationRelevant are considered.

 

Used BAPIs:

  • BAPI_MAT_BOM_EXISTENCE_CHECK
  • BAPI_MATERIAL_EXISTENCECHECK
  • BAPI_MATERIAL_BOM_GROUP_CREATE
Figure 27 - Before ERP BOM Creation in MSP
Figure 27 - Before ERP BOM Creation in MSP
Figure 28 - New bill of material in SAP ERP
Figure 28 - New bill of material in SAP ERP

2.6.3 Routing Creation in SAP

Material Routing is a description of which operations or list of activities that need to be carried out during the production process of that material. It also lists the order or sequence of the activities/operations which need to be carried out at work centres or machines. Sales Item whose product type which is marked as isMaterialCreationRelevant are eligible to create a routing in ERP.

For this purpose, the work centres need to be maintained as master data in MSP system. A work centre is an organizational unit that defines where and when a manufacturing operation can be performed. Routing calculations can be made to work together with internal price engine, a pricing step can be put that is routing relevant and it can calculate the required time taken in each work centre. Check internal price engine guide for more details. Plant is the mandatory parameter in routing creation.

Used BAPIs:

  • BAPI_ROUTING_CREATE
  • BAPI_TRANSACTION_COMMIT
Figure 29 - Input data preparation for routing - 1
Figure 29 - Input data preparation for routing - 1
Figure 30 - Input data preparation for routing - 2
Figure 30 - Input data preparation for routing - 2
Figure 31 - Input Data Preparation For Routing – 3
Figure 31 - Input Data Preparation For Routing – 3
Figure 31 - After Creating Material Routing In SAP ERP
Figure 31 - After Creating Material Routing In SAP ERP
Figure 32 - New material routing in SAP ERP – 1
Figure 32 - New material routing in SAP ERP – 1
Figure 33 - New material routing in SAP-ERP – 2
Figure 33 - New material routing in SAP-ERP – 2

2.6.4  Sales Document Creation in SAP

Sales Document creation happens after a quote is accepted in MSP. To support this the Account of the quote must be available in SAP ERP and should have the Object ERP Id maintained in the MSP. Anyhow for prospect accounts, that are imported from Cloud for Customer or directly in MSP, sales document creation is not supported.

Note that from a process definition point of view MSP will not trigger a creation of Account in ERP. This is because there are several checks and balances (finance approval etc) that are usually taken before an account/prospect is created in ERP.

Once this is done the account need to be synced from SAP Cloud for Customer, so that the ERP Id is available for the prospect or manually added directly in MSP. As a process, In Mind suggests triggering the ERP customer creation via C4C as MSP only uses the customer data that is coming from C4C. Once the ERP ID is available in Cloud for Customer, the sales rep can trigger sync the Account again to MSP.

Once the Account ERP ID is available in MSP, Sales Order creation can be triggered, in addition out details need to be present as well and this includes: Sales Area information, Business partners etc. Once the Sales Order is created in SAP ERP, the quotation is locked in MSP for any changes. From that point onwards, SAP is the owner of the sales document which depending on BAPI used could be a Quote or Order in ERP.

In sales order creation filters are also applied to products going into ERP Oder:
1.Sales item products product type should be marked as isOrderCreationRelevant.
2. The product should be allowed to be exported back to ERP
3. The product should have ERP ID maintained

Data needed:

  • Account ERP ID (Coming for SAP CFC).
  • Material ERP ID.
  • Sales Document Type (needed to control the type of sales order in ERP based on used selection).
  • Purchase order number and requested date.
  • Sales Area information: maintained on quote level and taken from SAP CFC. This includes Sales Org, Distribution Channel and Division.
  • Pricing Date and Requested Date: Maintained on MSP Quote.

MSP can pass variant configuration to SAP ERP system if the use case uses SAP SSC in configuration.

MSP uses the standard BAPI:

  • BAPI_SALESORDER_CREATEFROMDAT2
  • BAPI_TRANSACTION_COMMIT

The first step is to go to Actions-> ERP Helpers-> ERP Sales Doc

Figure 34 - Generate Sales Order
Figure 34 - Generate Sales Order

And click on Generate Sales orders.

As MSP supports Sales Quote Split and creation of multiple orders the system at this point determines how many sales orders need to be generated and in which order which line item needs to be put. Together with split in header price conditions.

One the sales order is generated it looks as shown below.

Figure 35 - Input Data Preparation for Sales Order Creation
Figure 35 - Input Data Preparation for Sales Order Creation

The user can next select the new order and click on create button to send the order into ERP.

Figure 36 - Newly created sales order in SAP ERP
Figure 36 - Newly created sales order in SAP ERP

For MTO process the newly created order can take only the material created in ERP because the rest of the information about that material is already in ERP.

2.6.5 Pricing Procedure Determination

To determine which pricing procedure will be picked in ERP for given combination of sales area data in sales document. Create Sales Order (VA01) and select sales area data. That displays sales document header data and find pricing procedure that is active in ERP.

The following figure shows where to find the pricing procedure of the current sales order.

Figure 37 - Sales order in ERP
Figure 37 - Sales order in ERP
Figure 38 - Pricing procedure in Sales Order in ERP
Figure 38 - Pricing procedure in Sales Order in ERP

Modify pricing procedure determination via ERP customizing V/07.

2.6.6 Reference Distribution Channel for Conditional Lookup

Price condition lookup in ERP is done via keys ‘Sales Organization and ‘Distribution Channel’. Maintained conditions can be expanded to multiple Distribution Channels by defining a reference Distribution Channel.

 

Go to ‘Customizing (SPRO) – Sales and Distribution – Master Data – Define Common Distribution Channels’ and maintain reference distribution channel for condition.

2.7  Product Substitution

Product substitution also known as material substitution is used to replace an existing product in a quote with another. This could be because of the older product is no longer continued and is replaced by the new product.

MSP supports two modes in product substitution, automatic substitution and manual substitution. Automatic substitution, as the name implies silently replaces the old product with the new product. In Manual substitution mode, if a substitute product is found, user is notified, and it is up to the user to decide whether to substitute or not.

Related Boolean settings:

  • SettingEnableProductSubstitution (Enable product substitution) – enable / disable product substitution in trigger points mentioned later in this section for the entire MSP.
  • SettingEnableProductSubstitutionAtQuoteSubmit (Enable product substitution at quote submit) – enable / disable automatic mode product substitution at quote submit. This will be effective only if Enable product substitution setting is turned on.

2.7.1  Product Substitution Scheme

MSP Product Substitution is a re-implementation of an SAP ERP feature popularly known as: material determination/substitution. In this In Mind uses the same data as a customer might have created in their ERP system and follows the same logic in principle to substitute a product.

The data for product substitution is maintained in lookup tables in MSP. In addition, a Product Substitution Scheme is used to define the sequence of steps and the lookup tables involved in each step to make effect a substitution. Thus, making the implementation independent of SAP ERP Tables. However, as most customer would already have the data in standard ERP tables, we take example by referring to them here.

In MSP we have also added three look up tables by default. These tables are:

  • KOTD001 – This table holds information of an on old product, substitution validity period and condition record number.
  • KOTD502 – This table holds information on old product, substitution validity period, company code and condition record number.
  • KONDD – This table holds information on condition record number, new product and substitution reason.

For more information on these tables please refer to SAP ERP documentation.

The important thing to note is that if a customer chooses to use this data in MSP, the above mentioned three tables three tables can be synchronized to MSP directly without need to create them.

The corresponding lookup table in MSP are:

Table 1 – KOTD001 Lookup Table

Field NameDescriptionSearch Expression
MATWAOld product’s ERP IDSalesItem().isProduct.objectERPId[0]
DATABValid from date
DATBIValid to date
KNUMHCondition record number

 

Table 2 – KOTD502 Lookup Table

Field NameDescriptionSearch Expression
MATWAOld product’s ERP IDSalesItem().isProduct.objectERPId[0]
BUKRSCompany ERP IDQuote().hasSalesOrg.containsCompany.

objectERPId[0]

DATABValid from date
DATBIValid to date
KNUMHCondition record number

 

Table 3 -KONDD Lookup Table

Field NameDescriptionSearch Expression
KNUMHCondition record number
SMATNNew product’s ERP ID
SUGRDReason for material substitution

NOTE: Product substitution reason ERP IDs (which matches SUGRD of KONDD lookup table) needs to be maintained in master data, as shown below.

Figure 39 - Product Substitution Reason from master data
Figure 39 - Product Substitution Reason from master data

Product substitution determination logic goes through the steps defined in the scheme one by one in the defined sequence, in each step it looks for a matching record with the given input and if a matching record is found it returns the condition record number (KNUMH) of that record. Once a condition record number is found, the rest of the steps are not evaluated.

For the found condition record number, MSP next tries to match the condition record number with a record in KONDD table. If found, the new product ERP Id and the reason for substitution ERP ID is retrieved from the matching record. Also note that automatic or manual substitution is based on the reason for substitution.

Figure 40 - Product Substitution- Scheme Creation
Figure 40 - Product Substitution- Scheme Creation
Figure 41 - Creation of Company Code Based Substitution Step
Figure 41 - Creation of Company Code Based Substitution Step
Figure 41 - Creation of Company Code Based Substitution Step
Figure 41 - Creation of Company Code Based Substitution Step
Figure 42 - Creation of Global Substitution Step
Figure 42 - Creation of Global Substitution Step
Figure 42 - Creation of Global Substitution Step
Figure 42 - Creation of Global Substitution Step
Figure 43 - Activate Product Substitution Scheme
Figure 43 - Activate Product Substitution Scheme

For each step of the scheme, quote pricing date and the data points defined by the search expressions of the lookup table are made available to the step. For more information on search expression please refer to Internal Price Engine Guide.

Taking an example here, in “Company Code Based Substitution step” in Figure 41 above, since table KOTD502 is being used, which uses search expression for old product ERP ID and company ERP ID. These two attributes are supplied as input to the table apart from the default value the quote pricing date. Because the condition record validity is determined based on quote pricing date.

Also note that the scheme is used only to find a matching condition record number. Once found, finding the product to substitute with is determined from KONDD which, is not directly part of the scheme, but is an inbuilt step/logic of the implementation.

2.7.2 Product substitution trigger points

Please refer to the following sample data in lookup tables for the rest of this section.

Figure 44 - Sample Data in KOTD001 Lookup Table
Figure 44 - Sample Data in KOTD001 Lookup Table
Figure 45 - Sample Data in KONDD Lookup Table
Figure 45 - Sample Data in KONDD Lookup Table
2.7.2.1  Adding a product to quote

Product substitution kicks in when a product is added to the quote. That is at the time of line item creation. The added product is looked up for a substitute product as per material determination logic and if found the product is either automatically replaces or shown to user to be manually replaced.

2.7.2.1.1 Automatic substitution mode
Figure 46 - Selecting a Product from Product Catalog
Figure 46 - Selecting a Product from Product Catalog
Figure 47 - Automatic Substitution and Notification
Figure 47 - Automatic Substitution and Notification

In the example product the added product was automatically substituted.

2.7.2.1.2  Manual substitution mode
Figure 48 - Selecting a Product from Product Catalog
Figure 48 - Selecting a Product from Product Catalog
Figure 49 - Manual Substitution Prompt for the User to Decide on the Substitution
Figure 49 - Manual Substitution Prompt for the User to Decide on the Substitution

The user can choose to manually replace the product in the shown screen.

Figure 50 - Manual Execution of Product Substitution
Figure 50 - Manual Execution of Product Substitution

At any point in quote if the user wants to check for substitute product, he can do so by clicking the action as shown above. As no line items were selected the system will try to check the product substitution for all the sales items in the quote. However, if the user selects sales items and click on the same button, product substitution will be executed only for those selected sales items. In both the cases, the subsequent action, that is the result of substitution being automatic or manual, is governed by the reason for the substitution as maintained in the data.

2.7.2.1.3 As quote pre-submit check

Another system enforced yet setting controlled trigger point for material substitution is at Quote Submit. MSP will automatically look for substitute materials at this point for all the items in the quote. For this to work one has to keep the following settings enabled:

  • SettingEnableProductSubstitution (Enable product substitution in general)
  • SettingEnableProductSubstitutionAtQuoteSubmit (Enable product substitution at quote submit)

If substitute products with substitution reason automatic are found, quote submission process is stopped, and user is prompted to replace the products manually.

Figure 51 - Product Substitution Pop up at Quote Submit
Figure 51 - Product Substitution Pop up at Quote Submit

Figure 51 shows the example where upon quote submit a substitute material was found. Since the substitution reason is automatic, user needs to replace the products for quote to get submitted.

2.8 SAP Solution Sales Configurator Integration (SSC)

2.8.1 BAPI Overview

  • ECC_SCE_EXTRACT

copy all kbs found in SCEKB into COMM_CFGKB

  • ECC_SCE_REQUEST

copy a specific kb from SCEKB into COMM_CFGKB

  • COM_CFG_DB_DELETE_KB

delete a specific kb from COMM_CFGKB

2.8.2 BAPI Patches

SAP made some changes within ERP which prevents successful usage of some required BAPIs from MSP. Most likely all ERP systems running SAP_AP releases >= 23 are affected. The SAP_AP release info can be found in System -> Status -> Component information.

SAP AP

If the SAP_AP release is >=23 the BAPI EXTRACT_DATA needs to be patched:

Patch for SAP_AP 700 Level 26 (Lines 50 to 55).

IF sy-subrc <> 0.

*{  REPLACE        DEVK900005      1

*\ RAISE internal_error. “do not proceed if caller is not from VMC

*RAISE internal_error. “do not proceed if caller is not from VMC

*} REPLACE

ENDIF.

Patch for SAP_AP 700 Level 29 (Lines 35 to 44)

SAP moved the VMC check into if_ex_extract_data-check_table_access so it’s easier to comment out this invocation.

* check whether the access onto this table is allowed or not get badi lr_badi.

call badi lr_badi->check_table_access

exporting

iv_table_name = tabname

importing

ev_access_allowed = lv_allowed.

if lv_allowed = space.

raise table_not_found.

endif.

The same patch needs to be applied to BAPI SELECT_COUNT if support package SAPKNA7032 is installed (sap note 1995783).

Attention – the BAPI SD_SALES_DOCU_MAINTAIN news to be patched in current SAP releases to enable transfer of manually entered pricing conditions.

Patch (region around line 1062)

*{             REPLACE

*\             if ( pricingtype ca ‘BCG’ and call_from_crm = charx ) and

if ( pricingtype ca ‘BCG’ and call_bapi = charx ) and

*}             REPLACE

2.8.3 Create Configurator Profile for LO-VC Model

After successful creation of LOVC model in ERP, we need to define/perform below activities as a prerequisite to get in touch with In Mind MSP system for seem less process flow.

Step 1: Define Configuration Profile.

Transaction Code: CU41

Transaction Code CU41

Each configuration profile must be assigned to at least one class with a class type that supports variant configuration.

Step 2: Define Knowledge Base object.

Transaction Code:  CU3

Transaction Code CU3

Here we need to assign configuration profile to KB Object.

Step 3: Runtime Version for KB object.

Transaction Code: CU34

Transaction Code CU34

2.8.4 IPC Compliance Check

The MSP system is only able to render Knowledge Bases and Prices from ERP with SAP SSC which are IPC Compliant. This means that ABAP based P-Functions, User Exits and Routines cannot be executed by SAP SSC. In order to check whether a KB is IPC Compliant the following tests need to be performed. Only then a runtime version can be generated that is fully working in MSP. Otherwise certain Configuration or Price information will be missing, and KB is incomplete.

IPC Compliance Check

Here we should perform consistency check to verify IPC compliance by click the Icon

Go back (F3) and then Generate and save the runtime version.

2.8.5 Make ERP Product Model Runtime Version Available

Make ERP Product Model Runtime Version Available

Go to SE37 and open function module ECC_SCE_REQUEST. Enter knowledge base name and version and execute.

Make ERP Product Model Runtime Version Available
Make ERP Product Model Runtime Version Available

Please note that, if we make any changes related to LOVC model after execution of ECC_SCE_REQUEST FM, we should create a new run time version for Knowledge Base Object and ECC_SCE _REQUEST should execute again with success message.

Apart from above, another important feature is “for the LOVC model data sync to MSP system, custom table Z_ISS_MAT should be defined and maintained with required sales org and distribution channel.

Make ERP Product Model Runtime Version Available
Make ERP Product Model Runtime Version Available
Make ERP Product Model Runtime Version Available

This custom table required to display the Product codes which are associated with given parameters as Sales Org and Distribution Channel.

2.8.6 ERP User for sample product model

For sample product modelling and testing, an ERP user is required with the following permissions:

Roles assigned to User:

  • SAP_LO_VC_MAINTAIN
  • SAP_LO_MD_BOM_MAINTAIN
  • SAP_CA_CL_MAINTAIN

 

Plus, usage of transactions:

  • CT01/CT02/CT03/CT04
  • CL01/CL02/CL03/CL04
  • MM01/MM02/MM03
  • VK11/VK12/VK13
  • VK30
  • VA01/VA02/VA03
  • VA21/VA22/VA23
  • SE37 (to execute function module ECC_SCE_REQUEST)
  • SE11, SE16