As the user sets the Validation rule, it checks the validation rule defined on specific fields data. When user is trying to post the transaction and enters data in that specific field, which violates the validation rule, system throws an error message for the user and it will not allow the transaction to post.

It will succeed to post the transaction only when the data is posted in that specific field as defined in the validation rule. It helps to avoid wrong entry at initial stage of posting the transaction.

Whereas Substitution rule is set up to substitute the data immediately upon the entry made. As the user enters the value, system validates according to the prerequisite defined by the user. If the prerequisite rule is met, the system replaces the value entered with other values.

With SAP S/4HANA Cloud 2005, The Manage Substitution/Validation Rules app for JVA is enhanced with the new comparison operator Matches and the new substitution type Table Lookup.

The Matches operator can be used to match a string-type field value against a regular expression.

The Table Lookup substitution type allows user to choose a source field from a custom business object and uses its value to fill in the target field.

Let’s see how it looks and how to configure in the Cloud System with 2005 upgrade:

Apps involved:

• Manage Substitution/Validation Rules
  
• Post General Journal Entries

Business Roles:

Unrestricted read/write for:

• Configuration Expert – Business Process Configuration: BR_BPC_EXPERT
  
• General Ledger Accountant: BR_GL_ACCOUNTANT

Example:

1. Define Validation Rule

Login with the role Configuration Expert – BPC_EXPERT

Go to “Manage Substitution/Validation Rules”

Click on “Create Rule”.

Enter the following:

Context: Coding Block

Event: Coding Block

Rule Type: Validation Rule

Click on “Create”

Under General Information enter the following:

Under Precondition, enter the following:

Under Validation, enter the following:

Click on “Save”.

Click on “Activate”.

2. Post Journal Entry

Login with the role General Leder Accountant: GL_ACCOUNTANT

Enter the following Header details.

Line Item 1: Enter the following details

Line Item 2: Enter the following details

Click on “Post”.

You should receive the below error message.

Click on OK and go to Line Item 1.

Change the Cost Center to CC_CON

Click on “Post”

3. Create Substitution Rule

Login with the role Configuration Expert – BPC_EXPERT

Go to “Manage Substitution/Validation Rules”

Click on “Create Rule”

Enter the following

Context: Coding Block

Event: Coding Block

Rule Type: Substitution Rule

Click on “Create”

Under General Information, enter the following:

Under Precondition, Enter the following:

Under Substitution, Enter the following:

Substitute Type: Substitute with Constant

Click on Save.

Click on Activate.

4. Post Journal Entry

Login with the role General Ledger Accountant: GL_ACCOUNTANT

Enter the following Header details.

Line Item 1: Enter the following details

Line Item 2: Enter the following details

Click on Post.

Click on Display.

Click on Settings

Select Functional area and click on OK.

Functional Area is YB20 which proves Substitution Rule has been triggered correctly.

With this the user can successfully create and validate the rules as per business requirements.

The post SAP S/4HANA Cloud Validation and Substitution rules appeared first on ERP Q&A.

In today’s data-driven world, having real-time insights at your fingertips is crucial for making informed business decisions. SAP Data Sphere is a cloud-based solution designed to integrate, model, and analyze data from various sources. In this blog, I’ll show you how to set up a trial account for SAP Data Sphere and create a dashboard using SAP’s sample sales order data. The dashboard will include visualizations like charts and tables, along with predictive analysis. Let’s get started!

Step 1: Getting a Trial Account for SAP Data Sphere

Before we begin, you’ll need access to SAP Data Sphere. Here’s how to sign up for a free trial:

1. Visit the SAP Data Sphere Trial Page:

• Go to SAP Data Sphere Trial.
  
• Note: You will need an SAP account, which you can create for free if you don’t have one.

2. Sign Up for the Trial:

• Click on the “Start your free trial” button. You’ll be prompted to log in or create an account. Once logged in, you can follow the instructions to activate your trial.

3. Activate the Trial:

After creating your account, confirm your email address and follow the instructions to activate your trial account. Once your trial is active, you’ll be able to access the SAP Data Sphere interface.

4. Access Your SAP Data Sphere Workspace:

Once the trial is set up, navigate to the SAP Data Sphere dashboard. This is where you’ll create your data models, visualizations, and analytics.

Step 2: Importing Sample Sales Order Data

SAP provides sample datasets to help you get started. Follow these steps to import the Sales Order sample data:

1. Navigate to Data Builder:

On the SAP Data Sphere main dashboard, look for the “Data Builder” tab on the left-hand menu and click on it. The Data Builder allows you to import, transform, and model your data.

2. Import Sample Sales Order Data:

In the Data Builder, click on the “Import” button at the top-right corner. This will open a menu of options. From the available sample datasets, select the “Sales Order Sample” dataset.

3. Review and Confirm Import:

Once selected, you will see a preview of the data. Confirm that this is the dataset you want to import by clicking “Next,” and then complete the process by clicking “Import”. The Sales Order data will now appear in your workspace under the “Data Sources” section.

Step 3: Building the Data Model

Before creating visualizations, we need to create a data model that organizes the sales order data into useful fields. Follow these steps:

