SAP S/4HANA Advanced Available-to-Promise (aATP) is a critical component of the S/4HANA suite that enhances the standard ATP (Available-to-Promise) functionality with more advanced and flexible features. It is designed to meet complex order fulfilment processes and ensure higher accuracy and efficiency in inventory allocation and customer order management.

Key Features and Functionalities of aATP

Product Allocation (PAL)

Product Allocation (PAL) in SAP S/4HANA’s Advanced Available-to-Promise (aATP) is a feature that enables businesses to control the distribution of limited products or resources across various customers, channels, or regions. It ensures that constrained products are allocated according to established rules and priorities, preventing overselling and ensuring that key customers or markets receive an appropriate share.

• Purpose: Ensures products are distributed according to predefined rules and limits, preventing overselling and prioritizing important customers or channels.
  
• Process: During order processing, the system verifies these allocations to determine the amount of product that can be confirmed for each customer.
  
• Benefits: Aids in managing limited products, balancing supply and demand, and safeguarding key customer relationships.

In aATP following aaps are applicable for product allocation –

• Configure Product Allocation
  
• Manage Product Allocation Planning Data
  
• Manage Product Allocation Sequences
  
• Assign Product to Product Allocation
  
• Product Allocation Overview

Concepts of Product Allocation (PAL)

1. Product Allocation Object (PAO) steps

• The core of PAL is the Product Allocation Object (PAO), which defines the framework and scope for allocation. It includes relevant materials (products), customers, customer groups, and parameters such as sales organizations or regions.
  
• A PAO simplifies the grouping and management of allocation rules.
  
• The Configure Product Allocation app is used to set up a PAO, allowing you to incorporate various characteristics into the product allocation object.
  
• The first step involves defining allocation rules within the PAO, which includes establishing relevant dimensions (such as products, customers, and regions) and assigning quotas. Allocation rules are time-phased, meaning they can vary across different periods (e.g., weekly, monthly).

Example Scenario

Imagine a company that manufactures a highly demanded mobile phone but has limited production capacity. The company has key customers across various regions and wants to ensure fair distribution to each region. To achieve this, the company creates a Product Allocation Object with rules that allocate specific quantities to each region based on historical sales data and strategic priorities.

Order processing: When orders are placed from different regions, the system checks the available allocation for each region before confirming the order. If a region’s quota is exhausted, no additional orders from that region will be confirmed unless the allocation is increased or unused quotas from other regions are available for redistribution.

In this example, instead of using regions, the allocation is based on a combination of sales organizations and sold-to parties.

Created product allocation objects –

With required characteristics –

2. Product allocation sequence

In our example Mobile allocation sequence consists of two sequence groups in a specific order. This order ensures that we first attempt to fulfil the requested quantity from the specific allocation per customer. If the allocation quantity is insufficient, the system will then use the second allocation during the Available-to-Promise (ATP) check. Consequently, important customers have access to two pools, while other customers can only use the quantity from the general pool.

The capacity sequence section contains a single sequence group that represents transport capacity. This group includes two allocation objects—one for the trailer and one for the battery. During the ATP check, all constraints within a sequence group are considered using AND logic.

3. Allocation planning

• Allocation rules are the core of PAL, determining how much of a product can be allocated to different customers or groups. Quotas are set based on historical data, forecasts, or strategic priorities.
  
• These rules can be time-dependent, allowing businesses to adjust allocations based on seasonal demand or other factors as per their business relevancy.
  
• For this ‘Manage Product allocation Planning data’ app is available where we can allocate the quantity.

Creation of Product allocation objects –

Planning data to be setup for each allocation object –

MOBILE_STANDARD_SALES

Capacity Sequence is nothing but the available capacity –

Planning data setup for MOBILE_TRANS_CAPACITY –

4. Assign product to Product allocation –

Product allocation output

Sales order creation to check confirm quantity after PAL set up. As per below scenario even though my capacity is 30 system has considered 15 qty after considering sequence and planning data by considering current period.

The actual ATP quantity is 100 in the system but system is showing confirm quantity in sales order after Product allocation setup,

5. Product allocation overview app–

This will give end to end overview of product allocation and order confirmation.

Integration with Other aATP Features

• Backorder Processing (BOP): PAL works in conjunction with BOP to reallocate inventory to high-priority orders if the allocations allow.
  
• Supply Protection: PAL can be used in combination with supply protection to reserve inventory for specific customer segments or markets, ensuring that critical orders are always fulfilled.

Benefits of Product Allocation (PAL)

1. Prioritization of Key Customers: PAL ensures that key customers or markets receive the products they need, even in situations of limited supply.
   
2. Controlled Distribution: Prevents overselling by enforcing quotas and ensuring that sales commitments are within the limits of available resources.
   
3. Flexibility and Responsiveness: Time-dependent allocation rules allow businesses to adjust to changing market conditions, seasonal demand, or strategic priorities.
   
4. Improved Decision-Making: Real-time tracking of allocation consumption provides actionable insights for sales and operations teams, enabling better decision-making.

The post Advanced Available – to – Promise (aATP in S/4HANA) appeared first on ERP Q&A.

The SAP landscape has evolved significantly, with businesses seeking simpler, more efficient solutions that offer excellent user experiences. Many organizations remain deeply embedded in the SAP ecosystem, primarily focusing on ABAP over other languages. So, is it possible to develop feature-rich applications without other frontend languages? Yes, leveraging ABAP with RAP (ABAP Restful Application Programming) makes it possible.

Restful Application Programming is an ABAP programming model for creating business applications and services in an AS ABAP or BTP ABAP environment. RAP offers a standardized way of developing applications using Core Data Services (CDS), the modernized extended ABAP language, OData protocol, and the concept of business objects and services. RAP applications can only be created through ABAP development tools (ADT) and it’s available in SAP BTP ABAP Environment, SAP S/4 HANA Cloud, and AS ABAP >=7.56.

Before digging deeper into RAP, let’s explore CDS, annotations, and business services. To illustrate these concepts, let’s create a simple read-only list report application.

Developing an OData Service for simple list reporting

An OData service follows the best practices for developing and consuming RESTful APIs. This service can be used in SAP Fiori applications and can also be exposed as Web APIs. Below are the steps for creating a simple list report application:

Let’s explore each step in detail by creating the application.

Sample requirement: Create a read-only list report application which shows purchase order information.

• Create an interface CDS view which takes data from Purchase Order Header (EKKO) and Item (EKPO).

