Replenishment Using Run Schedule Quantities: Integrating REM & Event Driven Kanban with SAP EWM

 For a long time, this topic was into my mind how repetitive manufacturing with run schedule quantities with ‘Event Driven Kanban‘ can be integrated to SAP EWM/. My current blog is an attempt to manifest the approach to integrate REM, Kanban with EWM in an asynchronous good movement mode.

With the launch of S/4 HANA Embedded 1909 & 2020, things have been more easier and there can be direct synchronous goods movement from manufacturing to EWM,  however this blog is written on 1709 S/4 HANA, hence only asynchronous goods movement can be explained.

The concept of ‘‘Run Schedule Quantity” has been into manufacturing arena for quite long time and its primarily used into Repetitive Manufacturing which represent -Partial quantity of a run schedule header( Header FG) with product cost collector.

Technically speaking, run schedule quantities are created as planned orders. The system creates
this type of planned order if you have set the repetitive manufacturing indicator in the material
master record and created a production version for the material. Mixing with  Event Driven Kanban can make this process more lethal and game changer for period based production industries( Discrete Manufacturing).

Event Driven Kanban:

As the name suggest Event Driven, the trigger of of event-driven Kanban is from MRP and not on a stipulated number of kanbans or a stipulated kanban quantity. The material is not continually made available and replenished at a production supply area, but is procured only when this is explicitly requested. In the process, the advantages of the Kanban module are utilized to simplify material replenishment.

 

Process flow:

 

A control cycle has to have created for Sub-Assembly with without any predefined number of container and quantity. MRP will drive the kanban quantity. Use replenishment strategy 0005 Kanban with MRP and with production version. You need to have REM profile at both the levels BOM if you using Higher Assemblies and Sub-Assemblies. Since, planning is top to down process, PIR will be inserted at top level( Planning Strategy 40)

 

PK13N shows no predefined number of containers for product EWM-51 as MRP is driving factor here.

 

Run MRP live with header product.

 

System created a planned order with Run schedule quantity( RS with firming indicator  PP consultants can catch why firming indicator is appearing)

 

Generate the Event driven Kanban qty from MF60( Legendary transaction used from Ages).

System generated Event driven replenishment with quantity 1383 EA as from MRP.

 

Check PK13N now, an empty container with ID 86 is generated with all the required detail and with Planned order 4708 Which is the reference for GI& GR of Sub assembly.

 

With the lead time of Planned order comes to end, manufacturing person has to post the GR / GI of kanban conatiner.

This is done by PK41. Since this is REM( 1709 HANA), synchronous GI cannot be posted from EWM managed storage location, only Assembly Backflush will be carried out.

 

On posting this system, system creates an Inbound delivery and kanban signal changes to green.

 

With this Inbound delivery, GR is posted immediately posted in EWM due to PPF Scheduling conditions and Actions if below configuration and condition record is maintained.

 

Latter product can be putawayed into Warehouse. Please note S/4 HANA 1909 and 2020 has made this process more simpler and if business works with HUs.

 

Hence the blog ends, appreciate your feedback to make this blog more productive.

 

Regards

Shailesh Mishra

Source: https://blogs.sap.com/2020/12/23/replenishment-using-run-schedule-quantities-integrating-rem-event-driven-kanban-with-sap-ewm/

How to load customers (business partners) with SAP S/4HANA data migration cockpit

 

Purpose

This blog explains the different approach for the load of customers, suppliers (vendors), contact persons in S/4HANA, that makes the use of business partners for these objects mandatory and old transactions like XD01, XK01, … have been deprecated and are no longer available. I will explain how the data migration cockpit can be used for customer load and what is the logic to fill the file template for customers with its different sheets (general data, sales view, finance view, contact persons,…).

 

How customers were loaded with ECC 6.0

With SAP ECC6.0 and previous versions it was common to create LSMW objects linked to different recordings created ad-hoc with transactions XD01 or VD01 or use program RFBIDEK0. File structure had to be defined within LSMW.

 

 

Why approach with ECC 6.0 is no longer possible. Business Partner concept.

