Materials are transported between the plants belonging to the same company code is known as Intra Company STO Where the supplying and receiving plants are under the same company code.

Configurations to-do from SD Side:

• Create Sales organization
  
• Create Distribution Channel
  
• Create Check Division
  
• Create Customer Master
  
• Assign Sales Organization to Company Code
  
• Assign Distribution to Sales organization
  
• Assign Division to Sales organization
  
• Set up Sales Area
  
• Assign Sales organization – Distribution Channel – Plant

Create Sales organization:

Configuration: SPRO –> IMG –> Enterprise Structure –> Definition –> Sales and Distribution –> Define, Copy, delete, check sales organization

T – Code: OVX5

We can create Sales organization by copying from the Standard one or we can enter create manually in New Entries.

Here I Create the Sales organization by copying from the Standard one.

Create Distribution Channel:

Configuration: SPRO –> IMG –> Enterprise Structure –> Definition –> Sales and Distribution –> Define, copy, delete, check distribution channel

Transaction Code: OVXI

We can create the Distribution channel by copying from the Standard one or we can enter create manually in New Entries

Here I Create the Distribution channel by copying from the Standard one.

Create Check Division:

Configuration: SPRO –> IMG –> Enterprise Structure –> Definition –> Logistics General –> Define, Copy, Delete, check division

Transaction Code: OVXB

We can create the Di vision by copying from the Standard one or we can enter create manually in New Entries

Here I Create the Division by copying from the Standard one.

Assign Sales Organization to Company Code:

Configuration: SPRO –> IMG –> Enterprise Structure –> Assignment –> Sales organization –> Assign Sales organization to Company Code

Transaction Code: OVX3

Assign Distribution to Sales organization:

Configuration: SPRO –> IMG –> Enterprise Structure –> Assignment –> Sales and Distribution –> Assign distribution channel to sales organization

Transaction Code: OVXK

Check Distribution Channel is assigned to the Sales organization or not. If not assigned, click on new entries to assign.

Assign Division to Sales organization:

Configuration: SPRO –> IMG –> Enterprise Structure –> Assignment –> Sales and Distribution –> Assign Division to sales organization

Transaction Code: OVXA

Check Division is assigned to Sales organization or not. If not assigned, click on new entries to assign.

Set up Sales Area:

Configuration: SPRO –> IMG –> Enterprise Structure –> Assignment –> Sales and Distribution –> Setup Sales Area

Transaction Code: OVXG

In Set up Sales Area we assign Sales organization –> Distribution Channel –> Check Division.

Check if they are assigned or not. If they are maintained Click on the new entries to assign.

Assign sales organization – distribution channel – plant:

Configuration: SPRO –> IMG –> Enterprise Structure –> Assignment –> Sales and Distribution –> Assign sales organization –> Distribution channel –> Plant

Transaction Code: OVX6

Assign Sales organization and Distribution Channel to both Supplying plant and Receiving plant.

These are the Configurations settings maintained from SD Side.

Note: In S/4 Hana we can create both Supplier and Customer in a single Transaction Code BP.

For the Intra Company STO:

• Creating in intra company STO we can create both supplier and customer in the same company code.

For the Supplier:

• In FLVN00 create the supplier in supplying Company Code.
  
• In FLVN01 create the Supplier in supplying purchasing organization and assign the Supplying plant in the vendor General Data.

For the Customer:

• Create the Customer in the Supplying Company Code of FLCU00.
  
• Create the Customer in Supplying Sales Organization, Distribution Channel and Division in FLCU01.

Now we Maintain the Configurations settings From MM Side

Here I Create the material –> 13000083 and extended to both Plants.

In Basic Data 1 Maintain Sales Division.

In Sales Organization 1 View maintain the Tax Classification

In Sales organization –>2 View Maintain Item category group – NORM.

In Sales: General Data View

Maintain Availability Check – 01

Transportation Group – 0001

Loading Group – 0001

After maintained all required fields click on save.

Extend the Material to Receiving Plant – 9002

Go to MM01 Transaction code.

• Enter the Material Number, Industry Sector and Material Type.
  
• Enter the Receiving Plant and Receiving Storage location.

Check and enter the missing fields in the selected views.

Define Shipping Point:

• Shipping point is an independent organizational entity and is required to ship the products to a customer.

Shipping point processes and monitors the deliveries as well as goods issue is carried out.

Configuration: SPRO –> IMG –> Enterprise Structure –> Definition – >Logistics Execution –> Define, Copy, Delete, Check shipping point

Transaction Code: OVXD