• Create two interface CDS views for showing master data of purchase order type and material details.

• Make an association between the purchase order type CDS view and material details CDS view from the purchase order header/item CDS view. The associated views will act as Search Help in the list report after applying the annotations.

• Create a consumption view on top of the Purchase Order Header/Item interface view (ZI_PURCHASE_ORDER_RVN).

The UI annotations needed for the application are written in the consumption CDS View or Metadata Extensions.

Now, we have the data model and the required annotations to manifest semantics for it. The next step is to create the OData service and binding the service.

To define a service, we first need to create a service definition. In service definition, we specify the CDS entities that need to be exposed. In this example, the gateway client is replaced by the service definition and service binding.

As a last step, create the service binding for service definition.

Set the binding type as OData V2 – UI, since this is an OData V2 service.

After publishing the service, the exposed entity and associated entities will be visible. Click on the entity and click the preview button to see the preview of the application.

Purchasing Doc Type Search Help

Material Search Help

Conclusion

This blog serves as an introduction to developing OData services for simple list reporting using the ABAP Restful Application Programming (RAP) model. By following the steps outlined, you can create a read-only list report application that showcases purchase order information. We have covered the basics of creating CDS views, defining and binding OData services, and incorporating annotations for enhanced functionality.

The post ABAP RESTful Application Programming Model (RAP) 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.

• On BTP: Cloud Connector Connection to Gateway system and Destination
  
• OnPremise: Activating required standard Fiori Application

Step 1: Open Template Wizard and select the application type as SAP UI5 Adoptation Project.

Step 2: Select the Target Environment as ABAP as we intend to deploy the application to onPremise

Step 3: Enter Project Name and Namespace details as shown below

Step 4: Select the Gateway system and the standard Fiori application. select yes for creating extension project as we intend to extend the standard application. Please note that you will be not able to extend the if if it is set to ‘No’. Here i have chosen My Time Events App. Click on Finish.

Step 5: You see the App folder created and make sure that .extconfig.json is created.

Step 6: Right click on .extconfig.json and click on “Create Extension” to see the extension possibilities.

Step 7: Select type of extensions you would like to do. in my case i have selected Controller and View Extension which is the copy of the original view/controller.

You may now choose to edit the view to add new controls and add the handlers in controller either with new function handles or editing extisting one’s. adittionally you can also choose i18n extensions to extend i18n files.

The final folder Structure would look like below. make sure you add ui5-deploy.yaml to add all the BSP, System and TR details.

Build and Deploy the app with the help of below scripts. (can be added to package.json file)

“build”: “ui5 build -a –clean-dest –include-task=generateCachebusterInfo”,

“deploy”: “npm run build && fiori deploy –config ui5-deploy.yaml && rimraf archive.zip”,

Now you have your first Fiori Extension Project built using Business Application Studio.

The post Fiori Adoptation Project for Extending Standard Fiori Application for onPremise using BAS appeared first on ERP Q&A.

https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/#/detail/Apps(‘F0842A’)/S22OP

This demo is mainly for the beginners who are curious to learn SAP Fiori Launchpad Configurations.

Check for the installations under implementation information tab in SAP Fiori Apps Library.

As we all know, we can see for the above installed front end and backend components in gateway system.

Activate the below nodes in SICF and OData Service in n/iwfnd/maint_service

Now open Launchpad Designer using tcode: /n/UI2/FLPD_CUST from gateway system. This opens the browser.

Create a custom catalog.

Open the Technical Catalog: SAP_TC_PRC_COMMON from Fiori Apps Library in Launchpad Designer and create a reference wrt tiles and target mappings to the above custom catalog.

Verify the added tiles and target mappings in the custom catalog:

Create a custom group and select the required tile:

Make sure to capture the Catalog & Group in Customizing TR

You need to have the front and backend roles assigned with the custom catalog and group to your user ID by Security team.

SAP Fiori Launchpad Output:

The post SAP Fiori Standard App configuration in Launchpad: Manage Purchase Orders (Version 2) appeared first on ERP Q&A.

This blog is for SD & MM consultants. This functionality can be used from SAP S/4HANA OP2022 FPS00 version.

What is Advanced Intercompany Stock Transfer

Classic Intercompany Stock Transfer was developed in order to reduce documents between intercompany trading since SAP R/3. However, For audit and IFRS reasons Classic Intercompany Stock transfer is not good enough. So, Advanced Intercompany Stock transfer was developed.

Classic Intercompany Stock Transfer has no Delivery Company’s Sales order.

The Advanced Intercompany Stock transfer has Delivery company’s sales order also.

3 Create a Purchase order manually

4 Create a Sales order automatically by Value Chain Monitor (VCM)

5 Create a outbound delivery order manually

6 Post GI for Stock transfer to SiT manually (Or TM, EWM, 3PL)

6′ Create inbound delivery order automatically by VCM

A Create a billing document to receiving company manually

7 After the internal planning due, Create material documents automatically by VCM

8 Stock transfer to 1010 manually (Or TM, EWM, 3PL)

B Create supplier invoice automatically by VCM

Pre-requisite

SAP S/4HANA OP2022 FPS00 or upper version. Fiori server must be installed.

Customize Hints:

Advanced ATP should be used.

IMG>Cross-Application Components>Advanced Availability-to-Promise (aATP)> Configuration Activities for Specific Document Types>Stock Transport Orders>Configure Delivery Type & Availability Check Procedure by Plant

IMG>Materials Management>Purchasing>Purchase Order>Set Up Stock Transport Order>Define Shipping Data for Plants

IMG>Sales and Distribution>Billing>Intercompany Billing>Define Internal Customer Number By Sales Organization

IMG>ABAP Platform>Application Server>System Administration>Activation of Scope-Dependent Background Job Definitions (Tr-CD: S_YI3_39000188)

Tr-CD: SJOBREPO

You can customize the job.

Master

Business Partner

Business partner for Receiving company

Price

Receiving company’s Internal purchase price and Sending company’s Internal sales price should be exactly same. Otherwise, the internal invoice verification will fail.

Intercompany Purchase Order

Intercompany Billing document

Operation

Execute “Create Purchase Order Advanced” Fiori Apps or TR-CD:ME21N

Set Purchase Order Type, Supplier and Purchase Organization.

Set “0004 Inbound Delivery” as the confirmation Control

Internal Seles order is created automatically by VCM