S/4HANA requires the use of business partner, instead of using previous methods of creating separate objects for customers, suppliers and contacts. Transactions like XD01, VD01 are outdated and SAP will redirect to new transaction BP, which will be the single point of entry to mantain these objects.

With the business partner approach, one BP can be a customer, vendor (now supplier), contact person, payer, etc. all at once, so there is no need for separate master data objects. The business partner role will define the role they have in the company.

These roles can be defined in customizing.

 

With the new business partner concept, the tables starting with BUT* are the central repository for all BP created. Older tables like KNA1, KNVV, KNB1 are still filled in S/4HANA, but it is necessary to do the necessary customizing settings in Customer-Vendor-Integration (CVI). CVI is used to synchronize customer and vendor master data objects with SAP business partner objects within SAP. With CVI in place, all the customers and vendors are assigned a BP number.

Besides this, with S/4 HANA it is not recommended to use LSMW, as there is a new data migration tool called Data Migration Cockpit, which provides file templates that we will fill to perform the data migration.

 

 

Load customers with Data Migration Cockpit. Fill the file template

The Migration Cockpit (transaction LTMC) provides structured migration templates as it is the case for Customer Master and Customer Master Extension.

 

To get the file you can click the corresponding option in the migration object. This will download an xml file that can be edited in Excel.

 

The Customer Master template contains a number of sheets, each sheet has mandatory fields marked with (*) which must be filled.

 

The person responsible of loading customers needs to fill the load template. I start with the general data that covers name, account group, ….  Although it is possible to use internal numbering for customer creation, customer number is mandatory on the template as it serves as the unique identifier to link data in all sheets to the general data in the first sheet.

If for some customer accounts types you need to use external numbering, it is necessary to enter those in the sheet and use them in all sheets. In this example I use sequencial numbers.

 

Address data also available in this sheet.

 

With S/4HANA Business Partner concept it is necessary to specify the business partner role. In this case I have to choose FLCU01 for customers.

 

The sales views need to be specified in the sheet Sales Data.It is necessary to use the customer number key entered in General Data sheet to link this and other sheets, otherwise there will be an error in the import.

 

Company code view filled in sheet Company Data. Here is where I set the payment terms, reconciliation account, …

 

Contact person data: I assign the contact persons to each customers, using consecutive numbers as ID as numbering will be internal.

 

Sales partner: The customer numbers are repeated four times to assign each partner role to that customer.

 

There are other views that can be filled for sales texts, company texts, … but not included in this exercise. It is necessary to link all possible entries in the file to to the customer numbers specified in the general data view.

 

 

Load customers with Data Migration Cockpit. Run LTMC

Inside of the migration object first it is necessary to upload the filled file.

 

Once uploaded, the file needs to be activated.

 

Now it is possible to start the transfer.

 

Next step is the data validation. Depending on the file size, this will take some time.

 

Once finished, the migration cockpit will show all file validation messages like wrong format, missing mandatory fields, ….

 

Next step is the conversion for the field values.

 

The template contains an external number for the customer; however, we need internal number assignment so the mapping is maintained as below;

 

Remember the number ranges have to be set up in customizing.

 

Click on save and the internal numbers will be generated in sequence.

For other fields I had to add the conversion values from the file to the S/4HANA instance.

 

Next step is to simulate the import in SAP, where different errors might appear.

 

Any errors will appear in the notification screen.

 

Once done, it is time to import the data in SAP. Executing the import loads the data in SAP.

 

data loaded appears in the log. If there are some errors, a Delta file would be created to be processed at a later stage.

 

Once loaded, I check in transaction BP that the customers are loaded. It is also possible to use transaction SE16N with tables BUT000 and KNA1, KNVV, …

 

Summary

As summary, a business partner can be a vendor, customer, contact person all at once and there is no need of separate objects. As this is the new approach in S/4HANA. this makes the use of LSMW not recommendable.

The data migration cockpit is then the best approach in a low complexity scenario, with data being migrated from a single legacy system to a new SAP S/4HANA environment with minimal data transformation requirements.

