sexta-feira, 1 de maio de 2020

Receipt & Reversal of Handling Units from Production with Restricted Batch Using Radio Frequency

Receipt of Handling Units from Production( Document Type INBM)

This blog will explain how from RF receipt of Hus and its reversal can be conducted for Advance Production Integration.
Assumption:
  • All mandatory configuration of Advance production integration
  • Master data is set up
  • Batch management is set up
  • RFUI is set up
The receipt of HUs from Production line using RF is a process by which goods receipt process at the end of production line is automated.
In the below example, points will be discussed
  •  Generation of restricted batch with Production date and BBD

  • Generation of Hus with RF

  • Generation of Inbound delivery in S4 Embedded EWM( No Expected Goods receipt)

  • Create & Confirm Warehouse Task from RF

  • Create a manufacturing order in ERP with goods receipt in EWM managed sloc. The product is batch managed with batch status management is active both in ERP and EWM. The initial status of batches is ”Restricted” is activated in OCHA and in EWM  warehouse task creation with ”Restricted Status” is configured at warehouse process type level.

  •  Logon to RFUI.
  • Scan the product
  • Create the HU( Receiving 1 HU from production )
  • Create Inbound delivery from RFUI.

  • Restricted Batch with Production date and SLED is generated. Restricted batch in EWM is marked as X.

  • Create Warehouse Task



Reversal of Handling units. 
If below condition is met, HU cannot be reversed.
  • The putaway of the HU to the final bin is already complete.
  • The HU is currently not in a bin and is not a planned HU.
  • The HU has multiple stock items in it, or the stock is not directly in the HU.
  • The stock in the HU refers to a quality inspection document that is released and cannot be canceled.
So, only those HUs can be reversed whose HU WT is not confirmed.
Try to reverse the above HU 8001000082.
— >Business context  RVS Reverse Receipt, in Customizing for Extended Warehouse Management under Start of the navigation path Cross-Process Settings Next navigation step Exception Handling Next navigation step Define Exception Codes End of the navigation path. The exception code must have an internal process code and a process code to reduce inbound delivery quantities upon reversal of the HU. DIFR



  • Process code has reduced the inbound delivery

  • Business Context RVS ,Exception code DIFF and the corresponding Process code I001 initiate the process of HU reversal by adjusting the Warehouse request.

  • Inbound delivery has reference of Process code


  • Try to conduct reversal of HU which is already Putawayed. System will not allow to do reversal of HUS.



  • Now, finally do the whole process again to conduct put-away.


  • New IBD is created.

  • Conduct WT creation and Confirmation

  • Check the delivery status now

  • Check Manufacturing Order in ERP

  • Check the Stock status with Batch Status in ERP and In EWM


  • EWM monitor Stock


Hence the blog end. Appreciate your suggestions and improvements to make this blog more useful


Best regards
Shailesh Mishra

SAP Fiori for SAP S/4HANA – Adaptation Transport Organizer

As member of the SAP S/4HANA Regional Implementation Group, I have the privilege of working with a lot of customers who are implementing SAP S/4HANA. Many of our SAP S/4HANA customer are looking to use in-app extensibility tools – Why? Because this is the easy, cloud-first, no-development-tools-needed way to extend your SAP S/4HANA solution, and particularly your SAP Fiori apps for SAP S/4HANA. This blog post is a summary of detail steps for setting up Adaptation Transport Organizer, which is a pre-requisite for using in-app extensibility.
In-app extensibility covers the most common changes most customers need to make to their SAP S/4HANA solution, including:
  • Adding custom fields to the database for use in SAP Fiori apps, SAP GUI transactions, forms, emails, etc.
  • Adding custom cards and filters to Overview Pages
  • Hiding unwanted fields, cards, and features from all users or from specific roles
  • Rearranging fields, field groups, and cards to make the most important fields for your specific business process more prominent
  • Presetting favorite navigation links, etc.
In-app extensibility changes are intended to be made by key users.  Who are key users? Whoever you authorize to make these changes on behalf of other business users. Because in-app extensibility does not require developer skills or developer tooling, your key users could be business process experts, or a central process governance group. Since these are the people who understand the business requirements behind these changes, it makes sense that they can make these changes for themselves.
NOTE: Of course, your key users could also be developers wanting to use in-app extensibility as the most efficient way to extend your SAP S/4ANA solution.
In-app extensibility options are inherited from SAP S/4HANA Cloud and the SAPUI5 technology to SAP S/4HANA AnyPremise solutions.
You can find out more about common patterns for in-app extensibility in the SAP Extensibility Explorer at https://sap.com/extends4