Create an outbound delivery by “My Purchase Orders Due for Delivery” Fiori Apps or Tr-CD: VL10B

Set the shipping point.

Push “Execute” button

Check the purchase order

Push “Background” button

GI by “My Outbound Delivery Monitor” or Tr-CD: VL06O

Set the Shipping Point

Push “Execute” button

Check the outbound delivery

Push “Post Goods Issue” button

Push “Continue”

Success message

Good Issue for OD into SiT (GIOD) Movement Type 681

Created inbound delivery document automatically by VCM

Create a Billing document by “Create Billing Documents” Fiori Apps or TR-CD: VF01

Check the out bound delivery document and push “Create Billing Documents” button

Created the billing document as a draft

Push “Save” button

Push “Post Billing Document” button

Monitor the Advanced Intercompany Stock Transfer” process by “Monitor Value Chains” Fiori Apps

Crick the leading purchase order document and push “>” button

Crick “i” button

Job schedule is the internal transfer control data

After coming the job due date, subsequent material documents were created automatically.

You can do GR posing manually for the inbound delivery document by “Inbound Deliveries for Purchase Orders” Fiori Apps or Tr-CD: VL32N

Push “Post Goods Receipt” Button

The business process was finished.

Post GI from Issuing SiT (GIIV) Movement Type 685T

Post Goods Receipt to Receiving SiT (GRRV) Movement Type 107

Post Stock Transfer into Physical Stock (GRID) Movement Type109

Supplier Invoice

The post Advanced Intercompany Stock Transfer in SAP S/4HANA OP/Private Cloud appeared first on ERP Q&A.

As you already aware regarding the Payment Proposal Workflow in SAP Finance, earlier it was triggered from SAP GUI and the decision whether it should be approved or rejected, this action was performed from SAP GUI itself. However, I came across this solution in S4 with Fiori integration with Payment Proposal Workflow.

In this solution, once the workflow is triggered from SAP GUI, it will be sent to Fiori inbox of the respective Approver. Now from Fiori inbox, approver can review the workflow and accordingly approve or reject the proposal from Fiori itself.

Hence I wanted to share my experience and concept on how this Fiori collaboration with business workflow can be implemented in S4. Hope this blog will be beneficial to everyone.

1. Current Functionality (AS-IS):

Standard workflow WS23200018 creates payment proposal workitem in My Inbox Fiori app with buttons like below. There is no explicit Approve and Reject button. Approvers needed to go to the ‘Open Task’ and approves from there or from SAP GUI. Till now Rejection was not possible from here.

2. Business Needs & Requirements (TO-BE):

As per the business requirement, need to add ‘Approve’ and ‘Reject’ button explicitly in this workitem and Functionality needs to be implemented like below –

1. Once the Payment Proposal is created in SAP, a workitem is sent to My Inbox of Approver with Approve & Reject Button. Once this is sent, a notification mail needs to be triggered to Approver’s outlook mail that a workitem is ready for your approval.
   
2. Once he Approves, a mail needs to be triggered to initiator and a group mail id that this workitem is approved. For this approval, Payment run is processed in background. Once all process is done, a confirmation mail is sent to initiator that the whole process is completed.
   
3. Once he Rejects, a mail needs to be triggered to initiator and a group mail id that this workitem is rejected. Once this is rejected, no payment run will be triggered. Initiator can delete the proposal from F110 and recreate it and send for approval accordingly.

3. Proposed Solution:

• Standard workflow and sub workflow needs to be copied to Custom workflow and sub workflow. Make required changes in custom ones.
  
• Approve and Reject custom buttons will be added for Fiori by setting configuration in SPRO.
  
• A Filter BADI needs to be implemented for these two buttons functionality.

4. Implemented Solution Steps:

Flow Chart of Entire Process –

• Solution Approach: Requirement 1:

Once the Payment Proposal is created in SAP, a workitem is sent to My Inbox of Approver with Approve & Reject Button. Once this is sent, a notification mail needs to be triggered to Approver’s outlook mail that a workitem is ready for your approval.

• Goto F110 Tcode – we create payment proposal

• For this development, we have created custom workflow WS90200005 and subworkflow WS90200006 by coping below standard workflow WS23200018 and subworkflow WS23200017.
  
• Once the proposal is created from F110, a workitem will be sent to My Inbox Fiori with Approve and Reject

To add this functionality, Approve and Reject button to a specific workitem ‘Payment Proposal Processing’ of the sub WF WS90200006, we need to do a settings in SPRO with the Corresponding Task No. and Step No.

Copy this Task no – TS23200014,

Step no – 000053,

Workflow no – WS90200006.

Go to SPRO -> Maintain Task Names and Decision Options -> Follow the below steps

• Save and Activate SPRO.

Now check Fiori Workitem of Approver – Approve and Reject Button is added to workitem.

• Now once this workitem is triggered, a notification mail needs to be sent to approver that some workitem is ready for your approval.

To cater this, we put a Custom mail step ‘Notification Mail To Approvers’ in sub WF WS90200006 just before the workitem creation step. Approver got the mail in Outlook.

• Solution Approach: Requirement 2 and 3:
• Once he Approves, a mail needs to be triggered to initiator and a group mail id that this workitem is approved. For this approval, Payment run is processed in background. Once all process is done, a confirmation mail is sent to initiator that the whole process is completed.
• Once he Rejects, a mail needs to be triggered to initiator and a group mail id that this workitem is rejected. Once this is rejected, no payment run will be triggered. Initiator can delete the proposal from F110 and recreate it and send for approval accordingly.

To implement the Approval and Rejection Functionality of Fiori, SAP has provided a Filter BADI ‘/IWWRK/BADI_WF_BEFORE_UPD_IB’. As we want to activate the BADI only for Payment Proposal decision purpose, we need to put filter condition which would be same as SPRO setting’s workflow and step number i.e.

Workflow No. – WS90200006 and Step No. – 53.

The entire logic for Approve and Reject buttons functionality is written in the config part in the above mentioned BADI.

• For Approval and Rejection, custom mail step is created in sub WF as shown below:

From ‘Payment Proposal Processing’ step, 3 things will be passed to sub WF through binding from Fiori and BADI –

• Decision Key – ‘A’ for Approve or ‘R’ for Reject
  
• Reviewer Name
  
• Attachment – if approver puts any comment during approval/rejection and attach any attachment.