Here we can Create the Shipping Point by Copying from the Standard one or we can create new one by clicking on the new entries.

Here I create the Shipping Point by Copying from the standard one.

Assign Shipping Point to Plant:

Configuration: SPRO –> IMG –> Enterprise Structure –> Assignment –> Logistics Execution –> Assign shipping point to plant

Transaction code: OVXC

Select the Plant and click on the Assign tab and choose the shipping Point to assign to the Plant.

Shipping Point Determination:

A Shipping Point is an independent organizational entity where the issuance and delivery processing of goods take place.

• SAP Shipping point determination depends on the following factors: Shipping terms and conditions from the customer master record (shipping screen).

Configuration: SPRO –> IMG –> Logistics Execution –> Shipping –> Basic Shipping Functions –> Shipping Point and Goods Receiving Point Determination –> Assign Shipping Points

Transaction Code: OVL2

Define Shipping Data for Plants:

Configuration: SPRO –> IMG –> Material Management –> Purchasing –> Purchase order –> Set up Stock Transport order –> Define Shipping Data for Plants

For Supplying Plant – 9001

Select the Plant and click on the details button, or double click on the line item.

Maintain the Sales organization – Distribution Chaneel – Check Division

For the Receiving Plant:

• Enter the Customer Number

Assign Delivery Type and Checking Rule:

Configuration: SPRO –> IMG –> Material Management –> Purchasing –> Purchase order –> Set up Stock Transport order –> Assign Delivery Type and Checking Rule

For Intra Company STO, The Delivery Type should be NL.

Assign Delivery Type and Checking Rule to the Document Type and Suppling Plant.

Assign Document Type, One-Step Procedure, under delivery Tolerance:

Configuration: SPRO –> IMG –> Material Management –> Purchasing –> Purchase order –> Set up Stock Transport order –> Assign Document Type, One-Step Procedure, Under delivery Tolerance

By clicking on New Entries, we can assign Supplying plant and Delivering Plant to Document type (or) else by copying the existing one change the plants and document type.

If we tick the checkbox the system thinks the STO process should be a one-step Procedure.

Create Purchase Order in ME21N

• Document Type will be “UB” for Intra Company STO Process.
  
• If we maintain all the back-end settings correctly then only the shipping tab will appear while creating Purchase order.

Stock Transp. Order created under the number 4500000913.

Here I am creating the Inter Company Code STO in Two-Step process.

Create the Outbound Delivery in (VL01N, VL10B, VL10D)

Here I am creating the Outbound Delivery in VL10D Transaction Code.

• Enter the Shipping Point and Purchase order Number and click on Execute Button.

Select the PO Number and click on the Background button.

Another line will be generated with Green Mark. Select that line and click on the Delivery log creation Tab.

Place the Cursor and click on the documents button the Outbound Delivery Number will be displayed.

The Outbound Delivery Number is – 80000366.

Next Change the Outbound Delivery Number (i.e., Post Goods Issue in VLO2N)

Enter the Picked Quantity, Storage location and check the Incompleteness data.

If all the data is ok, click on the Post Goods Issue or save button.

Replenishment Dlv. 80000366 has been saved

Now Check the Purchase order History in the Purchase Order in ME23N.

The Supplying Plant has issued the Goods, but the stock will be in Transit until the Receiving the Plant does the Goods Movement.

Accounting Entries:

BSX – (DR)

BSX – (CR)

Check the Stock Transit in MB5T

Now done the Goods Movement in MIGO

Goods Receipt –> Purchase order

Material document 178 posted.

No subsequent document found in accounting.

Now Check the Purchase Order History in the PO.

Goto ME23N (Display of the Purchase Order)

The post Intra-Company STO Process (Two Step Process) in S/4 HANA appeared first on ERP Q&A.

SAP Query is a tool that allows you to create reports even without programming. SAP queries are based on InfoSets – these are the areas that provide special views of a logical database and define which fields of the database can be used in queries. SAP queries can be shared with any users via assigning InfoSets to user groups.

SAP Query – Overview:

• SAP Query is used to create reports for users who have little knowledge about SAP Table data storage structure. SAP Query allows evaluating data in the SAP system.
  
• SAP Query offers users a broad range of ways to define reporting programs and create different types of reports such as basic lists, statistics, and ranked lists.

Following are the major components which are associated with SAP Query:

• Info Sets – Are based for the Query and it contains one or more database table details.
  
• Queries – For the User to create and generate the Query.
  
• User Group – To restrict set of Users for a specific Query plus for Authorizations.
  
• Quick Viewer – A simple tool for quick report generation.