Here is the summary of steps covered in this blog post:
  1. Motivation and setting up Adaption Transport Organizer
  2. How to Configure Software Packages apps
  3. How to Register Extensions for Transport
  4. Monitoring your extensions in the Extensibility Inventory

1.    Motivation and setting up Adaption Transport Organizer

Adaption Transport Organizer is a pre-requisite for in-app extensibility.  In-app extensibility changes are typically made in your development system and need to be transported through your system landscape environment.  Since these changes are made by key users, who may not have development skills, the Adaptation Transport Organizer simplifies this process for key users.
The transport of key user extensions is managed by the Adaption Transport Organizer (ATO). Extensibility for key users is deactivated by default in the SAP S/4HANA on-premise edition. To activate it, you run SAP GUI transaction S_ATO_SETUP.
Usually, after running transaction S_ATO_SETUP you will see the status “NO”
This simply means your ATO is not yet configured. Before you start to activate it, you will need to understand the possibilities.
  1. You have to choose whether you want to use a prefix or a namespace for your packages and transports.
For example:
Prefix – your object will be called ZZ1_<Generated Object Name> and can be transported to your production system.
Sandbox Prefix – your object will be called ZZ9 _<Generated Object Name> and must not be transported to your production system, only used for local sandbox objects.
Namespace – your object will be called /YOUR_NAMESPACE/<Generated Object Name>
  1. Define a local and a sandbox package where the extension items will be stored.
For example, in a SAP S/4HANA 30-day trial system the local package is called “TEST_YY_KEY_USER_LOCAL” and the sandbox is called “TEST_YY_KEY_USER_SANDBOX”.  In your case you will need your package names to follow the naming guidelines explained in the from SAP Help Portal guide General Functions for Key Users, and within that the section Configuration Information: Adaptation Transport Organizer.
Just keep in mind that the package names $YATO_KEY_USER_LOCAL and $YATO_KEY_USER_SANDBOX, are examples and all packages starting with “$” are deleted during upgrades. You can check the details in SAP Notes 2478895-ATO Package Lost in Upgrade.
Both local and sandbox packages are assigned to the software component “LOCAL”.
Now you are ready to press the button “Setup with specific data” and your ATO will be configured and you can access on the SAP Fiori launchpad extensibility apps and transportation apps for key users.
Transaction S_ATO_SETUP provides a few additional options, so here is some quick information to help you understand them:
Setup read only – Key user extensibility will be configured, but only in read mode.
Setup with default data – this action will set up the ATO with default values provided by SAP.
Lock – the ATO is locked and the extensibility apps and transportation apps are locked for key users.
Unlock – the ATO is unlocked and change, create, or transport extension items is activated.
Registration User for Job – you can register a job user, who will take care of the generation of artifacts. Job user needs the roles and authorizations required for artifact generation authorization object S_DEVELOP.  With this option you can reduce roles and authorizations for key users as generation is done with job user. Registration is done via Maintain Table view ATO_PK_JOB_USER.
Delete Setup – the configuration will be removed.

2.    How to Configure Software Packages

How do you transport extensibility items, if your local package is not assigned to a transport layer? That is the reason why you have to create a new software package that will be assigned to Transport Layer. The software package can be created in transaction Object Navigator SE80 or Package Builder SE21.
Example via SE21
Next step is to use the SAP Fiori app F1590 Configure Software Packages. This app is part of the security roles SAP_NW_APS_EXT_ATO_PK_CFG_APP, which need to assign to your User ID.
You can check details at SAP Fiori apps reference library
Logon to your SAP Fiori system follow steps:
  1. Choose Configure Software Packages app
  2. Select “Add Registration”
  3. Search for your package and select it
  4. Press OK button
So now within the Configure Software Packages app, the software package Z_ATO_DEMO is registered. The app allows you to assign a specific transport request to the registered package by selecting the transport request and then activate Automatic Task Handling.  Alternatively you can ask your administrator to manually create a task for your user in an open transport request via the transaction SE01 or SE09.
If Automatic Request Handling option is activated, then also the option Automatic Task Handling is activated and transport request and tasks are managed by system.
Now you are ready to create the extension items and publish it.
You can see very nice blog posts from my colleague Masaaki Arai How to add a field in standard Fiori apps and other objects by using Custom Fields menu in Key User Extensibility Tools Custom Fields and Logic