• Source: https://blogs.sap.com/2020/12/17/how-to-load-customers-business-partners-with-sap-s-4hana-data-migration-cockpit/

SAP Fiori for SAP S/4HANA – Fit-gap analysis for SAP Fiori apps and classic UIs

 As part of SAP S/4HANA Regional Implementation Group I have the privilege of talking to many customers about their SAP S/4HANA project plans. This blog post comes out of some recent experiences and discussions with functional team members around the current best options to assist the fit-gap process of SAP Fiori apps and classic UIs. This approach and the related tools and resources can be used when moving to SAP S/4HANA and/or for Continuous Improvement projects after go-live.

This is the outline of the general approach:

1. Start by scoping your SAP business roles
2. Get to know your real world business roles
3. Envision the future per real world business role
   • Use this to drive your fit-gap criteria for apps and UIs for your business role
4. Explore the SAP business role to refine your app/UI selection for your real world business role according to your fit-gap criteria
5. Validate your extension options for meeting any gaps identified
6. Build your roadmap for now and later

Why this approach?

It’s no longer enough to understand your business process, you need to think through how this translates to user’s actual working environment, their needs, and how those business users contribute to business outcomes.

Ultimately user adoption is key to achieving business outcomes – so you need to go beyond the abstract business process to how this will translate into the every day reality of your business users.

Fit to process is only part of the picture – you need to fit to your user too!

Why does this approach end with a roadmap?

As at SAP S/4HANA 2020, the solution now delivers:

• More than 2K SAP Fiori apps
• Alongside more than 8K classic UIs
  • Classic User Interfaces include GUI transactions, ABAP Web Dynpro applications, Web Client UI)
• Plus the first native mobile app for SAP S/4HANA (with more to come)
• More than 40 optional Line of Business processes many with process innovations – e.g. Group Reporting, Central Procurement, predictive MRP, Advanced Accounting and Financial Close, Intercompany Management and Reconciliation – as listed in the Feature Scope Description.
• A range of intelligent automation use cases, including:
  • More than 50 Situation Handling use cases
  • More than 70 Robotic Process Automation use cases
  • More than 15 Machine Learning use cases.

In other words, the reality is there is now so much new business value available in SAP S/4HANA that you are unlikely to implement everything you want in one go. Even if you do have the resources and skills within your project, there are likely to be limits on the capacity of your business users and your business itself to take advantage of that much new value in one deployment.

The most likely scenario during fit-gap is you will discover much more that you want to use than you can pragmatically use right now.  However, you don’t want to lose that discovery entirely, as it can help shorten future Continuous Innovation phases.

Capturing your collective initial thoughts and discoveries into a brief roadmap can simplify future discussions. It can also give you some top-of-mind options if things change. You will have some initial analysis to draw on if, for example, a change becomes more urgent due to a sudden industry or market change.  That initial analysis can also be useful if a change in strategy, tactics, or timeline frees up more capacity for change, and when at some point you upgrade to a future SAP S/4HANA release.

Step 1 – Start by scoping your business roles

The SAP S/4HANA User Experience revolves around business roles, matching the User Experience to people (i.e. business users) who share similar needs based on their work area and tasks (i.e. their business role).  The majority of decisions around User Experience are derived from that including:

• Which processes/tasks they participate in
• Which device types are likely to suit their working patterns
• Which apps or UIs are applicable to those processes/tasks and device types
• Which intelligent automation options or real-time analytics would make them more productive
• How should these apps be presented to them to optimize their productivity
• What additional information or additional features they may need, which may be provided by configuration, adaptation, extension, or even custom build

SAP S/4HANA delivers more than 500 Business Roles based on real world jobs that can be used as templates as explained in Understanding SAP Business Roles. You can explore what’s possible in your Sandbox system using these templates.  In your Development environment you copy these templates as a starting point for creating your custom business roles. You can then refine your custom business roles to match what you want to deploy to your business users.

SAP S/4HANA delivers more than 500 Business Roles

Tip: You can activate the apps in your custom business roles in Development environment using task lists, so that only the apps you actually use are activated.