SAP Query – Creation:

Creation of Quick Viewer: (Transaction code – SQVI)

SQVI is a simple ad-hoc report that can be written directly in the production system, I.e., there is no need for transporting information between systems. Any functional consultant (or even business user) with a good understanding of SAP tables can write a query with SQVI.

Enter the Title for your Report and Enter the Description

Select on the first tab (List Fields) which fields you want to see in your report. For Example, we select from the right column the fields “Country Key”, “Name 1”, “Vendor Account Group” and “Postal Code” and press the “Arrow to the left”, so these fields are available for the report, by being displayed on the left column.

If you want to see the Field Names in Technical click on the above button as highlight in the picture or else press SHIFT+F5.

Select on the second tab the sort order. Mark the fields you want and choose the desired criteria. In our case we will order the vendor by their names.

On the third tab you must define the selection fields. Choose from the right column the fields you need. You may also change the order in which they may appear later with the transaction.

After Maintaining all the data click on the save button.

After clicking on the save button click on the Execute button.

You will see a screen, like one from a standard program, but with your own description and specifically for the fields you have defined. For our example we select a specific country and press the “Execute” button.

Now we can see the result.

Note:

The Difference between the SQVI and SQ01/SQ02 are the Queries which we are written in SQ02/SQ01 are Transportable. Where in SQVI we directly written the Queries in production system.

SAP Query – Area:

SAP Query Area is a set of objects having queries, InfoSets and User Groups which are consistent.

Following Query Areas:

• Standard Area – They are Client Specific Queries and do not create a Work Bench Request.
  
• Global Area – Queries in the Global Area are Client Independent.

SAP databases have several numbers of tables in which the transactions, master data gets stored and it’s practically not feasible to have all such fields for selection when creating a query. Hence before the start of creating a query, InfoSet creation is required.

First create the User Groups in SQ03:

Create a logical set of User Group to which the InfoSet Queries would be assigned.

Enter the Description in the User Group and click on Create button.

Enter the Description and click on the save.

Now Create the Infosets in SQ02 Transaction Code:

The InfoSet creation can be made with the Combination of Tables (Table Join), Direct read from a Single Table or with the help of Logical Database.

Enter the Description in the InfoSet tab and click on the create button.

Here I am using the tables EKKO and EKPO.

Enter the Description in the Report Tab and Enter the Table Name and click on the Enter or else click on the Tick mark as shown below.

Click on the insert table button to add more tables.

Enter the table Names one by one by clicking on the Insert Table Tab.

If you want to join the tables, you can join by clicking on the Join Conditions Tab.

Here I Join

EKKO with EKPO by clicking on the Join Conditions Button.

After joining the tables click on the back button as shown in the below picture.

Select the Include key fields tab and click on the Enter button or else on Tick mark which is shown below.

Next, we’ll create field groups and add data fields per the requirement.

For our use case, we are not doing an alias table or extras. So, we can just hit the generate option,

In the Next step we can assign the Infoset to the Role/User Group Assignment in SQ02 Transaction code.

Select the User Group which we are created in the SQ03 Transaction Code. By selecting the User group click on the save Button.

We can assign Z_POREPORT to Z_PODATA.

Click on the Generate Button

In SQ03 We can Assign Users to InfoSets

Click on the Assign Infoset tab as shown in the picture.

Select the Infoset checkbox and click on the save button.

Next go to the Transaction Code SQ01, Enter the title in the Query Tab. Here I have entered My user Group as Title Description.

We should have to enter Either Infoset Title or User Group Title as Description in the while creating the Query in the SQ01 then only the system Accepting or else the system throws error User Group does not Exit.

By Entering the Title click on the create button. Select the Infoset that we created and click on the Green Tick mark as shown in the below picture.

Enter the Title Description and click on the Basic list Tab.

Click on the Enter Button or the Tick mark as shown in the picture.

In the data fields section, choose fields for selection and list (output).

List Fields are the output fields which have to be displayed in the Reporting.

Selection fields are the input fields.

Before clicking on the saving button. We can check whether the scenario is working properly or not by clicking on the Test button.

Here I am running the Testing scenario, Here I am clicking on the Execute button by entering the Company code.

The scenario is working properly.

Click on the save button.

Click on the Execute button.

By Entering the company Code click on the Execute Button.

Comparison between and SQ01 and SQVI:

1. SQ01 is a saved query that can be accessed by other people, SQVI can only be accessed by the user who wrote the query.
   
2. SQ01 allows for additional fields to be defined and populated, SQVI only allows for the use of fields already defined in the tables.
   