1. Create a New Space:

In SAP Data Sphere, data is organized into spaces. Go back to the main dashboard and click on “Spaces”. Here, create a new space by clicking “Create Space” and give it a relevant name like “Sales Order Analysis”.

2. Assign Your Data Source to the Space:

In the newly created space, go to the “Data Builder” tab. You’ll see the Sales Order data that you imported. Drag and drop this dataset into your space.

3. Modeling the Data:

Now, click on “New Graphical View” in the Data Builder. Select the Sales Order dataset as your input and choose the fields you want to work with, such as:

• Sales Order ID (SALESORDERID) – The unique identifier for each sales order.
  
• Partner ID (PARTNERID) – The customer or partner associated with the sales order.
  
• Gross Amount (GROSSAMOUNT) – The total amount of the sales order, including taxes.
  
• Net Amount (NETAMOUNT) – The amount after applying discounts and excluding taxes.
  
• Tax Amount (TAXAMOUNT) – The total tax applied to the order.
  
• Delivery Status (DELIVERYSTATUS) – The current status of the delivery process.
  
• Billing Status (BILLINGSTATUS) – The status of the billing process for the sales order.

These fields will help you create visualizations that show sales trends, financial summaries, customer distribution, and order status information.

Step 4: Creating Visualizations

With the data model in place, it’s time to create visualizations. Here’s how you can create charts, graphs, and tables:

1. Go to SAP Analytics Cloud:

To start building visualizations, navigate to the “Story Builder” tab in the left-hand menu. This is where you’ll create interactive charts and tables.

Create a Bar Chart for Sales by Partner ID:

1. Click on “Create New Story” and choose a bar chart as the visualization type.
   
2. In the data source section, select the data model you created.
   
3. Set the X-axis to “Partner ID (PARTNERID)” – this will represent different customers or partners.
   
4. Set the Y-axis to “Gross Amount (GROSSAMOUNT)” – this will show the total sales for each partner.
   
5. Customize the chart by adding labels, titles, and colors to make it more informative. For example, label the chart as “Sales by Partner” and add a currency format for the Y-axis.

Create a Line Graph to Show Sales Trends Over Time:

1. Add another visualization by selecting “Add Chart” and choosing a line graph.
   
2. Set the X-axis to “Created Date (CREATEDAT)” – this will plot the sales over time.
   
3. Set the Y-axis to “Net Amount (NETAMOUNT)” – this will display the net sales amount over time.
   
4. Group the data by months or quarters to visualize trends over time, allowing users to identify sales patterns, seasonal fluctuations, or growth over specific periods.

Create a Pie Chart for Market Share by Sales Organization:

1. Add a new chart and select “Pie Chart” as the visualization type.
   
2. Set the category to “Sales Organization (SALESORG)” – this will divide the sales data by different sales organizations.
   
3. Set the value to “Gross Amount (GROSSAMOUNT)” – the pie chart will reflect the sales contribution of each organization.
   
4. This chart will give you a clear view of the sales distribution across different sales organizations.

Create a Table for Detailed Sales Data:

1. Add a table to display more detailed information about individual sales orders.
   
2. In the table, select fields such as:
   
   • Sales Order ID (SALESORDERID) – to uniquely identify each order.
     
   • Partner ID (PARTNERID) – to show which customer made the order.
     
   • Gross Amount (GROSSAMOUNT) – to display the total value of each order.
     
   • Created Date (CREATEDAT) – to display when the order was created.
     
   • Billing Status (BILLINGSTATUS) – to track the billing progress of the order.
     
   • Delivery Status (DELIVERYSTATUS) – to track the status of deliveries.
     
3. Add sorting and filtering options for users to search for specific orders or filter data by criteria like date range, billing status, or delivery status.

4. Now our complete story looking like below:

Step 5: Adding Filters for User Interactivity

To make the dashboard more interactive, SAP Data Sphere allows you to add filters that help users explore the data in more detail. Here’s how we can add relevant filters based on your data:

Add a Date Range Filter:

1. In Story Builder, click the “Filter” icon at the top of the page.
   
2. Choose “Date Range” as the filter type.
   
3. Connect the filter to the “Created Date (CREATEDAT)” field. This will allow users to select a custom date range and view sales orders created within that timeframe.
   
4. This filter will help users analyze trends over specific periods, such as viewing sales in a particular quarter or year.

Add a Sales Organization Filter:

1. Next, add a filter for Sales Organization so users can focus on sales from specific regions or sales divisions.
   
2. Link this filter to the “Sales Organization (SALESORG)” field.
   
3. By applying this filter, users can narrow down the data to only view sales from certain sales organizations, helping them understand performance at a regional level.

Add a Partner ID (Customer) Filter:

1. Lastly, add a filter for Partner ID. This filter will allow users to isolate sales data for specific customers or partners.
   
2. Connect this filter to the “Partner ID (PARTNERID)” field from your dataset.
   
3. This filter will be useful for users who want to focus on the sales performance of specific customers, making it easier to drill down into customer-specific data and insights.

How Filters Enhance the User Experience:

By adding these filters, we give users the flexibility to explore the data in ways that matter to them. They can:

• Focus on sales from specific time periods (e.g., the last quarter or fiscal year).
  
• Analyze sales performance by region or sales organization.
  
• Drill down into data by specific customers (Partner ID), which is useful for customer analysis and segment-specific performance.

Step 6: Implementing Predictive Analytics

SAP Data Sphere allows us to use historical data to predict future trends and identify anomalies. Let’s implement predictive analytics to forecast future sales and detect unusual patterns in your sales data.

Go to Predictive Scenario:

1. Navigate to the “Predictive Scenario” section from the left-hand menu in SAP Data Sphere.
   
2. This is where you can create forecasting models using historical sales data to generate predictive insights.

Create a Sales Forecast:

1. Select “Time Series Forecast” as the type of predictive model.
   
2. Choose “Net Amount (NETAMOUNT)” as the target variable for the forecast. This will allow us to predict future net sales based on past trends.
   
3. Use “Created Date (CREATEDAT)” as the time field to predict future sales trends over time.
   
4. After configuring the model (e.g., defining time intervals such as monthly or quarterly forecasts), SAP Data Sphere will generate a sales forecast based on our historical data.
   
5. We can then display this forecast as a line graph in our dashboard to visualize future sales projections.

Anomaly Detection:

1. In addition to forecasting, you can enable Anomaly Detection in the Predictive Scenario section.
   
2. Choose “Net Amount (NETAMOUNT)” or “Gross Amount (GROSSAMOUNT)” as the target variable, depending on the type of anomalies we want to detect (e.g., unusually high or low sales amounts).
   
3. SAP Data Sphere will analyze your historical sales data and automatically flag any anomalies, such as:
   
   • Sudden drops in sales.
     
   • Unusual spikes in demand for specific customers or regions.
     
4. We can visualize these anomalies directly on your dashboard, helping your team investigate potential issues or capitalize on unusual growth patterns.

How Predictive Analytics Adds Value:

By using SAP Data Sphere’s predictive analytics capabilities, we can:

• Plan more effectively by forecasting future sales and identifying seasonal patterns.
  
• Detect and respond to anomalies in our sales performance, allowing you to address issues like unexpected sales drops or inventory problems.
  
• Visualize predictions easily in the dashboard, enabling your stakeholders to make data-driven decisions based on future trends.

Step 7: Sharing and Publishing the Dashboard

Once our dashboard is ready, we can share it with others or publish it for your team to access.

1. Publish the Dashboard:

• In the Story Builder, click on the “Publish” button at the top-right corner.
  
• Choose the audience you want to share it with, such as specific colleagues or departments, and set appropriate permission levels to ensure data security.

2. Sharing Links or Embedding the Dashboard:

• SAP Data Sphere also allows us to share the dashboard via a link or embed it on your company’s internal portal.
  
• To share via link, simply click “Get Shareable Link” and send it to your team.

Conclusion:

Congratulations! We’ve successfully created an interactive analytical dashboard in SAP Data Sphere using the sample sales order data. With visualizations, filters, and predictive analytics, you’ve transformed raw data into actionable insights. SAP Data Sphere’s flexibility and powerful tools make it easy to create meaningful dashboards for any business use case.

The post Step-by-Step Guide: Building an Analytical Dashboard in SAP Data Sphere Using Sales Order Data appeared first on ERP Q&A.

This short overview of abstract entities concept in the context of non-standard RAP business object operations. It outlines their purpose, advantages, and implementation strategies, emphasizing their role in enhancing modularity and flexibility in data modeling.

Purpose

Abstract entities are Core Data Services (CDS) constructs specifically designed to model complex input parameters for non-standard RAP BO operations(actions and functions).

Database Independence

One of the key features of abstract entities is their independence from database persistence. They are particularly suited for parameter modeling and give possibility to redefine parameters on next modelling level.

Reusability

Abstract entities promote reusability across multiple operations. This characteristic enables developers to adopt a more modular approach, allowing the same abstract entity to be utilized in different contexts without the need for redundant definitions.

Parameter Flexibility

These entities support complex structures, including multi-level nested components. This flexibility allows for more sophisticated data representations and enhances the capability to handle intricate business logic.

Binding

Unlike traditional entities, abstract entities are not bound to specific BO nodes. They provides greater adaptability in how they are integrated into various operations.

Improved Separation of Concerns

By decoupling input parameter modeling from the actual business logic, abstract entities facilitate a clearer separation of concerns. This simplification in design leads to more maintainable and understandable code, as the focus can be placed on each aspect of the application independently.

In conclusion, abstract entities serve as a powerful tool for modeling complex input parameters in non-standard RAP BO operations.

2. Implementation details.

I want to highlight how to effectively use abstract entities in ABAP development. One of their key applications is for typing, particularly for action parameters in RAP actions. Let’s begin with a straightforward example.

We make a simple abstract entity with four fields.

@EndUserText.label: 'ABSTRACT ENTITY'
define root abstract entity ZPRU_ABS_ENTITY
{
    ABSTRACTENTITYNAME : char40;
    SURNAME : char40;
    AGE : int4;
    EMAIL : char40;
    
    CHILD : composition [ * ] of ZPRU_ABS_CHILD;
    CHILD_2: composition [ * ] of ZPRU_ABS_CHILD_2;
}