3.    How to Register Extensions for Transport

Your final step is to register the extensions for transport using SAP Fiori app F1589 Register Extensions for Transport. This app is part of the security role SAP_NW_APS_EXT_ATO_PK_AI_APP, which need to assign to your User ID.
You can check the details in the SAP Fiori apps reference library
Your roles assignment should be like this, or you can use an equivalent customer-specific security rules.
Logon to your SAP Fiori system and follow these steps:
Search for SAP Fiori app Register Extensions for Transport for Administrator and click on it.
Now you will get an overview of extensions that are available for transport, check the current status of assignment and reassign extensions.

4.    Monitoring extensions in the Extensibility Inventory

You can monitor the extensions created in your system using the SAP Fiori app F2587 Extensibility Inventory.
As before, to see this SAP Fiori app in action you will need the relevant authorizations.
This app doesn’t have any standard SAP security role which can be assigned to your User ID, so you have to assign to your security role / business role (PFCG) the Business Catalog (and optionally the business Group to add the tile to your Home Page). You can find the names of the business catalog and business group can be found in the SAP Fiori apps reference library
Logon to your SAP Fiori system and follow these steps:
Search for Fiori app Extensibility Inventory and click on it.
Now you will get an overview of your extensibility items and to see all details. Pay particular attention to columns Uses or Used By, which provide information about extensibility items that the extensibility item in question “uses” or is “used by”.

You can go to SAP help, where you will find a video overview explaining the Transport process.

Becoming a SAP Fiori for SAP S/4HANA guru

You’ll find much more on our SAP Fiori for SAP S/4HANA wiki
Brought to you by the S/4HANA RIG

terça-feira, 21 de abril de 2020

Let’s talk SAP S/4HANA AnyPremise Upgrade

Are you one of those early adopters who implemented SAP S/4HANA and are now starting to reap its benefits in terms of lower TCO, improved processes and performance, and increased business productivity? Or are you among those who are currently in the process of adopting SAP S/4HANA (whether it’s a short sharp few months system conversion, or a multi-year business transformation program)? Regardless of the phase of SAP S/4HANA journey you are in, you will have thought about what happens during an upgrade for one reason or another.
You recognize that having upgrades in the roadmap will position your organization to continue to get the most from its SAP S/4HANA investments. This blog post offers resources to help you define an upgrade strategy for your organization, including:
  • Why upgrade – driving factors for business and technical upgrades
  • Which target version
  • When to upgrade
  • How to upgrade
You will find a list of further related resources at the end of this blog post.

Why upgrade

The need to upgrade an SAP S/4HANA platform can stem either from your Business or IT departments or both.  Those identified needs will determine the scope as well as the approach to the upgrade namely – functional and technical upgrades.  You will find it helpful for upgrade planning to understand the key driving factors for both types of upgrade.

Driving factors for functional upgrades

Innovations, new features and improvements that help realize business value by demonstrating return on investment is usually what drives the business need for an upgrade. As a result, there is also significant functional rework that happens in this type of upgrade with redesign of business processes.  This approach enables customers to take advantage of latest innovations using intelligent technologies such as predictive analytics, AI, machine learning and robotic process automation. This is typically called a functional upgrade.
The SAP S/4HANA What’s New Viewer is a great resource to explore the new, changed and deleted features and functions at a high level of all versions and feature packages of SAP S/4HANA when evaluating the upgrade potential.
You can review the video series: The Power of SAP S/4HANA for some examples of the latest new value of SAP S/4HANA 1909 in action.
You can also get some great starting points for discussion with business stakeholders via the SAP Fiori lighthouse scenarios (regularly updated), which highlights apps with the best new business value for specific lines of business.
With more and more solutions and functionalities being embedded and enhanced with each release of SAP S/4HANA, upgrade provides the option to activate such functions for customers who can benefit from them. For example: the embedded SAP TM solution was made available in SAP S/4HANA 1709 and enhanced in subsequent releases, see this blog article for details.
This means that alongside the new possibilities of your target SAP S/4HANA version are new process simplifications that need to be assessed.  So, you will need to factor the time for assessing these simplifications into your upgrade planning.
Simplification Item Catalog provides descriptions of all potentially relevant changes that help analyze and mitigate the impact of an upgrade. The Simplification Item (SI) Check Report – which is based on the content in the Simplification Item Catalog – performs checks directly on the source SAP S/4HANA system to determine relevant simplification impacts and what preparations are needed before the upgrade can start by using the usage data of that system. SI check report also provides functional teams the visibility of any functional impacts from additional simplification items. The catalog will only list all the simplification items from source to target release but the SI check report will also display relevant ones based on customer usage.
NOTE: Over time, as more areas are simplified, the number of additional simplifications to be assessed in each new SAP S/4HANA version will reduce. However, for those currently on lower releases such as SAP S/4HANA 1511, the number of simplifications to assess between source release (1511) and target release (1909) is already considerable.