3. SQ01 will automatically bring in text descriptions (such as item description or customer name) when using fields that would have a text field associated, SQVI did not.

Process to Customize the Transaction Code:

For the report we just created, you shouldn’t give end users access to T-codes SQ02 and SQ01. It is not a good user experience to have your business folks play around with these technical transactions.

So, for a complete end-user experience, you should create a report in SQ02/SQ01 and then associate a Z transaction code (custom code) with it. SAP allows you to create these Z transaction codes, which can be used like any other standard transaction code.

To do this, first go to T-code SQ01 and follow this path:

Query > More Functions > Generate Program

Query > More Functions > Display Report Name

Copy the program name.

Next, go to T-code SE93.

Enter a unique transaction code starting with Z, Enter a name in the short text field, select the radio button for “program and selection screen (report transaction).”

Click on the Enter button or the Green Tick Mark after Entering the short text and by selecting the start object.

Enter the programming Name in the Program tab and click on the check button to check whether it contains any Inconsistent or not.

By checking the data, click on the Save Button.

Click on the Local Object.

The customized Transaction code was created successfully.

Enter the Customized Transaction code in Command Bar.

We can get the initial screen directly after Executing the Transaction code.

By Entering the Company Code Click on the Execute Button.

To control the User Authorization, we have to follow the below steps:

• First you have to create the use group in transaction SQ03 and assign the infoset to this user group with transaction SQ02.
  
• Use the standard authorization object S_Query with transaction SU21 and assign the authorization groups. Now you need to assign to the user profiles or Roles directly so that we can the restrict the users to access the queries and infoset.

The post SAP Query appeared first on ERP Q&A.

In this blog-post, SAP Sourcing and Procurement consultant will be able to learn the concept and mapping procedure of Subcontracting Process with two different plants i.e one plant creating the PO and other plant is issuing the components to the Subcontracting vendor in SAP system.

Subcontracting process is generally used in most of the industries. In subcontracting process, raw materials are provided to subcontracting vendor. It’s being processed by subcontracting vendor, convert it to semi-finish material and deliver back.

Sometimes, components may not be available with the plant where the subcontracting PO was created but components will be available at the another plant which is under the same company code to provide the components to the subcontractor.

There are two plants under the same company code – say Plant (S001) and Plant (US99).

Plant (S001) will issue the Raw materials to subcontractor (Ranemadras pvt ltd (4000020)) and the vendor (Ranemadras pvt ltd (4000020)) will send the processed goods to the Plant (US99), against the subcontract PO.

Here, My Sub-contract Vendor is Ranemadras pvt ltd (4000020)

Please follow the Configuration steps

• Create a Customized special procurement type I.e., Sub-Contracting.

IMG->Material Management->Consumption Based -Planning -> Master Data-> Define Special Procurement Types

Create a special procurement Type, say S1 for plant (US99) by copying the special

procurement type 30.

Check the tick mark withdrawal alternate plant as well as the issuing plant (S001) as shown above:

Look at the above, I have highlighted in red

Note: Material Master should be existing for both plants i.e., sending and receiving plant

• Create a Raw material for Plant (US99) via MM01

For plant S001

Material 20039 created

Same Material should be extended for the plant US99

Go to MRP2 view and maintain the special procurement Type “S1” for Plant US99 Material 20039

• Creating Finished Product for both plants S001& US99 via MM01

Material 7 created

• Create BOM for plant US99 materials

Creating BOM for material 7

Note: In S/4HANA Production Version is the mandatory, why because without Production Version components will not explore at PO.

• Create a Production Version Via SE38, or C223

Program: CS_BOM_PROVDER_MIGRATION

Select the line, and then click on Approve all

• Create Sub-Contracting PO for Plant (US99)

Here, must enter the receiving plant (US99),

Click on Components

Here, we can see the issuing plant S001

Standard PO created under the number 4500000347

• Post Goods Issues ME2O

See the issuing plant S001

• Check the Stock using MMBE

• Components Receipt via MIGO

Please observe, receiving plant US99 & supplying plant S001

i.e., issuing the Raw material to the sub-contracting vendor from plant S001, and finished goods receiving to the Plant US99

please find, Sub-Contracting Vendor

Material document 6000000011 posted,

Check the accounting entries

Result: The Main material is received in plant US99 from subcontractor (Ranemadras pvt ltd (4000020)) and the components are consumed from alternate plant S001

• Check the Stock via MMBE

create Invoice via MIRO for sub-contracting service charge with ref. PO.