After taking decision, in sub WF it will check the Decision in ‘Check Decision’ step. Accordingly, it will send mail with these Attachments and Reviewer Name.

Here one Attachment of comment and Reviewer name is passed to mail for both Approval and Rejection. Outlook mail will be triggered to Initiator’s mail id accordingly.

• Once Payment run is carried out, a Confirmation mail will be sent to a group of mail ids. This mail step will be added in main WF –

Proposal will be in ‘Confirmed’ status in case of Approval. Outlook mail will be triggered to intended recipient.

• Similarly For Rejection – Mail will be sent to initiator, Sub and Main WF will not be completed. So Payment run will not happen. Proposal will be reopened again.

The post SAP Fiori Collaboration With Finance Payment Proposal Workflow appeared first on ERP Q&A.

Avoid CHANGED. MANUAL by Exception. MAINTAINED is OK. Strive for STANDARD.

For as long as I’ve been building application security roles via transaction PFCG, this is the mantra I’ve followed when maintaining authorisations. Transaction PFCG (Role Maintenance) is integrated with Transaction SU24 (Authorisations Proposals). This integration automatically imports and removes proposals from the role authorisation data based on the items in the role menu.

With the move to SAP S/4HANA and SAP Fiori, managing authorizations effectively becomes more important than ever. Authorizations directly affect the User Experience of your users. Get it wrong and you risk actively degrading UX adoption and reduce the benefits that your users and your organization can derive from these innovations. For example, manually adding transaction code to role will make it unavailable to users in Fiori Launchpad.

An overview of PFCG and SU24 integration

For the most part, transaction SU24 is a build accelerator and is a is considered a best practise for role build as it:

• Reduces access creep: when transactions are removed from the role menu, the associated authorisations proposals are also removed (so long as another menu item doesn’t require them). This benefit only works for standard and maintained authorisation status items.
  
• Reduces authorisations errors: the role will automatically receive the require authorisations for each application so long as the mappings are fully maintained in transaction SU24, and the application has been added to the role menu
  
• Reduces build Effort and time: the security administrators can leverage existing mappings as part of role build and requires less time to map the values out for each role.
  
• Simplifies and Improves Impact Analysis: it makes is easier for role authorisations experts to easily identify why an authorisation is part of a security role. This helps with segregation of duties impact assessment, role clean-up, and regression test prioritisation.

Going back to the mantra –

Avoid CHANGED. MANUAL by Exception. MAINTAINED is OK. Strive for STANDARD.

Why Avoid CHANGED?

We avoid CHANGE as it is a deliberate breaking of mappings and deviates from consistency. A CHANGED status object is treated like a MANUAL object. Transaction PFCG cannot automatically remove a CHANGED authorisation from the role when the transaction is removed as there is not relationship between the data. Therefore, CHANGED objects can increase access creep and make it difficult to properly impact assess or remove the access.

Why MANUAL by Exception?

We accept MANUAL by exceptions. Some authorisations are required but are not mapped to applications items that can be added to a role menu (e.g. S_RFCACL for trusted RFC). Some may be clear design decisions for supplementing an existing role to provide additional authorisation (e.g. purchasing approval codes). These exceptions are clearly documented and less likely to change.

Why strive for STANDARD?

We aim for STANDARD as it meant we had a 100% alignment with authorisation proposals. Assuming SU24 data is accurate, it is unlikely the security administrator team needs to maintain values in PFCG.

Why is MAINTAINED ok?

We accept and settle for MAINTAINED as a balance between mapping what we can in SU24 and avoiding CHANGED status.

Wouldn’t it be great if we didn’t have to settle for maintained? Variants makes this possible.

Common Scenario for MAINTAINED status

Maintained status occurs because we only partially maintained authorisation proposal inside SU24. This is needed when a transaction code belongs to multiple roles with differently underlying authorisations values.

For example, if we had a transaction that provided table maintenance then we would provide authorisation object S_TABU_NAM. This object contains fields Activity and Table Name. We cannot maintain the Activity proposal in SU24 if we need to grant access to users in either display or maintenance mode. However, both roles would need the same Table Name. As a result, we would partially maintain the proposal: Activity field would remain blank, and Table Name would contain the entry.

For example, transaction OB52 provides access to posting periods. Many users may need display access and only a few need to make changes. Within transaction SU24, SAP provides the ACTVT Activity field as an empty proposal which is then maintained at role level.

Within transaction PFCG, we would receive a STANDARD proposal initially that is then set to MAINTAINED once we finish populating the Activity proposals (one role gets display only whilst the other role gets change and display).

Other Scenarios for MAINTAINED status… and where it can get messy

MAINTAINED Status can also be due to:

• SAP Proposal and Upgrades remain unchanged – the customer chooses to leave the default proposals as is and make all necessary refines at role level.
  
• Cockpit Style Transactions – the application has several use cases controlled through combinations of authorisations. The SU24 default proposals remain predominately empty to provide the flexibility to maintain values at role level.
  
• HR Authorisations and transaction – most HR transaction access is controlled through two (2) main objects – P_ORGIN and PLOG. The objects contain fields for activity level, infotype, and enterprise data restrictions. To avoid CHANGE and MANUAL status, these objects are added with empty proposals and all changes are managed at role level.

SAP Proposals and Upgrades

SAP provides default proposals for SAP standard transactions. These values are shipped via transaction SU22 tables and copied across to transaction SU24 tables via transaction SU25 (for greenfield systems, Step 1 is run).

The customer is allowed to make changes to the SAP proposals. Within transaction SU24, you can compare the values in your system against SAP proposals to check if you have deviated from the original.

As part of upgrades, SAP ships new values (changes to existing mappings and mappings for new transactions). The customer uses transaction SU25 Steps 2a/2b to compare customer tables and SAP tables to import changes.

However, for many customers, it becomes a challenge to decide if they should adopt SAP updates on transactions that they have already maintained. Depending on build maturity, it can be difficult to change which proposals are a better fit: SAP’s latest proposals or updates the customer made as part of build refinement.

Some security administration teams avoid making changes to SAP standard proposals. In this situation, it leads to an increased level of CHANGED and MANUAL authorisations – what we’re trying to avoid. However, it makes upgrades a bit easier for the security team to process.

Cockpit style transactions

The transaction is a single-entry point for several functional scenarios and assigned to multiple roles. In this situation, SU24 proposals have a higher incomplete rate and requires individual maintained in each role. Each role requires a different combination of fields values. This level of localisations shifts the build effort to the security administrator as part of role build.