Gather the list of SAP Business Roles you need to explore as part of your scope.

There are two main approaches to scoping your business roles depending on where you are in your SAP S/4HANA journey:

• SAP Readiness Check – use this when converting from SAP Business Suite, or when upgrading from a lower to a higher release of SAP S/4HANA
• SAP Best Practices Explorer – use this when you are doing a new implementation of SAP S/4HANA and have no transaction usage history in SAP

For both options you will also need to include the standard business roles to configure adapt and extend SAP S/4HANA.

Option 1:  Scoping using SAP Readiness Check

As part of the readiness check process, you will capture your system usage of current GUI transactions in your production system. This usage data is then used by SAP Readiness Check to identify relevant business roles.

SAP Readiness Check recommends the most relevant business roles

Within each Business Role the usage data is also used to assign a relevance rating to the associated SAP Fiori apps.

Relevance ratings for apps within a business role based on your usage data

Find out more in Readiness Check – Details about the topic of Fiori.

If you want to start your scoping before you set up SAP Readiness Check, you can also provide your GUI transaction usage data as an input to the SAP Fiori apps recommendation report. This report provides much the same analysis and will help you in your early planning.

Option 2: New implementation of SAP S/4HANA, with no history of SAP

Using the SAP Best Practices Explorer, you can review the best practices scope items for your target SAP S/4HANA version and localization country. These scope items represent different business process areas.

Each best practice scope item includes a business process diagram and test scripts.  The business process diagrams and the test scripts will confirm which business roles are involved in the process, including configuration roles needed. The test scripts will even confirm the recommend SAP Fiori app or classic UI for each process.

Example of a Best Practices process diagram highlighting business roles and apps/UIs assigned to tasks

Include business roles that configure, adapt, and extend SAP S/4HANA

Don’t forget to add the configuration roles as explained in Yes you need SAP Fiori to configure, adapt, and extend SAP S/4HANA. These roles are currently:

• Administrator
• Analytics Expert
• Business Process Specialist
• Configuration Expert – Business Process Configuration

These should be activated in your Sandbox and Development environments as a minimum, i.e. in addition to your scoped business roles.

To make it easier these are now included in the tasks lists for both rapid content activation (for SAP Business Roles) and content activation (for custom business roles).

Select recommended SAP Business Roles option in task lists

Refer to SAP Notes:

• 2686456 – Fiori Setup: Content Activation for SAP Business Roles
• 2813396 – Fiori Setup: Content Activation for Business Roles

Step 2 – Get to know your real world business roles

Whatever SAP Fiori apps and classic UIs you choose will need to fit with the real world needs and working environment of your business users as much as they need to fit with your to-be business processes.  For example:

• App and UIs are often optimized for use on selected device types. You will want to make sure that you have the correct app or UI that suits both the task *and* the device type.
• Different features may be more or less relevant depending on where and when in their day the user performs this task. For example, if they are travelling around users need a simple flow and few buttons, when they are back at their desk users can take advantage of more advanced features and do more detailed analysis.
• Apps and UIs may need to be personalized to make sure they can be used in the business user’s actual working environment, for example whether they work in bright sunshine or a darkened room.

Important: You will need to gather data and other evidence of the real needs of the business users in your organization. Why? Your project team may never have experienced the working environment of your organization’s business users. Many project consultants have spent their entire career in an office environment.  This is why it is so important to get some data and evidence of the real working environment of your users.  This can be done through site visits, interviews, photos, or videos. The better the quality of your information, the easier to determine real world fit of your UX.

Some useful questions to ask about your business users include:

• What is their working environment? Do they work in an office? Are they a field worker? Do they spend much of their work time travelling?

 

• Do they have any mobility restrictions? For example, if they are climbing ladders, or need to move around equipment on a factory floor, that might impact what type of device they can use for certain tasks. Safety regulations may even prevent them from using certain devices in certain situations.

 

• What is their typical workwear? Uniforms, hazmat suits, helmets, safety goggles and gloves, tool belts and other accoutrements can impact when and where they can use their devices.

 