Conclusion: This article explained the process scenario of Subcontracting where issuing the components from another plant in SAP Procurement also it shows how the production version can be used to explore the BOM at PO in S4 HANA. I believe, It will be helpful and will provide sufficient information to the readers.

The post Sub-Contracting where components Issue from one plant and Finished product received by another Plant appeared first on ERP Q&A.

Batch Management increases production, improves quality, reduces cycle times, and facilitates compliance for your company to meet most industry standards. A batch is a consistent unit of material that’s defined in your SAP system with unique specifications. A batch represents a single subset of the total quantity of material that is held and produced during a production run. Many production runs can be used to produce a production lot.

In a real-world scenario, you’ll be receiving one material in a number of batches, and this will be kept in storage location stock or in warehouse storage bins. When you want issue the issue the material to production, you need to have a strategy to choose the batch. You can define the strategy in the system, where the system determines and offers up the right batch to pick. This process is called batch determination.

Batch determination uses the condition technique. Strategy records of the respective application determine batch determination. Different strategy records in the system have to be created for different purposes such as goods issue to production, goods issue to customer and so on. Batch determination can be used in the goods movement, production/process order, sales order/delivery and transfer order functions.

Configuration:

Step 1: Creation of Condition table.

Spro—Log Gen –Batch Management—Batch Determination and Batch check—Condition table—Define Inventory Management Condition tables—Create Condition table for Inventory Management.

Step 2: Define Access Sequence

Spro—Log Gen –Batch Management—Batch Determination and Batch check—Access Sequence —Define Inventory Management Access Sequence —Create Access Sequence for Inventory Management.

Standard is ME01.

Step 3: Strategy Type

Spro—Log Gen –Batch Management—Batch Determination and Batch check—Strategy types—Define Inventory Management Strategy type. (and assign access sequence which defined above)

Standard ME01.

Step 4: Batch Search Procedure.

Spro—Log Gen –Batch Management—Batch Determination and Batch check—Batch Search Procedure –Define Inventory Management Search Procedure.

Define Procedure and assign strategy type.

Step 5: Batch Search Procedure allocation

Spro—Log Gen –Batch Management—Batch Determination and Batch check—Batch Search Procedure allocation and check activation – Allocate IM search procedure/Active check.

Step 6: Spro—Log Gen –Batch Management—Shelf life Expiration Date—Set Expiration Date Check.

Master Data:

Step 7: Use T -code BMSM when you are batch determination first time in client by which system will copy all standard char from 000 Client.

Step 8: Create Class (CL02)—BATCH_CLS

Below assigned char’s are standard Characteristics

Step 9: Create Material Master : 5000000040

Step 10: Create selection class (CL02)– BATCH_SEL_CLS

Easy Access—Logistics—Central Functions—Batch Management—Batch Determination—Selection and Sort—Selection Classes—Create (BMC1)

Step 11: Create Sort rule

Easy Access—Logistics—Central Functions—Batch Management—Batch Determination—Selection and Sort—Sort rule—Create(CU70)(Ascending = First in First out)

Step 12: Define Batch search strategy.

Easy Access—Logistics—Central Functions—Batch Management—Batch Determination—Batch Search strategy—For Inventory Management (MBC1) Create.

From step 8 and 9

Step 13: GR with 501 Movement type here enter the date of manufacturing.

Stock in MMBE:

Step 14: Goods issue against cost centre.

If we observe based on the batch which is expiring, system is proposing that batch First(FEFO—First expiry first out)

Let’s change the Sorting from Ascending to descending in Strategy in CU70 and issue goods.

LEFO (Last Expiry First out)

Step 15: Now will check FIFO and LIFO based on GR Date for which we need to create new sort sequence in CU70 as shown below.

Step 16: Now assign the new sort rule in Strategy in MBC2 and strategy Type

Do Goods issue.

Lets change to ascending in CU71(LIFO)

The post Batch determination in Inventory Management for FEFO,FIFO,LIFO processes appeared first on ERP Q&A.

Last week, I was giving a demo to customer on “Supplier segmentation & evaluation” in area of procurement & sourcing in SAP S/4HANA ( on-premise). While explaining newly introduced feature purchasing categories via SAP FIORI app “Manage Purchasing Categories” , customer raised a very valid question.

Customer question – We have a supplier base of 1 million & some of them are dormant from months, most of them are involved in low business value transactions etc. We really do not know, how best we can cluster suppliers based on available invoice data. With limited IT team bandwidth we cannot perform classification of all 1 million suppliers.