Driving factors for technical upgrades

The key driving factors for the IT department are to stay current with corrections and security patches and to simply stay at a supported version dictated by SAP S/4HANA maintenance schedule. This technical upgrade approach will help improve performance and simplify the architecture.
Upgrading also provides significant improvements in SAP S/4HANA User Experience in:
  • Increased SAP Fiori coverage (new apps, new features in existing apps)
  • New SAP Fiori features (new launchpad options, new automatic features in floorplans, such as export to spreadsheet in many SAP Fiori elements apps)
  • New classic UI capabilities when launched from SAP Fiori (touch-enabled user interfaces for Web Dynpro ABAP applications and GUI for HTML transactions)
  • Performance (improvements in both SAP Fiori and classic user interface technologies).
This blog post from my colleague Hannes Defloo at the SAP S/4HANA RIG explains SAP Fiori upgrade scenarios in detail

IMPORTANT – understanding SAP S/4HANA Maintenance Schedule:

SAP S/4HANA releases follow the yearly innovation cycle and have a five-year Mainstream Maintenance phase after which they enter into Customer Specific Maintenance phase.
This year, 2020, marks the first year where an SAP S/4HANA release will fall out of support with S/4HANA 1511 mainstream maintenance expiring on the 31st December of 2020, reference – SAP Product Availability Matrix (PAM). Customers who are still running S/4HANA 1511 are strongly advised to start planning the upgrade sooner than later.
Mainstream maintenance for every subsequent release will end the years following 2020.
Usually, there is a direct upgrade path available from one release to any other subsequent release as long as the releases are in mainstream maintenance. Depending on technological constraints, an upgrade to a release that is several releases beyond a customer’s current release may have to be performed in more than one step.


Which target version

SAP recommends that you always upgrade to the latest SAP S/4HANA version whenever possible, which is 1909 at the time of writing this article.
In addition to achieving the upgrade objectives, getting to the latest release helps ensure supportability and reduces maintenance costs.  Occasionally an upgrade to the latest version may not be possible when pre-requisites are not met. For example, due to a partner add-on that is not yet certified with the latest version (see footnote for link to SAP certified solutions directory), or due to the timing of the overall project.
The Feature Package Stacks (FPS) and Support Package Stacks (SPS) should also be considered when putting together the upgrade strategy. FPS is similar to SPS but may come with non-disruptive, non-mandatory features that you may be interested in. FPS/SPS upgrade on the same base version is usually of lower impact compared to the release upgrade.
A general recommendation is to aim for FPS01 or higher on any SAP S/4HANA release, for the simple reason that SAP aims FPS01 at the long-term maintenance SAPUI5 version, e.g. SAP S/4HANA 1909 is aimed at SAPUI5 1.71.  SAPUI5 is the underlying technology for SAP Fiori for S/4HANA components. So, aiming for FPS01 or higher minimizes the need for upgrading of these SAP Fiori components prior to your next SAP S/4HANA upgrade.
The other important point to keep in mind when planning the upgrade is the version interoperability within the SAP S/4HANA solution landscape. Upgrade dependencies with individual systems connected to the SAP S/4HANA and the underlying SAP HANA database version should be carefully analyzed. Certain application components deployed in the central hub mode such as SAP Fiori for S/4HANA, SAP MDG on S/4HANA should always be simultaneously upgraded to the same version as the S/4HANA system. Other SAP NetWeaver systems used as central hubs in the landscape, for example, SAP NetWeaver PI and SAP NetWeaver Business Warehouse are not required to be upgraded if the underlying SAP NetWeaver release is at least 7.3 (SAP note 2251604).
Once the justification and approach for the upgrade is established, the next logical questions are when and how.