• What devices do they currently use (or plan to use) and for what types of tasks? This gives a heads-up on both the degree of change and whether there are other factors you may need to pay attention to in your project, such as safety regulations, or even procurement of devices.

 

• What types of apps or UIs do they currently use? Are they experienced in certain types of user interfaces such as GUI transactions? This helps you communicate changes and benefits of your final app selection.

 

• How frequently do they use them? Knowing whether they are a casual or expert user can help you decide between a simple app or a more complex app.

 

• What are their most frequent on-system tasks? This helps identify which activities are most critical to their day-to-day working life. It’s worth asking if there are any highly manual tasks, either on-system or that involve both on and off system activities, e.g. copying data from email attachments or spreadsheets into the system? These could indicate the need for an Upload/Import app or even a potential Robotic Process Automation scenario.

 

• What are their most important exception tasks? These tasks are occasional critical response to business exceptions, potential bottlenecks or stumbling points where they need to respond promptly to ensure business continues smoothly. For example, a supplier not being able to deliver all of the quantity requested, or a contract approaching an expiry date, or an equipment breakdown. These could indicate a possible fit to Notifications or even a Situation Handling use case.

 

• What are the entry points to their tasks? An entry point is not typically a “doing” activity (e.g. create, change, delete, release, etc.), it’s the trigger for action. In other words, how do they decide what should they do? How do they decide of all the things they can do, what takes priority? Are they monitoring something in the system? Are they responding to an external request via phone or email or an incoming advice from a customer or supplier?

 

• What are their biggest pain points when working on system? This helps quickly identify perhaps apps or features that may provide obvious business value to these users, such as desirable embedded analytics/KPIs, intelligent automation, or a search across multiple business objects.

Step 3 – Envision the future per real world business role

Workshop with the business process experts and some business users themselves what sorts of changes would bring immediate business benefits.  At this stage you are looking to build a high-level roadmap that helps you determine your fit-gap criteria for apps that fit both your business outcomes and your business users. This can be good to do as design thinking workshop.

Set your fit-gap criteria for apps for each role

Identify the most important criteria for each business role. Your definition of “fit for purpose” must include UX criteria and not just functional capability. Failure to include UX criteria can result in a UX that is overly complex and confusing.

Important: UX criteria must be focussed on the real needs of the business users in your organization, and not on the preferences of your project consultants. Why? Many project consultants  are themselves highly expert users who typically come from outside your organization and may never have experienced the working environment of your organization’s business users.  Good user adoption depends on fitting the UX to real needs of your users in their working environment.

For example:

Are mobile devices important for certain tasks?  You will need to pay attention to device type fit when selecting apps or UIs.

You have GUI-invested users? You may want to focus on complementary apps first, i.e. apps that bring new business value, and can navigate to rather than replace well-loved transactions.

You have casual users? Focus on ease of use for most frequent tasks.

You have deep analysis/investigative users? Focus on embedded analytics that give highly flexible analysis options. Consider whether and how other analytical tools such as SAP Analytics Cloud will be integrated with their user experience.

Users who are overburdened with rote work or manual tasks? Focus on intelligent automation use cases and apps that can ease their workload.

Users who need to respond quickly to changing information? Focus on analytical apps, situation handling, and machine learning use cases, that help them quickly prioritize what to do next.

Step 4 – Explore the SAP business role in your Sandbox or Trial system to refine your app selection

In a typical SAP S/4HANA project, the recommended approach is to start by activating whole SAP Business Roles in your sandbox system for exploration.  This brings a predefined set of SAP Fiori apps, classic UIs, the navigations between them, and the associated authorizations for you to explore.  The aim is to use the SAP Business Roles as a starting point to creating your own custom business roles.

You can activate SAP Business Roles using rapid activation, which provides options to:

• Create a test user per role so you can view the apps and features as they will see them
• Copy the SAP Business Role to the customer namespace so you can start refining your list of apps and UIs as you go, simplifying your next steps into your development environment.

As you explore the business role, make sure you use the User Actions menu > About to capture the exact technical ids of the apps and UIs you want to include in your final role.