This question motivated me to perform a POC(proof-of-concept) to cluster suppliers based on available Invoice data with the help of ML unsupervised algorithm. It does not make lot of sense to create purchasing categories & perform supplier evaluation on all the suppliers. This POC is additional mechanism to filter non strategic suppliers before actual supplier classification & evaluation.

The idea is to show customer that using ML unsupervised learning algorithm, suppliers can be screened & supplier evaluation can be performed on smaller number of strategic suppliers to save time & effort of purchasing department.

To accomplish this POC, I have written Python code with ML KMeans algorithm to perform clustering of supplier before actual supplier classification & segmentation phase. Coding is done in Jupyter notebook & to understand this POC it is absolutely not necessary to understand python code. I have added code snippet for technical folks. Optional code snippet is added in each step under section “POC Execution”.

Objective:

The Aim of this POC is to screen suppliers based on RFM (Recency, Frequency, Monetary Value) parameters before performing actual supplier classification. It is first & basic level of refinement before creating purchasing categories in SAP S/4HANA(on premise) system. Below is more details of RFM methodology.

• R (Recency): Number of days since last invoice raised by supplier to check from how long the supplier is dormant.

Ex – How recent supplier have supplied the material – 50 Days

• F (Frequency): Number of transactions per supplier in given time frame

Ex – How Frequently procurement is done with supplier – 100 invoices raised in given timeframe

• M (Monetary Value) – How much procurement done with supplier in $

Ex – Total 100$ worth of invoices raised by supplier done in given timeframe

Business Value:

• Reduce workload of supplier screening & evaluation team as we get refined list of strategic suppliers after the exercise.
  
• Identify strategically important suppliers which fall under high RFM cluster. Supplier with recent, high value monetary transactions.
  
• Improves accuracy of supplier scoring & evaluation phase.

POC Execution:

This problem is a clear candidate of Unsupervised machine learning use case as Output/Label is not predefined & we are expected to Cluster suppliers using ML Algorithm.

Implementation of data science POC from scratch tend to become too technical, I am not denying that but there is equal involvement of functional counterpart in each stage. At each stage I will share important points which a functional expert can drive & discuss with customer.

Business & data understanding

Business understanding is shared in section Background & objective of POC.

List of 500k Invoice transactions taken from Jan 2019 to Dec 2020, sample Excel data:

Columns :

• InvoiceNo. – Unique invoice number (Under 1 Invoice number multiple material code are invoiced, Hence more than 1 row exist per invoice in dataset)
  
• Material Code – Material Invoiced
  
• Invoicing party – Supplier
  
• Quantity – Invoice quantity of material code invoices at UnitPrice.
  
• InvoiceDate – invoicing date with timestamp

Optional* – Read excel, check data types & important statistical parameters

Data Preparation

Data preparation is very important step before model building. Following are important questions answered in this step.

• What to do with missing values in the dataset(Excel in this case) – Ex – Delete or replace missing data with mean/median/mode

Most of the times data may not be complete & is plagued with missing values. Hence functional consultant are expected to discuss missing value issue before model building. It is required to treat missing values in dataset by either deletion of columns or rows with missing values Or by replacing them with statistical mean/mode/median. There are lot of ways of dealing missing values however in this POC we have dropped rows with missing values as there was no scarcity of data.

Functional consultant is expected to discuss treatment of missing values with customer.

Optional* – Code snippet to highlight % of missing values & dropping rows with missing values.

• Drive important features/columns out of existing dataset columns. Ex – Recency, Frequency, Monetary

This is very important step as part of data preparation as it involves creation of new features/columns to increase insights in given dataset. To perform supplier clustering on RFM (Recency, Frequency, Monetary ) parameters it is required to create three additional columns (amount, recency & frequency) to depict recency,frequency & monetary value by grouping existing data.

Monetary Value: Total invoice transaction amount per supplier – Group by supplier on Amount field (calculated by multiplying Quantity * Unit Price)

Optional*

Frequency: Frequency of invoice transaction per supplier – Group by supplier & count transaction per supplier.

Optional*

Recency: Last Invoice transaction done by supplier from today in Days.

Optional*

Final dataset prepared based on RFM analysis.

• How outliers are treated ?

Outliers are data points which holds values less & more than lower band & higher band of boxplot. Below is depiction of outliers in statistical terms

Outliers highly influence clustering of suppliers, Hence treatment of outliers are important before model building & driving new columns.

In this POC since ample amount of dataset was available I just deleted outliers present in column Recency, Frequency & Monetary value.

• Share the Insights with customer after exploratory data Analysis.

Ex – Highest number of Tx observed in UK Or Top 10 suppliers with business value

Modeling, evaluation & deployment