Next, I created a RAP business object with a root entity view (the specifics of which aren’t important for this example) and defined the ‘sendEntity’ action with an input parameter of type ZPRU_ABS_ENTITY.

Let’s have a look at action definition:

managed implementation in class zbp_pru_root_entity unique;
strict ( 2 );

define behavior for ZPRU_ROOT_ENTITY alias ROOT
persistent table zpru_dn
lock master
authorization master ( instance )
{
  create;
  update;
  delete;
  field ( readonly ) dn_no, freq, prod;

  //Flat
  action sendEntity parameter ZPRU_ABS_ENTITY;
  // Deep
  action sendEntity2 deep parameter ZPRU_ABS_ENTITY;
  // Deep Table
  action sendEntity3 deep table parameter ZPRU_ABS_ENTITY;

}

Right now, let’s check RAP business object implementation class.

CLASS lhc_root DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.

    METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION
      IMPORTING keys REQUEST requested_authorizations FOR root RESULT result.

    METHODS sendentity2 FOR MODIFY
      IMPORTING keys FOR ACTION root~sendentity2.

    METHODS sendentity FOR MODIFY
      IMPORTING keys FOR ACTION root~sendentity.

    METHODS sendentity3 FOR MODIFY
      IMPORTING keys FOR ACTION root~sendentity3.

ENDCLASS.

CLASS lhc_root IMPLEMENTATION.

  METHOD get_instance_authorizations.
  ENDMETHOD.

  METHOD sendentity2.
    DATA(lv_deep_field_from_abs_entity) = keys[ 1 ]-%param-child[ 1 ]-abstractchildname.
  ENDMETHOD.

  METHOD sendentity.
    DATA(lv_field_from_abs_entity) = keys[ 1 ]-%param-abstractentityname.
  ENDMETHOD.

  METHOD sendentity3.
    DATA(lv_deep_table_field) = keys[ 1 ]-%param[ 1 ]-child[ 1 ]-abstractchildname.
  ENDMETHOD.

ENDCLASS.

Derived type:

As a result, you’ll see the KEYS table, where each row contains a %PARAM component. This component is typed as the structure ZPRU_ABS_ENTITY.

The next step is to demonstrate the use of the ‘deep parameter AbstractBDEF’ and the ‘deep table parameter AbstractBDEF’ in defining a BDEF action parameter.

To do this, we need to extend the abstract entity by adding a BDEF of type Abstract with a hierarchy.

First, I added the ‘root’ keyword to the abstract entity:

One important note: when adding a BDEF to an abstract entity, we initiate the creation of an abstract business object. As a result, we need to construct this business object in a way that’s quite similar to how we build standard RAP business objects. This is why we use keywords like ‘root’, ‘composition’, and ‘association to parent.’

I also created a new abstract entity, ZPRU_ABS_CHILD. Then, I added mutual associations between ZPRU_ABS_ENTITY as the root and ZPRU_ABS_CHILD as the child.

Then, I’ve created BDEF with ZPRU_ABS_ENITY as root entity and Abstract implementation type:

Let’s overview new abstract BDEF:

abstract;
strict ( 2 );
with hierarchy;

define behavior for ZPRU_ABS_ENTITY alias ABS
{
  association CHILD;
  association CHILD_2;
}

define behavior for ZPRU_ABS_CHILD alias CHILD
{

  association ROOT;

}

define behavior for zpru_abs_child_2 {

association third_level;

}

There are 3 main points:

1. add keyword ‘with hierarchy’ to make BDEF opt to deep expanding.
   
2. recreate RAP BO composition tree, add root entity and child entity.
   
3. explicitly mark association to ZPRU_ABS_CHILD.

Finally, I’ve added addition keyword ‘deep’ to action definition to expand action parameter type.

Let’s have a look into typing:

%PARAM typing:

You can notice that to component %PARAM a new nested table with the name CHILD has been added. It’s an effect of keyword ‘deep’ in action parameter definition. Component CHILD has type of table due to cardinality [ * ] in definition of composition in abstract root entity ZPRU_ABS_ENTITY.

Last topic is about addition ‘deep table’ to action parameter definition.

Let’s add it:

Hence, let’s check what has been changed in typing:

As you can see component %PARAM became table, before it was a structure. This is the effect of keyword ‘table’ in action parameter definition.

Lastly, the same principles apply to typing action output parameters. However, one key difference is that we can’t use the ‘deep’ addition when defining output parameters. As a result, the %PARAM component will be incorporated into the output’s derived type as a structure.

A table with summarizing:

The post CDS Abstract Entity and ABAP RESTful Application Programming Model: Input parameter modelling appeared first on ERP Q&A.

The Data Migration Cockpit is an SAP Fiori-based application designed to simplify and manage the migration of both master data and transactional data into SAP S/4HANA Public Cloud during system implementation.

It provides a structured, user-friendly interface with the following key capabilities:

• Predefined Migration Objects – such as Profit center, cost center, Customer, Vendor, G/L Accounts, Asset Master, etc.
• SAP-Provided Excel Templates – for easy data input and mapping
• Built-in Validation & Error Checking – helps identify and correct data issues before posting
• Step-by-Step Guided Process – ensures consistent and accurate data migration

With the Data Migration Cockpit, businesses can reduce complexity, minimize errors, and ensure a smooth go-live by efficiently uploading clean legacy data into the SAP cloud system.

Steps to Perform Data Migration in SAP S/4HANA Public Cloud

Step 1: Access the Data Migration App

• Go to the Fiori Launchpad.
• Open the app: “Migrate Your Data – Migration Cockpit“.

Step 2: Create a New Migration Project

Click “Create”

Enter a name for your project eg.. profit center Migration

When you create a migration project, it is saved but not yet started. Once you begin working on it, the status changes to “In Progress.” After completing the migration steps, you mark the project as “Finished” and select how long the system should retain the project data. Once that time period ends, the project is automatically removed from the list. However, the data you uploaded will remain in the system and can still be used.

Important Details Before Starting Your Migration Project

After you create the migration project, there are some key points to understand before you begin:

• Stage-wise Data Validation: The system performs validations at different stages. You can see how many tables are involved in the migration object and how many data records (instances) will be created in the system.
• Mapping Tasks Table: During the mapping process, you can view detailed information about your data, including any errors or successful mappings. You will also see similar reports during the simulation and actual migration steps.

1. Download the Template
Get the Excel template provided by SAP for the migration object you want to upload.

2. Prepare the Data
Fill the template carefully with your legacy data, following the format exactly.

3. Upload the Prepared Template
Upload your completed Excel file into the Data Migration Cockpit.

4. Mapping Tasks
Review and adjust how your data fields map to SAP system fields if needed.

5. Simulation
Run a test migration to check for errors without actually posting data.

6. Migration
Execute the real data upload into SAP once the simulation is successful.

7. Correction File
If errors appear, download the correction file, fix the data, and repeat the upload process.

These are the steps in the migration process. After you finish one step, the system will take you to the next step automatically. You just need to follow and complete each step.

Download Template and Upload Data

Get the template as an XML file, enter the necessary data, and submit the filled template by uploading it back.

Mapping Task

The Mapping Task helps you connect the data from your uploaded file to the correct values in SAP S/4HANA.

For example:

• You may need to match company codes, currencies, or country codes from your old system to the values used in SAP.

During this step:

• The system shows you any missing or incorrect values.

• You can manually adjust or confirm the correct mappings.

• Once everything is mapped correctly, you can continue to the next step.

Simulation

The Simulation step lets you test the data migration without actually posting the data into the SAP system.

What happens during simulation:

• The system checks if the data is correct and complete.

• It shows any errors or warnings in the data.

• You can review the results and fix any problems before doing the actual migration.

This step helps you avoid mistakes during the real migration.

Migration

After a successful simulation, you can start the Migration step.

In this step:

• The system uploads the data from the staging tables into SAP S/4HANA.

• All valid records are posted to the system.

• You can see a summary of successful and failed records.

If there are any errors, you can fix them and repeat the migration for those records.

This is the final step where your data becomes active in SAP.

Migration Result

After the migration is complete, you can view the Migration Results to check the status of your data upload.

In this section, you will see:

• Successful Records – These records were uploaded and posted correctly into SAP.

• Failed Records – These records had errors and were not posted.

For failed records:

• The system shows error messages to help you understand what went wrong.

• You can download a Correction File, fix the issues, and re-upload the corrected data.

Reviewing the migration result helps ensure that all your data has been properly transferred into SAP S/4HANA.

The uploaded template file must be less than 100 MB in size. If your data is too large, consider splitting it into multiple files.

The post Step-by-Step Guide to Data Migration Cockpit in SAP S/4HANA Public Cloud appeared first on ERP Q&A.

Milestone billing means distributing the total amount to be billed over multiple billing dates in the billing plan. This approach is particularly beneficial for industries such as engineering, construction & professional services where projects are linked to project completion phases.

Business Example:

Engineering firm such as Windmill Manufacturing company uses milestone billing as follow,

1. Contract Phase – 30%
   
2. Design Phase – 40%
   
3. Assembly Phase – 20%
   
4. Final Invoice Delivery Phase -10 %

At each milestone Billing date Invoice triggers to the Client.

Below are the Configuration steps for Milestone Billing in SAP S/4HANA:

1. We need to Define Billing Plan Type in SPRO/ Transaction Code: OVBO.
2. Define Date Description in SPRO/ Transaction code: OVB0: As per Business requirement create Date description such as- Contract phase, Design phase, Assembly phase, Final Invoice phase.
3. Define and Assign Date Categories: Billing rule- (Depends on Business requirement of percentage Basis or Value base etc.)
4. Assign Date category for Billing Plan.
5. Maintain Date proposals for billing plan type: Maintaining the Billing Date, Billing Rule, Date Description and Billing Type Information will be repeated automatically in upcoming milestone orders created in the system (As per client requirement).