The User Actions menu feature About shows the technical id of a SAP Fiori app or classic UI

Refer to: Finding the technical name of an app

Some business roles have more than 150 apps or UIs you can potentially use.  You will need to set some priorities around what to explore first, particularly if you know you only have the time, resources, or skills to introduce a small set of apps in your current project phase.

Prioritizing apps for exploration

These are a few suggestions that customers have found useful depending on your focus and priorities for this role.

You need to bring clear new business value of SAP S/4HANA.  Review the SAP Fiori Lighthouse scenarios for a shortlist of apps bringing the best new value.

You want to bring intelligent automation benefits.

Situation Handling can be good fit for business exception tasks – review the Use cases for Situation Handling.

Robotic Process Automation can be a good fit for reduce rote or manual tasks – review the use cases in the RPA bot store.

Machine Learning use cases can be a good fit for identifying business exceptions or making better informed choices  – review the scope items in the SAP Best Practices Explorer.

You want to bring some quick wins for users who currently use and like SAP GUI.

Prioritize apps that bring real-time insights that complement current GUI transaction usage, such as: Overview pages, Monitor and Manage apps, or Smart Business KPIs.

These apps are often a good fit for monitoring and prioritizing day-to-day main activities, especially where the user is responsible for certain business objects. For example: a Purchaser who monitors Purchase Requisitions and Purchase Orders; a Accounts Payable Accountant who monitors outgoing payments; or a Maintenance Technician who monitors Equipment and Maintenance Notifications.

Refer to: Overview Pages – a good place to start

You need to find simple apps, especially apps that will work on phones.

In the SAP Fiori apps reference library, check the app detail to see if it works on device type “Smartphone”. You can also select all the apps and UIs for the business role, and filter by Phone.

Device Type information in the SAP Fiori apps library

Remember to consider native mobile app offerings. While there are only a few of these now provided with SAP S/4HANA, the list will grow over time.

Remember that classic UIs are not supported on phone.  However SAP Screen Personas can be used to provide a phone-ready overlay.

Tip: Classic UIs are supported on desktop/laptop.  Most classic UIs are also supported on tablet as of SAP S/4HANA 1909 or higher as explained in touch-enablement of the classic UIs.

Consider launchpad features that bring immediate benefits

These can bring new benefits even when a business role will mostly use classic UIs. For example:

• Search on business objects
• Notifications
• Default values – to save on data entry

Refer to The SAP Fiori User Experience for SAP S/4HANA

Avoid predecessor apps

In the SAP Fiori apps reference library, when you aggregate apps against your SAP S/4HANA release, look out for any apps marked as “Successor also chosen”, and remove those from your list of apps to be considered.  As a general guideline, you want to avoid working with any app that has already been superseded by a new and improved equivalent.

When there is no suitable SAP Fiori app for a task, you may need to use a classic User Interface

Classic User interfaces include GUI Transactions, ABAP Web Dynpro, or Web Client UI. All of these classic UIs can be launched from the SAP Fiori launchpad. You can also launch to URLs, e.g. SAP Cloud Platform apps, 3rd party apps, and related websites.

Important: Using classic UIs to supplement SAP Fiori apps is normal and expected.  The SAP S/4HANA roadmap towards new SAP Fiori UX is a long-term vision.  With each SAP S/4HANA release around 300-350 SAP Fiori apps have been added.  It’s worth noting that when developing new apps, bringing new business value via SAP Fiori has been prioritized over replacing the old.  There are now more than 2K SAP Fiori apps delivered with SAP S/4HANA. However even with that large number, there are more than 8K classic UIs that can also be used and launched from the SAP Fiori launchpad.  Some business roles have greater SAP Fiori coverage than others.  You can use the SAP Fiori apps reference library to quickly see a count of the number of available apps and get an idea of coverage as explained in Understanding SAP Business Roles.

Step 5 – Validate your app selection and extension options

Once you have worked out which are your most likely SAP Fiori apps and classic UIs, you will need to validate that they can meet your business needs at the fine detail level.  This is typically done with a series of demonstrations and walkthroughs with the business.