Determination is optimum number of clusters precedes model building & evaluation.

There are methods like Silhouette Analysis & elbow curve to determine optimum number of clusters. However, it is always wise to take first feedback from customer on number of clusters. Based on business discussion primarily on customer workload bandwidth, hence customer advised to have 3 clusters.

Multiple unsupervised learning algorithms like KMeans, Random forest, Decision tree can be used. Before finalizing algorithms for clustering it is important to understand pros & cons of each of them. Explaining pros & cons of each of them is a huge topic in itself & hence not explained here. For this POC we used KMeans clustering algorithm. Below is the summary

• No. of cluster – 3, tagged as (0,1,2)
  
• Model employed – Kmeans
  
• Model learning Iterations – 50

Optional*

Graphical display of Clusters

Frequency – Scatter plot of clusters ( 0,1,2)

Recency – Scatter plot of clusters ( 0,1,2)

Amount/Monetary Value – Scatter plot of clusters ( 0,1,2)

Inference:

Above inference highlights suppliers tagged under Cluster 2 are strategically important as they exhibit frequent high-volume transaction. Hence suppliers tagged under cluster 2 should be taken in follow on process like supplier classification & evaluation.

Important consideration

• Other unsupervised learning algorithms like RF, DT etc. can be also employed, They may produce similar or even better result however I have not tried them in this POC
  
• I had taken invoice data for clustering & have not included Credit or Debit Memo for simplicity. However same can included.
  
• Here customer has guided us on number of clusters considering IT team bandwidth & other business aspects, however 3 or more clusters can be created.
  
• Number of clusters can also be determined based on Elbow curve or silhouette score.
  
• Dataset displayed in screen shots are dummy dataset.
  
• Some of the decisions taken in this proof of concept like deletion of missing values, selection of model etc. varies a lot with dataset, Hence should not be followed as it is.

The post Supplier clustering using Machine learning on Invoice dataset – Proof of concept appeared first on ERP Q&A.

In this article I would like to focus on purchasing side of CCM including two flows configuration, classical rebates based on invoice from Vendor and same approach but with use of accruals and delta settlement.

Configuration

Configuration for condition contract management is split into four main steps:

• Condition type – two configuration steps
  
• Settlement process
  
• Settlement documents

Condition type configuration is more logistics related settings process where settlement process and settlement document configuration is place where FI knowledge is very useful. Basic configuration like condition types and pricing procedure are not described here.

I will not focus here on number of basic and quite well understandable from other areas customizing settings as a number of options to configure is tremendous.

I start with a bit upside down approach means with condition type configuration. Customizing location is Logistics – General -> Settlement Management and then respective subsection.

Condition contract type

Contract type customizing is split into two parts where first one contains more general setting like number range, fields to show/hide or next processing.

From this contract type customizing important is:

• Type of contract partner – V Supplier
  
• Type of Eligible Partner – this setting allows you to further limit selection of business volume
  
• Condition contract category – it’s a grouping of contracts parameter
  
• Purchasing Condition type group is the most important parameter to assign here, as it indicates which condition types can be maintained in a contract.

In my example purchase condition type group ZUR1 has been created where three condition types are going to be used. ZUC1 is a percentage condition, ZUC2 is a fix amount condition and ZUC3 is an accrual condition. Important is that condition types in the group are set as relevant for CC determination.

Second part of condition contract type configuration is more sophisticated and divided into couple of steps combined later on in setting of contract type.

Business volume determination

What I like very much about this new CCM concept is that rebate can takes into account business volume of transactions already settled in the system. In classical ECC rebates processing this was also possible but required filling in some S-table and was always error prone. In CCM, newly created contract receives a database view and when settlement process starts, it calculates quantity, value ad-hoc. View with transaction data and description of main fields are done in profile for business volume determination.

In my case I take into account business volume as a MM invoice posted into system. Additionally, I need to assign basic fields used by condition contract processing like which field correspondents to Vendor or data.

* To see detailed business volume assigned to your contract you can use tcode: WB2R_BUSVOL.

Amount field

In ECC rebates processing base amount field of document used later on for calculation of rebate was determined in pricing procedure of entered document and stored in subtotal 7 – Carry over value to KOMP_BONBA (rebate basis 1). In new CCM concept, field that carry amount value is fully configurable throughout the process. As presented in below screenshot I will take a amount value from WRBTR. Target condition type ZUR3 is used in pricing procedure executed during contract settlement. Field name BUSVOL_1 is used in detailed reporting for business volume.