6. Assign Billing plan Types to Sales Document Types in SPRO/ Transaction Code: VOFA.
7. Assign Billing Plan type to Item Categories.
8. In some Business Cases Milestone comes from PS Module:

• Create Milestone Billing in Project Systems (PS) Module Use Transaction Code: CJ20N (Project Builder)
  
• Define milestone under project activities and specify milestone dates.
  
• Link each milestone to a billing plan date.
  
• Once the Milestone is confirmed by the Project system team, the billing block is removed and billing can be done accordingly.

9. Create Sales order: Go to Billing plan tab in Item level & adjust the billing dates and amounts according to milestone and project progress.
10. Now system is ready to create Invoices based on Milestone.

Note: To Add or Remove Billing Plan Tab in Sales order – Header level Screen > Go to Transaction code VOV8 Select sales document type in Billing Tab > Billing Plan type maintain as Business requirements.

Advantages of Milestone billing to clients:

Milestone billing gives clients the option to change project focuses while reducing the financial risk by connecting payments to finished milestones. It helps businesses keep high quality, Standard and builds a trust in client. Linking payments to the project phase clears the result encourages trust and openness, Clients can monitor the progress and make sure payments match the billing value delivered. This approach also improves project management by setting clear targets and timelines, which helps stay on schedule and budget while matching cash flow Alignment with project advancement.

Upgrade in S/4HANA compared to ECC:

1. User Interface: Fiori application provides modern & easy to use interface, easy to track and manage.
2. Milestone Achievement rates are progressed due to embedded analytical dashboards and by allowing real- time Tracking.
3. Integration with SAP Project Systems (PS) updates billing milestones by project status, making it more accurate and cutting down on manual tasks.
4. The integration of real-time connectivity with the Universal Journal facilitates instantaneous modifications to milestone billing financial documentation, thereby obviating the necessity for routine verifications.
5. The system provides quicker processing of big billing data and allows for real-time checks for billing results.

Conclusion: Milestone billing is a useful way to send invoices that brings several advantages to companies. These advantages include better cash flow control, improved project handling, and stronger relationships with clients. By linking payments to certain project milestones, companies can maintain financial steadiness, lower financial risk, and encourage quality work. Using milestone billing helps companies succeed and gain both profit and customer satisfaction.

The post Milestone Billing in SAP S/4HANA appeared first on ERP Q&A.

In this blog series, I will give you the overview to ISLM tool and brief guide on how to get the maximum value out of the pre-built scenarios provided by SAP.

This blog is built as a series of several parts and I’ll be updating the links to other parts once they’re published.

Intelligent Scenario Lifecycle Management (ISLM) is a framework facilitating lifecycle management tasks for machine learning scenarios. It serves as a self-service tool, empowering users to address diverse operational needs inherent in machine learning scenarios efficiently. With ISLM, you can train intelligent scenarios and utilize the resulting trained models to obtain precise inference results.

In the above diagram, we have three boxes at the bottom. The first one being the business application, this is where the business user would consume any kind of intelligence. Then at the extreme right, we have the ML runtimes or AI Services which could be either embedded within the same stack in case of HANA ML or it could be, for example SAP BTP. Then right at the center at the core of it, we have ISLM, which i Bridges the gap between the SAP business application and AI services. ISLM is a key enabler for our customers, our partners and our internal teams to create these AI use cases, and not just create but also to operate the entire life cycle of it.

The categorization of scenarios within a business application depends on the specific machine learning scenario involved:

• Embedded: In this methodology, a business application such as SAP S/4HANA operates within the same stack as its machine learning counterpart, SAP HANA Machine Learning, utilizing either the SAP HANA Automated Predictive Library (APL) or the SAP HANA Predictive Analysis Library (PAL) for analytics tasks. APL provides business analysts with data mining capabilities through an Automated Analytics engine, facilitating the development of predictive modelling processes. On the other hand, PAL offers advanced analytics algorithms tailored for data scientists. These tools can be effectively applied to address various use cases such as forecasting, trend analysis, and more
  
• Side by Side: In this setup, a business application like SAP S/4HANA operates on a distinct stack from its machine learning provider, such as SAP Data Intelligence. Remote machine learning is employed for advanced use cases, such as image recognition, sentiment analysis, and deep learning for natural language processing, leveraging neural networks

ISLM framework consists of two SAP Fiori applications:

Intelligent Scenarios and Intelligent Scenario Management. These applications allow you to create and manage the lifecycle of intelligent scenarios.

ISLM comprises of the following functionalities:

• Display: You can view the details of the intelligent scenarios that are displayed, such as package, scenario type, inputs and outputs, API details, and so on.
  
• Create: You can create an intelligent scenario of the type Side-by-Side and Embedded for your specific business need.
  
• Train: You can train the scenario to generate a trained machine learning model or artifact for the business consumption.
  
• Deployment: You can deploy the trained machine learning models for inference consumption. This functionality applies to Side-by-Side scenarios only.
  
• Activation: You can activate the trained machine learning model for which you want to get the inference results.
  
• Inference Results – You can get the predictions that is generated from the trained models.

Here are some of the advantages offered by ISLM:

• Serves as a unified entry point for Citizen Data Scientists to conduct machine learning lifecycle management operations on both embedded and remote machine learning models.
• Offers support for both On-Premise and SAP Cloud solutions in conjunction with the SAP solution it integrates with, such as SAP S/4HANA.
• Delivers comparable functionality to the previous SAP solution, SAP Predictive Analytics Integrator (PAi).
• Establishes a standardized approach for managing training, deployment, and activation across all intelligent scenarios.
• Supports both Embedded and Side-by-Side scenario configurations.
• Provides the flexibility to create custom intelligent scenarios and oversee the model training, deployment, and activation directly within ISLM.
• Coordinates machine learning operations in the embedded approach utilizing SAP HANA predictive libraries like APL and PAL, as well as in the Side-by-Side approach with remote providers such as SAP Data Intelligence.

Intelligent Scenarios App

• Here you can check the standard pre-built scenarios provided by SAP. Custom scenarios can also be created from this app.

• You need to add a Machine Learning Model here

• In the next screen you need to populate the Technical fields – Training Dataset, Apply Dataset, Target

• Once done, you have to review the model and publish it. The technical details can be found here:

https://help.sap.com/docs/ABAP_PLATFORM_NEW/7989a582039547ae91d8f483e487058d/ca55e11ef9544d1e846773cb8626e746.html?version=202009.001

Intelligent Scenario Management App

• All the standard Intelligent scenarios provided by SAP can be seen here. You can select any scenario to use it to train the model

• One or multiple filters are available for your selection. Once filters are selected, you need to train the model

• After the model is trained, you need to activate it. Now the Intelligent scenario is active and ready for use

Conclusion

This blog post should help you to understand in detail about the ISLM tool and it’s offerings. Also, you will get brief idea on SAP’s strategy in regards to Intelligent solutions to business processes.

The post A Comprehensive Overview of Intelligent Scenario Lifecycle Management (ISLM) appeared first on ERP Q&A.

Backorder Processing (BOP) involves the bulk handling of orders in batch mode, wherein adjustments to order confirmations are made to align with business priorities and respond to shifts in the demand/supply dynamics within your order fulfillment process.

In the context of aATP BOP, a novel notion of requirement classification is introduced, enabling the confirmation of orders based on predefined criteria. This system comprises five classifications (win, gain, redistribute, fill, and lose), each equipped with a distinct rule governing the prioritization of order confirmations. For instance, the winner and the gainer hold the utmost priorities and retain their confirmed quantities without any reduction, while the loser consistently forfeits all confirmed quantities to any other classification.

Let’s go through the each BOP segment to get a thorough understanding.

Different BOP segments and behavior

Example Scenario:

Assumption: The “Scope of check” only considers the on hand stock. Not future stocks.

Organization ABC is receiving some purchase order from different customers and they raise sales orders in the below sequence.

Sales Order creation sequence in the model scenario

In accordance with the aforementioned illustration, organization ABC is generating multiple sales orders for its clientele. The first order pertains to a customer with a delivery priority of 3, who is not classified as one of the premier clients of organization ABC.

The second order is attributed to a customer of neutral standing, characterized as a regular and recurrent purchaser. At the point of initiating the sales order, the available on-hand stock is documented at 4000 pieces, considering that 8000 pieces have already been confirmed for the preceding order out of the total inventory of 12000 pieces. Additionally, the complete requisition cannot be confirmed due to the specified quantity for order 2 amounting to 6000 pieces.

Concluding the sequence, the third sales order is allocated to a premium customer. Upon commencement of the sales order, the on-hand stock will be depleted to zero. This is where the back-order processing functionality within aATP comes into play. Subsequently, an examination of how BOP navigates and manages the aforementioned situation shall be conducted.

BOP variant simulation result for the model scenario.

As depicted above, the BOP (Back Order Processing) variant initiates the process by revoking the entire confirmation attributed to customer 01. This action is prompted by the customer’s adherence to the LOSE strategy, allowing the unconfirmed quantity to become available for utilization by the WIN, GAIN, and REDISTRIBUTE strategies. In this specific business scenario, customer 03 aligns with the WIN strategy. Consequently, the unconfirmed quantity originally associated with customer 01 is reallocated to customer 03.

Nevertheless, achieving full confirmation for customer 03 remains unattainable, given their requirement of 9000 pieces. The deficit of 1000 pieces can be offset by sourcing from customer 02, characterized by a delivery priority of 02 and an inclination towards the REDISTRIBUTE strategy.

The critical aspect lies in discerning the disparity between LOSE and REDISTRIBUTE strategies within this context. Following the complete un-confirmation of the prior commitment to customer 01, a shortfall of 1000 pieces persists for the fulfillment of customer 03’s requirement. This shortfall is addressed through a partial confirmation extended to customer 02.

This elucidates how BOP adeptly manages and automates the resolution of issues arising from incongruities between requirements and demands, a process that traditionally necessitated human intervention.

In order to simplify the understanding process, i have simulated the same business scenario in my system environment and below is the BOP variant simulation result that could observe.

WIN

REDISTRIBUTE

LOSE