Any gaps – such as missing fields or features – will need to be covered.  Most common gaps can be covered by in-app extensibility options. You can make sure you are prepared for any questions by following a few simple steps to check what is available:

• Find and review the Extensibility Documentation for the app, where provided
• Confirm available optional fields for the app
• Confirm if custom fields can be added
• Review options to adjust visibility, features, and layout

Where gaps cannot be covered using in-app extensibility options, note their criticality and business impact.  You will need to pass these for deeper feasibility assessment by your technical team for side-by-side, classic, or build your own extensions.

Find and review the Extensibility Documentation in the SAP Fiori apps library

Some SAP Fiori apps have an Extensibility Documentation link in the SAP Fiori apps reference library that explains the extension options provided for the app. If there is an Extensibility Documentation link it will be shown in the Implementation Information tab, section Extensibility.

For example:

Extensibility Documentation link example in the SAP Fiori apps reference library

Tip: Make sure you have already selected your SAP S/4HANA release at the top of the implementation information tab. This will adjust information on the tab for your release, including the Extensibility Documentation link.

Release selection in the Implementation Information tab of the SAP Fiori apps reference library

Important: If a SAP Fiori app does NOT have Extensibility Documentation this does NOT mean the app cannot be extended. It simply means that there is no specific extension advice for this app.  Most SAP Fiori apps follow floorplans or frameworks that have built-in extension options. For example:

• Apps based on SAP Fiori elements floorplans can use Adapt UI, Adapt Filters, and Settings
• Smart Business apps can be adjusted using SAP Fiori app Manage KPIs and Reports

Find more examples in Yes you need SAP Fiori to configure, adapt, and extend SAP S/4HANA.

There are also more advanced extension options provided generally in SAPUI5 itself. These require developer skills. For example, Using Component Configuration – a technique that keeps most of the standard app intact and just enables the replacement of a specific view or controller. Refer to: SAPUI5 SDK > Documentation > section Extending Apps.

Tip: For classic UIs you will not find listed Extensibility Documentation.  However, these also have some extension options, such as using SAP Screen Personas to improve the layout. You can also use some classic extension techniques – refer to:

• SAP GUI – Enhancements to the Standard
• Adapting and Enhancing Web Dynpro ABAP applications

Confirm available optional fields for an app

One of the most common requirements is for a few extra fields.  Many apps provide in-app extensions that let you include additional optional fields.  These are some quick checks to make sure you know what is possible.

Examine the app using User Actions > Adapt UI. The Adapt UI in-app extensibility option applies to all SAP Fiori elements apps and some freestyle apps.  That’s approximately 50% of the more than 2K SAP Fiori apps delivered with SAP S/4HANA.  Some apps provide no extra fields, some provide a handful, and some are known to provide over 100 optional fields via Adapt UI. So it’s worth a quick check to see what you can add.

Adapt UI feature in the User Actions menu

Example of option to add field using UI Adaptation

Reviewing the list of available fields in the Add Field dialog

Important: You need to be authorized to see this feature by being granted security role SAP_UI_FLEX_KEY_USER.

For apps with Filter areas, examine the Adapt Filters link on filter bars. Some apps can have dozens of additional filter fields available.

For apps with Tables and Charts, examine the Settings icon button for Tables and Charts.  Many tables and charts provide additional fields to be included simply by checking the matching checkbox in the Settings dialog.

For Smart Business KPIs and reports, examine the configuration options in SAP Fiori app Manage KPIs and Reports.

For Multidimensional reports review the available dimensions.  You can also use SAP Fiori app View Browser to review the available data in the associated CDS View. Consider using SAP Fiori app Custom Analytical Queries for any additional reports you need to build.

Confirm whether custom fields can be added using SAP Fiori app F1481 Custom Fields and Logic

There are many SAP Fiori apps that provide the option to add custom fields using SAP Fiori app F1481 Custom Fields and Logic.  These apps typically also provide Extensibility Documentation where they list the matching Business Context Scenario(s) to which custom fields can be added.