There is an option to assign as well other amount fields and used them later on in pricing procedure during settlement processes (subconfiguration of additional quantities on left hand side)

Split criteria

This option allows to decide what is the level of data aggregation in settlement document. As presented below out of condition contract only one settlement document is created (as no header level split) with multiple lines – one per item (as material is a split criteria)

Selection fields

As a business volume view can be used by number of contracts where data inside the view is the same and selection fields will allow to restrict the results. Here only the fields for selection are chosen but the values are assigned in instance of contract. Second use case for selection fields is the applicability to select of eligible partner, which is deeper restriction of business volume done by basic selection fields.

After creation of field selection, they must be assigned to group of selection fields.

Condition type group for Accruals

This is optional configuration step which is valid only if you use accruals and later on you need to settle them as delta with condition contract settlement.

In this case ZUC3 condition type carry the value set in instance of condition contract to condition ZUX1 which poses already settled accruals. Value is used later on during a again delta accruals settlement or final settlement in pricing procedure during CC (condition contract) settlement.

Second step of condition contract type – Settlement process

As the first part on condition contract is a bit more “technical” from process perspective the second one is way more business related with emphasis on business data maintenance and settlement.

Number of parameters split per sections is high one and rather on user friendly to set it up. Below description and brief explanation of them.

• Business Volume – assignment of previous set up business volume, group for set of field and optional eligible partners.
  
• Settlement – indicate how each contract type is going to be settled if supplier or customer type.
  
• Supplier Settlement – indicates which settlement process (more details later on) is going to be used in each scenario like regular settlement , partial settlement or delta accruals etc.
  
• Accruals – valid only in case if accruals scenario is in use, here to set which accruals condition group is going to be used and the status indicating validity for settlement process.

Next steps are related to settlement process and consists of creation of settlement process and settlement document type. As mentioned before this section is more finance oriented. Minimum requirement is to have at least one settlement process for which would settle the rebate process. Processed could be different depends on the complexity of process (partial settlement, accruals processing etc.) and time span (partial settlement, delta accruals etc.). I use ZM01 for regular rebate processing and ZM02 for delta of accruals.

Again, the number of options for configuration is overwhelming. Below brief explanations:

• Price determination – controls side of pricing procedure determination.
  
• Pricing procedure determination type – controls based on which parameters determination of pricing procedure is done.
  
• Check allowed settlement doc. Types – checkbox to control if only assigned in configuration table settlement document type to settlement process is allowed.
  
• Post business volume in accounting – controls based on what data accounting documents postings are created. Either pricing procedure posting is run (multiple lines possible) or simple two lines accounting posting Vendor/Customer with offset posted according to account key for clearing set in settlement document type.
  
• Settlement partner category – indicates if settlement process can be used for both sides (Vendor, Customer)
  
• Couple of settings regarding tax determination and if no value for tax means error.
  
• Settlement document type – define which settlement document type is used to settle this process

Finally, the last step of configuration (as this article is really limited to milestones of configuration without describing details like setting transfer procedure etc) which is settlement document type.

Again, this is one most complex step with the highest number of configuration possibilities so I will describe only the most important (below screenshot presents only couple of sections).

• Settlement document category – describe mainly way of processing of document (Invoice/Credit memo) in FI.
  
• Pricing section contains parameters to describe what kind of pricing procedure is used (in my case M – Purchasing) and Document schema group is one of parameters used in pricing procedure determination in settlement process
  
• Account key for clearing line – as mentioned before indicated account key for posting business volume if pricing procedure is not used.

Each settlement document type executes pricing procedure (if posting is to be settled) and below presented two different pricing procedures one for regular rebates (ZUK002) and second one of delta accruals (ZUK003). As ZUR3 is the condition that has value coming from business volume update, ZUC1/ZUC2 are conditions set in condition contract. In the accruals processing ZUX1 condition has value of already processed accruals in delta settlement then ZAC3 condition is a copy of ZUC3 condition but without accruals checkbox set in a condition type and use as a reference condition ZUC3.

If you reached this paragraph means you are really persistent. My personal opinion about the subject is that CCM is very flexible and powerful tool but to complex to configure it comparing to previous version of rebates processing. Looking forward to hear more from other logistics or finance consultants. At the end short summary of a number of setting that you have to pass through:

• Condition contract type -> Around 60 drop lists or input fields – 22 checkboxes
  
• Settlement process type -> Around 45 drop lists or input fields – 10 checkboxes
  
• Settlement document type -> Around 114 drop lists or input fields – 29 checkboxes

The post S/4 Condition Contract Management – Purchasing appeared first on ERP Q&A.