In SAP S/4HANA, the Enhanced Available-to-Promise (aATP) feature provides a range of SAP Fiori applications designed for the automated handling of backorders and the manual authorization of orders for delivery. These applications cater to various business document types, including sales orders and stock transport orders.

Each of the subsequent applications enables you to set up a particular step before initiating backorder processing or to oversee the outcomes of a concluded backorder processing operation:

Configure BOP Segment

This application allows you to establish a set of criteria for selecting priorities in distributing supplies when the demand for materials in sales and stock transport orders surpasses the existing inventory or capacity. Through the utilization of selection and exclusion conditions, along with prioritizes, you can automate the rescheduling and redistribution processes in alignment with your company’s strategy. Following this, the Configure BOP Variant application can be employed to create a variant, facilitating the direct execution of the corresponding backorder processing run within the app or through the Schedule BOP Run application. Access to this app is contingent upon the assignment of the Order Fulfillment Manager (R0226) business role to your user account.

Configure Bop Variant

Utilizing this application, you have the capability to establish a variant for backorder processing (BOP), incorporating optional filters and prioritizers. This allows for the automated rescheduling and redistribution of materials in restricted supply. The outcomes of successive backorder processing runs can be viewed in the Monitor BOP Run application.

Configure Custom BOP Sorting

Using this application, you have the capability to generate sequences for prioritizing requirements originating from sales and stock transport documents based on attributes that are not amenable to straightforward alphanumeric sorting, such as customer or sold-to party. In this process, you establish a logical framework for prioritizing requirements, which is subsequently applied in the Configure BOP Segment application and in subsequent backorder processing runs initiated from either the Configure BOP Variant or Schedule BOP Run applications.

Schedule BOP Run & Monitor BOP Run

Using these applications, you can set up and timetable tasks to execute backorder processing (BOP) runs. This involves specifying the technical parameters governing the selection criteria, operational characteristics of the run, and, if necessary, simulative and recurring runs, as well as subsequent update processes and logging. The outcomes of any scheduled run through this app can be monitored in the Monitor BOP Run application.

This concludes this article and the main object of writing this to give you all a high level understanding of Backorder Processing in aATP, SAP S4 HANA. Please do share all your insights.

The post Backorder Processing in aATP – SAP S4 HANA appeared first on ERP Q&A.

Let’s understand pagination first,

In the context of OData (Open Data Protocol), pagination refers to the practice of dividing a large set of data into smaller, more manageable chunks or pages. This is done to improve the performance of data retrieval and to reduce the amount of data transferred over the network. Pagination is a common technique in APIs and web services to handle large result sets efficiently.

In OData, pagination is typically achieved through the use of query parameters, specifically the $skip and $top parameters. Here’s a brief explanation of these parameters:

1. $skip: This parameter is used to specify the number of items that should be skipped from the beginning of the result set. It is often used in conjunction with $top to implement paging. For example, if you want to retrieve results 11 to 20, you would set $skip=10.
   
2. $top: This parameter is used to specify the maximum number of items to be returned in the result set. It works in conjunction with $skip to define the size of each page. For example, if you want to retrieve the first 10 items, you would set $top=0.
   
3. $inlinecount: This parameter is used to get total count of records by passing value “allpages” to this parameter.

By using $skip,$top and $inlinecount together, you can navigate through the result set in chunks, effectively implementing pagination.

For instance, to retrieve the second page of results (items 501-600), you might use $top=100 and $skip=500.

Now, you have a scenario where you need to fetch the full load from the Business Partner API or any other API of S/4 Hana public cloud with 500 records per page.

Here, $inlinecount parameter will come in the picture.

First get call to the API with https://<S4hanaAPIHostName>:<Port>/API_BUSINESS_PARTNER/A_BusinessPartner?$top=500&$skip=0$inlinecount=allpages

in response, you will get 500 record if records are equal to 500 or more else full load will come in first page it self.

Along with these records, you will also get count of total records in “count” element

if (count>500)

then calculate the number of API call you need to make based on total count

After every API call, Increase the value of skip by 500.

To do all this, you need to write a program in language supported by you application or middleware system.

Let’s call this API in CPI with Pagination

In CPI, OData adapter can manage all parameters, we need to just manage the number of times API should be called by “looping process call” artifact.

As you can see in the below picture, fetching data from S/4 Hana, transform the data in Salesforce Soap API format and transferring to Salesforce system is happing in “Local Integration Process 1”

And Integration Process is only use to call “Local Integration Process 1” in loop.

In OData adapter, just tick “Process in Pages” and enter the total number or records should be called in a single call in “Page size”.

Every time when API call fetches the data, a property “${property.<RECEIVER>.<Channel>.hasMoreRecords} ” is set with true if there are still records to fetch from S/4 Hana or set with false if no records are left to fetch

This property we need to set in Lopping Process Call to give the condition for stopping loop

Receiver: S4Hana

Channel: ODataS4

Condition in Lopping Process Call: ${property.S4Hana.ODataS4.hasMoreRecords} contains ‘true’

Conclusion: After reading this document, you can easily use OData API with pagination and how to use it in CPI.

The post Fetch data in chunks using pagination from S/4 Hana Cloud’s OData API appeared first on ERP Q&A.