HR Authorisations and transactions

HR authorisation objects control personnel record and organisational structure for infotype access. If you attempt to use transaction SU24 proposals, in most cases you are forced to enter an empty proposal in SU24 as each role requires different values. For example, transaction code PA30 for Maintain Personnel Record requires P_ORGIN authorisations to control activity level, data access, and Infotypes. Several users may need access to the transactions but different functional access. Therefore, P_ORGIN would need to be empty in SU24 and fully maintained in PFCG. It can make it difficult in HR-centric roles to determine why the roles has field values as you cannot determine the context by the role menu items. Often, security administrators resort to manually adding objects instead of attempting SU24 maintenance.

A use case of needing variants in SU24

Using the “cockpit style: scenario, let’s imagine you want to provide users with access to F3163 Manage Business Partner Master Data. This application allows you to access Suppler, Customer, and Employee information and is included in several business role templates. Many users will have a requirement to access the application, but they will need to be restricted to specific data.

Fiori App F3163 authorisation is based on SAP Gateway Service “MD_BUSINESSPARTNER_SRV 0001”. Within SU24, default proposals are provided but they are for maintenance access with no specific limit to business part role. This means without changing the proposal within transaction SU24, all restrictions will need to be at role level. Making changes are role level will result in MAINTAINED, CHANGED, or MANUAL status. Alternately, SU24 can be updated to remove the field proposals and leave empty values to maintain entirely at role level (end up with MAINTAINED only) but that doesn’t a consider different maintenance level (e.g. deletion access may be restricted).

Each time the application is added to a role, the administrator then must make changes. However, SU24 variants can solve this problem and allow you to continue with STANDARD proposals. Within, transaction SU24, a variant is created with the required mapping.

Transaction code PFCG now contains an Application Tab which will list the available Variants for each application maintain. This tab is populated after the role menu is refreshed and SU24 definitions have been read in. In the example below, the options are greyed out as there are no variants to choose between.

Once the variants have been selected, the SU24 proposals are then imported via the Authorisation Tab. Again, in this example there are not variants sot the SAP standard values will be adopted.

The security role administrator will need to work through each authorisation proposal to either set the unrequired authorisations to inactive, complete field proposal, or return to transaction SU24 to make proposal changes at the master data and then return to the role to continue build. However, as this application is used by several process areas (procurement, sales, HR, etc), it is unlikely SU24 proposals will be changed as it impacts all roles. Instead, the proposals will end up in a MAINTAIN or CHANGED status to maintain the required authorisation for the role. Ultimately, you start to lose the benefits of SU24 proposals, or you must remove all proposals in SU24 and maintain everything inside of PFCG.

Finally what are these variants and how to use them

Originally this capability was delivered under a “new” transaction code SU24N but has seen been merged back into transaction SU24.

Transaction SU24 now allows you to create variants of the maintenance proposals. This means you can create multiple proposal versions and control which ones you adopt within the roles.

Within SU24 transaction you can how choose to CREATE VARIANT instead of changed SAP standard proposals for an application. When creating the variant you must enter this in the customer namespace. You can implement a naming convention (such as including Fiori Application Id which can help for context later).

As this is workbench object, you will need to assign it to a transport (no screen shot shown). Once you have created the VARIANT you can start making changes to the proposal data without updating the standard values.

In the case of this application and the context of managing Supplier, you can now switch off authorisation proposals that are not relevant as well as changing the existing proposals for values that are more relevant to supplier master data.

Once you have completed the updates you then save (just like you would have when you made updates to the standard proposal)

Return to transaction PFCG and look and go to the Application Tab. You will now. The SU24 variants are automatically identified based on applications in the role menu.

As a variant now exists, you can choose which on you select for the role authorisation proposals. If there are several variants, you can choose as many as required for the role.

Once you have selected the applicable variant, save the role before you maintain authorisation data again. On the authorisation tab you will need to select Expert Mode for Profile Generation > Read Old/Merge with new to re-read the SU24 values and pick up the VARIANT proposals

You will still be asked to enter the organisational values (or update them if you need to).

The authorisation data will show more STANDARD (green) proposals due to the VARIANT that you maintained

When reviewing the authorisation proposal you will now see which specific variant brought them in.

As mentioned, when creating a VARIANT in SU24, the variant name is quite useful to understand the context. As shown above, the application variant name of “ZF3163_SUP_M” is a basic naming convention for the Fiori App F3163 with variant of Supplier Maintenance. These conventions can make it easier to understand the access context compared to the application Odata service name.

Impacts of Using Variants

The primary benefit of using variants is to allow you to leverage authorisation default proposals from SU24 and minimise overall maintenance of individual permission within the role. The following are benefits I can see in using variant in SU24

• Able to easily handle different access contexts for the same application.
  
• Separate development/maintenance default mappings with security roles team
  
• Reduce access creep and confusion in role build through less direct maintenance of value
  
• Obtain better access context through variant names to better understand reason authorisation proposal within a role
  
• Easily able to add a new variant to an application for another role without having to maintained the existing roles. This can occur when you add an application in design but need to change the SU24. If you update the SU24 data, then you would need to also maintained the existing role and regression test. This further add to your change request and effort. Instead, you can define a new variant just for those values.
  
• Reduce SU25 Step 2a/2b upgrade effort as you avoid maintaining SAP standard proposals. However, you will need to manually assess your variants to decide if you need to add new value proposals that were added to the SAP original
  
• Flexibility to differentiate access proposals for non-production and production access. This can allow security teams to leverage SU24 for project role build for sensitive transactions that would generally be granted in display mode only.
  
• Small win – your can double-click on the variant tab line items of transaction PFCG to navigate to the related transaction SU24 configuration to confirm you have selected the required variant.

The post Getting back to Standard Proposals with SU24 Authorisation Variants appeared first on ERP Q&A.

Customers tell us they are so useful, the temptation for business users can be to create too many views, resulting in some unintended confusion over which view to use. So with SAP S/4HANA 2021 there are new and changed options to bring you greater control over who can create views and who can use views.

TLDR; The new launchpad configuration parameter UI5FLEX_ENABLE_VARIANTS lets you control who can create views and where, including letting users create public views in production. You can see the SAP Help Portal documentation in the SAP Fiori launchpad guide > Administration Guide, and section Launchpad Configuration Parameters. Public views can now be created locally, without requiring a transport. Transportable public views can now be created and assigned to specific roles by key users using Adapt UI.