Extensibility Documentation for the SAP Fiori app F1602 Manage Product Master Data showing available business context scenarios for adding custom fields

These business context scenarios centrally update a range of related objects for that scenario including:

• SAP Fiori apps
• Classic UIs
• CDS Views
• OData Services
• APIs
• Output templates (e.g. email, forms, reports)

You can even control where the fields are visible and/or searchable, whether they can be aggregated and much more. Find out more in the Custom Fields and Logic documentation.

Review options to adjust visibility, features, and layout

Examine the app using User Actions > Adapt UI

Typical changes that can be made using Adapt UI include:

• Add, move or hide fields
• Add, move or hide sections
• Add, edit or hide cards
• Move or hide buttons and links
• Default preferred links in Smart Link dialogs

Adapt UI field level options in an Object Page

Adapt UI card options in an Overview Page

Examine the app for setting default values and variants

Many apps support minimizing data entry through User Defaults.  Both single (primary value) and multiple (primary value + additional values) can be provided depending on whether the target field can accept single or multiple value. Confirm the available user defaults by reviewing the list in Setting User Defaults in SAP S/4HANA.

Apps with filter areas, tables, charts, or cards often provide options to default preferred fields and features using Variant Management.  Variants can be created for an individual user, or made public/shared for use by multiple users.

List Report app showing Adapt Filters link and table Settings icon button

Typical adjustments that can be made with variants include:

• Set preferred filter fields and static values in a filter area
• Set preferred table columns and column sequence of a table
• Set preferred table sorting and grouping (e.g. for hierarchy display of totals and subtotals)
• Set preferred chart columns for dimensions and categories
• Set preferred chart type

For classic UIs, consider SAP Screen Personas to adjust visibility, features and layout

When there is no suitable SAP Fiori app for a task, you may need to use a classic User Interface such as a GUI Transaction or ABAP Web Dynpro.

SAP Screen Personas can be an effective option to quickly improve the content, usability and look and feel of classic UIs. This can avoid the need to create a complex custom-built app.

You can use SAP Screen Personas to:

• Hide or move fields to help users focus on only what’s important
• Merge tab content into a single place
• Adjust the look and feel to make the UI look more “Fiori-like”
• Use scripting to automate repetitive or common steps, fetch data from other related transactions or perform simple calculations
• Build simple mobile ready applications using the SAP Screen Personas Slipstream engine

SAP Screen Personas is delivered as a free add-on to your SAP S/4HANA system.

You can find more including tutorials in the SAP Community topic for SAP Screen Personas

Step 6 – Build your Roadmap for now and for later

Fit-gap analysis is one of those activities that can be easily derailed by scope creep.  As you design your custom business role you will need to keep a track of which SAP Fiori apps or classic UIs you want to use now in this phase, versus future continuous improvement phases.

When collecting up your list of apps, make your next steps in development environment easier by collecting the following details:

• The technical app id – this identifies the exact app and the technology type.
  • Why? Names can be confusing or similar across apps, particularly where there are multiple versions of an app or successor apps.
  • This also helps with confirming complex extension options should they be needed.

• The original SAP Business Role, SAP Business Catalog and SAP Technical catalog of the app
  • Why? This helps when refining your custom role in your Development environment using the Launchpad content manager and Launchpad app manager tools.

All of this information also provides a handy reference for assessing successor apps when you upgrade to a higher SAP S/4HANA release.

Becoming a SAP Fiori for SAP S/4HANA guru

Tip: The screenshots in this blog post were taken in a SAP S/4HANA 1909 FPS02 system, with SAP Fiori frontend server is in embedded mode.

You’ll find much more on our SAP Fiori for SAP S/4HANA wiki

Brought to you by the S/4HANA RIG

Source: https://blogs.sap.com/2020/12/10/sap-fiori-for-sap-s-4hana-fit-gap-analysis-for-sap-fiori-apps-and-classic-uis/?source=social-global-voicestorm-LinkedIn&campaigncode=CRM-YD20-SOC-GETSOC1