The mill products difference – dealing with dimensions and tolerances
I love this picture. This is ThyssenKrupp Rasselstein‘s storage for hot rolled coils in Andernach. In SAP terms each coil is an own batch number with own attributes, dimensions, quality information and weight. If you run a “make-to-order” production order for 60 coils, each coil will be different, each will result in a batch, each with its own unique classification.
This data model makes the endless variations of dimensions and grades managable without creating a material master data record for each variation.
Working with the system, the user in many cases needs to have the classification (or the configuration) on the screen to actually identify the individual inventory item, sales or production order. The material or batch number alone is simply not sufficient.
What would you need to do to achtually include the characteristics into a Fiori work list or object page?
Image by Wolkenkratzer (Own work) [CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0)], via Wikimedia Commons
The Mill Products Industry Solution in SAP S/4 HANA
In the old days of R/3, the Mill Products industry soution was a modiying add-on, later in SAP ERP you still had to explicitly activate it. As industry boundaries blur, and the Mill Products functionality has been used and requested from companies in health care, chemicals, life sciences or automotive, SAP decided to make the former industry functionality available as part of standard S/4 HANA. No more discussion whether to activate or not, and whether DIMP including Mill Products is compatible with another industry solution. When you move to S/4 HANA you will have the mill products solution “always on”.
Nearly all of the former industry functionality & processes are available in SAP S/4HANA today.
But SAP S/4 HANA is very different – and I would like to highlight just 2 aspects:
Under the hood – SAP Suite for HANA is natively optimized and built for SAP HANA. Well, you could have guessed this from the name. What this means, though, is that applications, analytics and UX are built on top of SAP HANA – and key element of this architecture are the CDS views in the picture below. They are consumed in embedded analytics, and are the foundation for various types of Fiori apps.
Where SAP HANA is the powerful new engine under the hood, SAP Fiori is the beautiful new web-based user interface. It even won a few Red Dot design awards for its interaction concepts. its embedded analytics, and the newest Fiori 2.0.
I would like to focus here on the second layer in the hierarchy: the domain specific insights: the overview pages, the list reports, and the worklists. Take for example, the batch overview page (in the latest release called “manage batches”).
This looks like a rather straigh-forward report, but has a lot of in-built HANA-power.
The filters in the top row dynamically narrow down the search result – and the user can, of course, choose the fields used for filtering. The columns can be flexibly selected by the end user, and stored in a separate variant. As you see below, the standard version of the “Manage batches” does not include any classification characteristic values.
Industrializing SAP ERP
One key aspect of our mill products industry solution is the support for characteristics. This is why we have build fast data entries for many of the key transactions in the past. In the SAP GUI days, we defined a number of characteristic overviews in customizing, called “MUEBS”, basically a custom-defined collection of characteristics.
The tricky bit for the developers was the fact that each material has different characteristics, and they are defined as part of the PLM master data in a customer system. So you can’t hard code on specific columns and filters – it’s all dynamic.
How would this work with Fiori?
Before we start to change the batch overview page, let’s first understand on a high level how the page works. Behind the Fiori is – no surprise – a CDS view called
C_BATCH_TP. To add filter criteria (and columns) to our overview page, we will need to extend this CDS view – in our case with the characteristic fields.
Step 1: Generate a new CDS view with the classification information
As part of the SAP Advanced Variant Configuration Embedded Analytics scope in 1610, SAP has delivered a generation report which will create a CDS-View based on a class.
Use the tile ‘Classification/Configuration CDS View’ under ‘Variant Configuration Modelling’ tile group (role SAP_BR_PRODUCT_CONFIG_MODELER).
You can either use an existing class, or create a new one that contains only those characteristics you would like to use for the extension. Note that you may want to “merge” characteristics from multiple existing batch classes to display characteristics from various materials.
This report can run by a key user. You would do exactly the same to create CDS-view for embedded analytics. This will work out-of-the-box with your “normal” ECC batch classes that you may have migrated to S/4HANA.
Step 2: Create and link a customer extension DDL source with the standard view
The following will need to be done by a developer.
Create a new DDL source view (as extend view), specifying the view you want to extend, and the association to the just generated classification base CDS view for fetching the characteristics needed in the extension.
Let’s do this step by step. First let’s create the extend view.
The extend view needs to be defined like this: It extends
Z_MANAGE_BATCH_EXTENSION associating the classification CDS-view generated by the report in the previous step. If you prefer code, it looks like this:
Step 3: Define the Annotations – aka the “field catalog” of the new classification fields – to define “behaviour” for the end user
Per each characteristic you can define whether it is visible by default, and can overwrite the column name with an own definition (if needed).
The following annotations are needed specifically to render the characteristics in the UI .
Fine-Tuning the Layout
The end user can now adjust the filter options by adding also characteristics to the filter criteria of the app.
Also, the end user can define which of the predefined characteristics from batch classification should be included as a column in the batch overview.
End Result: An Industrialized “Batch Overview” with the Batch Classification to Filter and Display
The Fiori screen is enhanced with 2 new filter criterias aka batch characteristics “Length” and “Color”.
The search result, the list of batches, displays additionally batch characteristic values “Length”, “Quality”, “Thickness” and “Width” (based on the user specific layout).
Conclusion, Outlook & Reuse
We have built this initially as a PoC to test the extensibility of Fiori screens with characteristics.
For the “Batch Overview”, we showed that this is possible without modification. This requires minimal involvement by development. The end user can then select from the extension which characteristic values should be used as a filter and as additional columns. This screen layout can be saved as a variant. We will deliver a consulting note that to describe this approach as well.
This concept should work as well for other application that deal with other classified objects. We have built this out only for batch. Please add a comment if you used this also for e.g. materials, documents,…
We are also analyzing this extension concept for variant configuration characteristics.
Prequisite to build this, is a link between the classification and the standard CDS view. In our example below the
clfnobjectinternalid acts as such link.
@EndUserText.label: ‘extension view'
extend view C_BatchTP with Z_MANAGE_BATCH_EXTENSION
association[0..1] to Z910023CH_VC_PLATE_BATCHMCH1_ as _classification on $projection. clfnobjectinternalid = _classification.ProductConfiguration
This concept is currently intended only for S/4HANA on premise due to the development enhancements. This does not require any mill-specific coding and should work for all industries.
Usability Considerations when Defining the Batch Class
Please take a look at the filter and column selection above. If this list of available characteristics is too long the usability will suffer. Luckily we can define such extension class specifically to this purpose, and thus limit the characteristics, comparably to the maximum of 10 characterstics you were able to include in the fast data entry’s characteristic display “MUEBS”. Obviously, we cannot switch between multiple alternative characteristic displays per each material category.
Your Feedback Please
Feedback & questions are welcome, as always. We are specifically curious on your experience using this, and suggestions for improvement.