In this blog post you will learn about the main features of views and how these new SAP S/4HANA 2021 capabilities work. You will learn:

• What’s new for views in SAP S/4HANA 2021
  
• How to use existing views
  
• How to create views – both personal and public
  
• How key users create role-specific views
  
• How to control view options centrally
  
• Where to find out more about views

What’s new for Views in SAP S/4HANA 2021

In SAP S/4HANA 2020 and lower releases:

• All users could create personal views.
  
• Only authorized users could create public views.
  
  • Public views were transportable and required a transport request to be assigned to the user
    
• You could change who was permitted to create public views using SAP Note 2658662 – Configurable key user check for public/shared views (variants)
  
  • From SAP S/4HANA 2021 this note is obsolete.

From SAP S/4HANA 2021:

• You can control whether users can:
  
  • Create personal views and public views, or
    
  • May only create personal views
    
• You can even control whether users are permitted to create views at all, that is restrict them to only using existing views.

IMPORTANT: Both personal and public views are created as local views. Local views are not transportable and do not require a transport request or software collection. Local views are created in the current system/client (in SAP S/4HANA Cloud, Private Edition or SAP S/4HANA On-Premise) or in the current tenant (in SAP S/4HANA Cloud, Public Edition).

There are also some changes in how public views are handled:

In SAP S/4HANA 2020 and lower releases:

• Public views were always transportable. To create public views, you needed:
  
  • The ability to transport the views, for example you needed to be assigned a transport request

From SAP S/4HANA 2021:

• Public views can be created locally in the current system/client
  
  • Public views can be used by everyone
    
  • Public views created locally are not transportable
    
• Key users using Adapt UI, i.e. UI Adaptation at Runtime:
  
  • Can create and save public views that can be used by everyone
    
  • Can create and save public views restricted to selected business roles, i.e. create role-specific views using the Adapt UI feature
    
  • Can set views as the default view for every user who has not yet set their own default view
    
  • Views created using Adapt UI can be transported

These new features give you more control over who can create public views. They also bring more control over which business users will see the public views you have created.

For example, if you have a lot of users and want to avoid too many public views being created, you could:

• In your Sandbox environment, permit everyone to create local personal and public views to try them out
  
• In your Development environment, permit everyone to create personal views and authorize key users to create transportable public and role-specific views.
  
  • You then transport the key user views to your quality/user acceptance testing and production environments
    
• In your quality/user acceptance testing and production environment you could:
  
  • Decide if you want to allow personal views or not
    
  • The only public views would be key user created views

If you only have a few users and they work well together, you may just allow anyone to create personal and public views in all your environments.

Or you may decide on to let your users create public views for a limited time only, and then change your configuration settings back to restrict them to creating personal views.

How to use existing views

Views are specific to an app. Views can be created:

• Dynamically for immediate use but not saved
  
• Saved for personal use as a business user, i.e. Private Views
  
• Saved for use by everyone, i.e. Public Views
  
• Saved for use by people assigned to certain roles, i.e. Role-Specific Views.

As a business user, you can find your views in the My Views dialog in your apps. By default SAP provides a Standard view wherever views apply.

You can use the Manage option to find existing views and add them to your favorites.

You can mark any views you want to see in My Views as your favorites and optionally choose to make a view your default view. You save your changes.

When you see the views in your My Views dialog, you simply select the view to apply it.

How to create views

All apps that use views provide a default Standard view, i.e. the SAP delivered view.

To change the view, you use:

• Adapt filters for Filter bars
  
• Settings (gear wheel icon) for Tables and Charts

Any changes are applied and can be used immediately – without saving.

You can tell you have made a change because a * appears next to the view name indicating the change has not been saved. To save a view you press the View dropdown to access the My Views dialog.

In the My Views dialog you use Save As to save your view.

How to save a Personal View

Personal views can only be seen by you.

Simply give your view a name and save it.

Tip: The Apply Automatically option seen for filter views is the equivalent of saying “and press Go immediately”.

You can optionally make your view your personal default. This means the view is shown immediately, whenever you enter that app. For example, in a list report, such as Manage Sales Orders, you can set your favorite table columns, sort order and grouping by using a table view and setting as as your default view for that app.

Your current view is shown in the views dropdown menu and you can swap between any of your views.

Personal views are always local and cannot be transported.

How to save a Public View

Public views can be seen by everyone.

You follow much the same process as when you create a personal view.

When you name the view you also choose the option Public.

In SAP S/4HANA 2020 and lower releases, when you selected the Public checkbox you would be prompted for a transport request.

From SAP S/4HANA 2021, public views created in this way are local public views and cannot be transported.

IMPORTANT: In SAP S/4HANA 2021, if you want to create transportable views you need to be authorized as a key user.

How key users create role-specific views

To create views for selected roles you must be a key user and have the authorization to use the Adapt UI feature. For example, in SAP S/4HANA on-premise or SAP S/4HANA Cloud, Private Edition you must be assigned the role SAP_UI_FLEX_KEY_USER or an equivalent custom role.

IMPORTANT: Key Users make UI Adaptation changes in the Development environment. Any changes they make are tested before being transported to the Production environment.

Launch the app and go into Adapt UI from the User Actions (Profile) menu on the SAP Fiori launchpad shell bar.

You will get an information message if there are existing role-specific views already created.

In UI Adaptation, swap to the Navigation mode to adjust the filters to the values you want to use and try them out. In this screenshot some additional filters have been added and values have been set. You can see the * in the My Views area showing that the values have not been saved.

Then swap to UI Adaption mode. In UI Adaptation mode when you select the My views drop down you will see the adaptation action Save View As.

Give the view a name. To create a role-specific view, select the option Only for users in specific roles and then choose Add Roles to add the roles.

IMPORTANT: If you choose the option “For all users”, this creates a public view that is transportable.

When creating a role-specific view, you can select and add multiple roles to the same view.

• You can add SAP delivered roles or custom roles.
  
• You can search for roles by name or id.

Once you have added your roles, save the view.

When you select a saved view in UI Adaptation mode, you can see additional actions.

The UI Adaptation features available for role-specific views are:

• Rename – rename the current views
  
• Save View – update the current view
  
• Save View as – copy the current view to a new view
  
• Manage Views – mark views as favorites, nominate the default view
  
• Switch Views – switch to a different view so that you can maintain it