When to upgrade

Putting a maintenance schedule in place to upgrade the SAP S/4HANA platform on a regular basis is essential because of the business upgrade and technical upgrade reasons mentioned above. Determining the right timing to upgrade is important, as waiting too long can increase support costs, future upgrade costs, and effort to assess both new simplications and new opportunities.

How to upgrade

A good starting point to prepare is by going through the SAP S/4HANA upgrade guide – link to the target 1909 version is available in footnotes. There are two phases to the SAP S/4HANA upgrade process, the prepare phase and the realize phase applicable for all target releases and feature packages. Some important checks are performed in the prepare phase to ensure a smooth execution of the upgrade procedure in the realize phase. These include checks on source system requirements, business functions and add-ons status checks, and simplification item checks.
PLEASE NOTE: If you need to minimize your upgrade window, near-Zero Downtime Maintenance (nZDM) and Zero Downtime Option (ZDO) for SUM are available for SAP S/4HANA upgrades but with some restrictions and limitations – see SAP notes shown in the picture below for more information.
Execution of the upgrade is only half the work in an upgrade project. A testing strategy that covers regression, system integration, and UAT scenarios depending on the scope of the upgrade needs to be put in place to ensure project success.
As a best practice, it is always recommended to run the first full cycle of upgrade on a Sandbox environment that is a recent copy of the Production system.

Upgrading SAP Fiori for SAP S/4HANA

SAP Fiori is the way business users consume the new value of SAP S/4HANA. At the time of writing this article, there are over 1700 SAP Fiori apps delivered out of the box, plus many 1000s of classic UIs (GUI transactions, ABAP Web Dynpro applications, and Web Client UIs) that can be launched from SAP Fiori launchpad.
For this reason, if you did not deploy SAP Fiori in your initial implementation of SAP S/4HANA, you are strongly recommended to deploy SAP Fiori with your first SAP S/4HANA upgrade.
If you are already using SAP Fiori, you can assess the delta of new apps between your target and source SAP S/4HANA releases using the SAP Fiori apps reference library, and/or search on keyword Fiori in the SAP S/4HANA What’s New Viewer.  In addition, you can still use the SAP Fiori Apps recommendation report to discover and deploy apps relevant to your current GUI transaction usage.
If SAP Fiori is already being used and your SAP Fiori frontend server is deployed in hub mode, it is advisable to consider moving to the recommended embedded mode of SAP Fiori for SAP S/4HANA as part of the upgrade. Useful links to blog articles is provided in the footnotes section.

Conclusion

With mainstream maintenance phase for older SAP S/4HANA releases ending and innovations being delivered on a regular basis through releases and feature packages, now is the time for customers to plan ahead and create an upgrade strategy to move to a newer release of SAP S/4HANA. The upgrade should be viewed as an opportunity for getting one step closer to becoming an intelligent enterprise rather than a necessary inconvenience.

Related resources:

SAP Certified Solutions Directory – http://www.sap.com/sapcertifiedsolutions
2214409 – SAP S/4HANA: Compatible Add-Ons – https://launchpad.support.sap.com/#/notes/2214409
Review the video series: The Power of SAP S/4HANA for some examples of the new value – https://blogs.sap.com/2019/09/20/video-series-the-power-of-sap-s4hana/
Simplification Item Catalog – https://launchpad.support.sap.com/#sic
How and why to upgrade SAP Fiori for your SAP S/4HANA solution – https://blogs.sap.com/2020/03/13/how-and-why-to-upgrade-sap-fiori-for-your-sap-s-4hana-solution/
SAP Fiori Frontend Server transitioning from standalone to embedded mode – https://blogs.sap.com/2019/10/25/sap-fiori-transition-from-standalone-to-embedded-deployment-in-sap-s4hana/
2251604 – Version Interoperability between SAP S/4HANA On Premise Edition and SAP NetWeaver Systems – https://launchpad.support.sap.com/#/notes/2251604
SAP Fiori Apps Recommendation Report – gives recommendations based on past GUI transaction usage – https://sap.com/far
1678565 – Prerequisites, Terms and Conditions for nZDM/SUM – https://launchpad.support.sap.com/#/notes/1678565
2707731 – Prerequisites and restrictions of Zero Downtime Option of SUM for SAP S/4HANA – https://launchpad.support.sap.com/#/notes/2707731

Brought to you by the S/4HANA RIG