In Manage Views you will see the view visibility is shown as Restricted.

Once you have finished making your changes, in the UI Adaptation tab, press Save & Exit to apply your changes.

IMPORTANT: You can also choose the Save As action to assign your view only to an App Variant. An App Variant is a new version of the current app. To use an app variant, users must be assigned the app variant. That is the app variant must be added to a business catalog assigned to their business role. Tip: If you can’t see the Save As button, look for the “…” more actions menu button.

Saving your adaptations starts the reload of the app and you will see an information message confirming that the role-specific views will be applied.

How role-specific views impact users

Users with one of the specified roles see the restricted view listed in the Manage Views dialog, reached by opening the My Views dialog and selecting the Manage action.

For example, sales managers see the role-specific view assigned to them as a Public view.

Users who have the app but do NOT have one of the specified roles cannot see the view at all.

For example, this Sales Representative user does not have the Sales Manager role, and so does NOT see the role-specific view.

How to control view options centrally

There is a new launchpad configuration parameter called UI5FLEX_ENABLE_VARIANTS that lets you centrally control the behaviour of views in the current system and client.

Because UI5FLEX_ENABLE_VARIANTS is a FLP UI Server Setting these parameters can be set centrally in Customizing.

IMPORTANT: FLP UI Service Settings cannot be set as parameters of target mappings.

Launchpad configuration parameters can be set centrally:

• Client-specific in transaction /UI2/FLP_CUS_CONF (preferred)
  
• Cross-client in transaction /UI2/FLP_SYS_CONF

When UI5FLEX_ENABLE_VARIANTS is set to public – i.e. all users can create both private and public views.

This means in the My Views dialog the Save As action is available.

When you Save As you the option Public is available to create a public view. No transport is required as this is a local public view.

When UI5FLEX_ENABLE_VARIANTS is set to private, users can only create personal views. They are not permitted to create public views.

When you open the My Views dialog, you can see the Save As action.

However, when you press Save As the option to create a Public view is not visible.

When UI5FLEX_ENABLE_VARIANTS is set to none, users cannot create any views.

When UI5FLEX_ENABLE_VARIANTS is set to NONE, the Save As action does not appear in the My Views dialog at all. Users can still select Manage to see existing views that they can use and select their favorite views.

How to transport Views

From SAP S/4HANA 2021, only views created by key users via UI Adaptation can be transported.

You will need to be assigned a transport request to publish the view.

IMPORTANT: In SAP S/4HANA Cloud, Private Edition or SAP S/4HANA On-Premise you can create transport requests using GUI transaction SE09.

When you are ready to transport your view, as a key user you enter Adapt UI mode again and then use the Publish action to add your changes to a transport request. You are recommended to use a customizing transport request.

In SAP S/4HANA on-premise and SAP S/4HANA Cloud, Private Edition, your technical team will find that the transport object type for key user adaptations saved to a customizing request is R3TR LRST. Your transport team will standard ABAP transport management system to manage the transport. That is, you release the request to push the transport through your system landscape.

IMPORTANT: You should NOT the program /UIF/WRITE_TRANSPORT_ENTRIES to transport layered repository contents. This is a support tool intended for SAP support only in exceptional circumstances only.

WORTH KNOWING: In SAP S/4HANA Cloud, Public Edition the transport process is slightly different.

• Instead of a transport request you use a software collection.
  
• When you press Publish your key user changes are automatically added to your assigned collection
  
• To transport the changes, as an Administrator, you use the SAP Fiori app F1433 Export Software Collection to release the collection in your source environment and SAP Fiori app F1432 Import Collection to import the changes into your target environment
  
• You can find out more about this approach in the guide Extend and Integrate your SAP S/4HANA Cloud

Where to find out more about Views

For developers, wanting to implement views in their custom apps, look for topic Managing Variants in the SAPUI5 SDK documentation.

***Hint:

In this blog post the screenshots were taken in a SAP S/4HANA 2021 FPS0 system.

The examples were performed using:

• a test user assigned the SAP Business Role Internal Sales Representative, or
  
• a key user with the same role, plus the security role SAP_UI_FLEX_KEY_USER.

The test user was generated using the task list SAP_FIORI_CONTENT_ACTIVATION.

The post SAP Fiori for SAP S/4HANA – New options for managing Views for filters tables and charts appeared first on ERP Q&A.

The motivation behind this question is usually a role design approach where display roles are built for each functional area. In this design approach, security teams attempt to provide users with a “display all” capability for their functional area to avoid future support requests for ad-hoc reporting requirements. Users will automatically receive the display role relating to their functional area as part of their system access. Confidentiality requirements may sometimes necessitate several levels of display access, but the idea remains the same: if the app is read only or can be restricted to read only then it is added to the display role.

I’ve always been a proponent of this role design approach. Building “display only” roles allow us to:

• Provide display only access easily to a broad user base
• Provide the ability to downgrade access organization-wide to display only (e.g. to support certain time periods for a business processes when maintenance is not allowed)
• Provide support and super user access to allow display access to production without requiring Firefighter or temporary elevation of privileges
• Provide auditors with easy access to see what is happening in an area
• Reduce duplication of application access (less security build restrictions, regression tests, etc) as several user populations receive the same display access
• Easily identify the correct security role to assign a user (i.e. if the access only exists in one role then the answer is easy)
• Reduce change requests on security team to provide Adhoc reporting and display access

Hint: Manage apps are typically marked in the SAP Fiori apps reference library as Application Type = Transactional and UI Technology Type = SAP Fiori elements. They typically use the SAP Fiori elements floorplan “List Report” or “Worklist”.

The SAP ECC Days with Classic UI transactions

In SAP ECC system transactional access had two main patterns.

Pattern 1: A transaction code was allocated for each Activity to an object (e.g. transactions FI01 through to FI03 provide Access to Create, Maintain, Display of Bank Master Data). As security administrators, most times we could deduce the access level based on the transaction code (01 Create, 02 Change, 03 Display, etc).

Pattern 2: The other pattern would be one transaction code to provide access to an object. Within the transaction, action buttons would allow for different activity levels (e.g. transaction FS00 to Maintain GL Accounts). Manage Apps in SAP Fiori operate a bit like this scenario – single entry point that with several buttons to control the actions.

In the “build a display role approach” for the examples above, transaction codes FI03 (Display Bank) and FS00 Edit G/L Account Centrally would be granted and all underlying authorisations restricted to display only. Transaction FI01 and FI02 would most likely be assigned to a Finance Master Data Role.

Creating display only roles with SAP Fiori “Manage” apps

In SAP Fiori, it’s not quite as simple. “Manage” apps is an example of how the User Experience (UX) paradigm can conflict with this (potentially outdated) security design approach:

• SAP Fiori Apps may be based on a consolidation of several UI classic applications together (e.g. FI01, FI02, FI03 Create/Maintain/Display Banks are now a single app Manage Banks)
  
• Action Buttons may be available regardless of the user’s authorisations
  
• Fiori Application authorisations checks are not evaluated until a user performs an action that triggers a call to the backend.
  
• From a security authorisation point of view, transaction SU24 data (where authorisation proposals for applications is maintained to simplify role build) most likely assumes maintenance level access. You will need to change several default proposals to streamline your security role build.

In relation to authorisation checks, this can be quite frustrating for the user to take the time to enter or maintain the data only to receive a message at the end advising them of lack of access. The ability to enter edit mode may cause unnecessary alarm and incidents amongst business users who are concerned access has not been appropriately restricted.

From a UX standpoint, Fiori Launchpad has been built with usability in mind and application tiles are not the only access pathway to meet the original intent of the ECC “display only” use case, i.e. to provide the user with display level access to the master or transaction data.

Example: SAP Fiori App F1366A Manage Bank Accounts in Display Mode

Manage Banks Accounts (BankAccount-manageMasterData) supersedes classic UI transactions for Create Bank (FI01), Maintain Bank (FI02), Display Bank (FI03). The SAP Fiori app provides a 1-stop shop for all maintenance activities of the Cash Manager. The app has been designed to fit with the needs and tasks of the Cash Manager. If you were to use the SAP Business Roles as delivered, only the Cash Manager is assigned this app.

But what happens if you give this app to other users – who are not Cash Managers – and who only need to display bank information? Although the user is restricted to display only authorization, they can still view and press the create button and Fiori opens a new record to complete.

The user may invest time to enter the required information then presses save.

This can be considered bad user experience and will cause incidents as users complain of lack of access or concern, they have inappropriate access assigned. From a strict SAP Fiori role-based perspective, this should not happen, because the app is not intended for use by other users needing display only access and should not be assigned to anyone who is not a Cash Manager.

Better ways to provide display access in SAP Fiori

The easiest way to provide users access to display access is via Enterprise Search. This will let users search for the object using keywords and wildcards. For example, search for banks by name or code.

The search results bring them summary details of the object. For example, for banks you can see details such as bank name, bank country, bank key, SWIFT code, and several other fields.

If the user is only permitted to see the summary details the main id – in the example the bank name – is a flat text.

If the user is permitted to see more complete details, they can also be assigned the related Object Page (technically this is done by assigning the associated target mapping for the displayFactSheet semantic action). This converts the main id to a hyperlink to the object page. For example, clicking on the bank name takes you into the bank object page.

This approach allows users to get to the data faster and avoids assigning the original app.

Users must be authorised to the user the search and have the target mappings to open the App to view more details. If the user has the required target mapping, they can click on the hyperlink and navigate directly to the underlying Fiori App to view the search results.

This solution deviates from the ECC security approach but may meet the user’s true requirement. User who are not responsible for managing master data are less likely to need a master data list of all records. In most cases, they may be attempting to find a specific record based on known information. Enterprise Search is the better fit. Taking this approach finds the right balance between UX and security.

Technically: Object Page (action=displayFactSheet) apps can also be assigned to user as a tile on their launchpad and allow direct entry. Or the user can bookmark their favourite bank to their entry page using the Save as tile icon.

Again, this would be a better UX and security approach.

Even so, you may still have a use case to provide the Manage App in Display only mode

Ask yourself if the access is to meet a business requirement or a security design requirement? If it’s a security design requirement (i.e. all “display” in a display role) then you may want to reconsider the role design approach for display access.

In most cases, Enterprise Search or an alternative Fiori Application will provide users with their requirements. It won’t, however, support the traditional security role design approach of putting all display level access into a role.

Use the in-app extension ADAPT UI to provide a Display only App Variant

The final scenario is where there is a use case to provide the app as read only. The common scenarios here are for Support Users or System Auditors.

ADAPT UI in SAP Fiori allows the Key User to create an App Variant of the Manage App. Who is this key user? Whoever you designate to create the app variant. For example, the key user could be a Fiori configuration expert, subject matter expert, Functional expert, Security, or dedicated UX expert, or even a central process governance team.

This Key User must be authorised to execute the ADAPT UI option in your development environment, for example by being assigned the security role SAP_UI_FLEX_KEY_USER.

When you enter the app In UI Adaptation mode, you can remove the action buttons, and save an app variant into a transport request.

Buttons can be removed or relabeled. For example, Initiate Review Process, Create Document, Create Bank action buttons have been removed. Import and Export Bank Accounts has been renamed to Export Bank Accounts.

Hint 1: If renaming, you then need to check if the navigation target requires another App Variant to also limit it to display.

Hint 2: You may also need to navigate into a record to check for additional action buttons as shown below (click on the bank results to get to the details screen where you have additional action buttons like copy, send closing request to bank, manage attachments)

Buttons such as Copy, Send Closing Request to Bank are removed and Manage Attachment is changed to View Attachments.

Once all the adjustments have been made the App Variant is defined.

On Save, an app variant Configuration Id is generated and provided.

To assign the app variant to your display only users, the app variant id must be added to a new Fiori Application definition in a technical catalog, and then to a Fiori Catalog and security role. To make the target mapping unique to the app variant, make sure you assign different semantic action to the original app. You should assign it to the same Semantic Object so you can find it easily, and so that it can be used in existing dynamic links such as search results, Related Apps buttons, Smart Link dialogs, and jump-to options in analytics.

In the end state solution, the user can access the Display version of the app. In App Finder, Display Bank Account App appears.

The user clicks the App and the App will open as Display Bank. It is a variant of Manage Bank without action buttons related to maintenance.

ADAPT UI will provide users with the App. The main shortcoming is app-to-app navigation. Users will not be able to navigate from one app back to the original “manage” app as they will not have the target mapping assigned. Therefore, it is so important to use the same Semantic Object to maximize availability in dynamic links.

The post Converting a SAP Fiori “Manage” app to a Display Only using Adapt UI appeared first on ERP Q&A.