Segregating Warehouse Responsibilities

Segregating Warehouse Responsibilities using standard Inventory Management and Warehouse management authorizations

 

Background/Situation

 

In certain situations there can be a requirement to separate logistical processes in a SAP system on a detailed level.  This is usually the case when different parties are responsible to perform different logistical processes and / or are responsible for different parts of the same warehouse. 

 

Examples of the situations where the requirements could occur are:

• A third party executes logistical activities and manages a part of the  plant and warehouse.  In these parts of the plant and warehouse this third party is responsible for the stock.
• ‘Special’ materials are stored in certain parts of the warehouse and should only be handled by a certain set of users.

 

This separation in responsibilities can be depicted in SAP by setting up different plants and warehouses that can subsequently be authorized on. But these solutions would mean a redesign of the logistical landscape and additional administrative activities would be needed during day to day operations.  Avoiding this redesign and administrative burden would require effective authorization restrictions on organizational elements lower than plant and warehouse. The requirement of controlling who executes IM and WM processes on a detailed level can be met using standard SAP authorizations in combination with IM/ WM customizing without setting up additional plants and warehouses.  This blog discusses this solution for segregating warehouse responsibilities. 

 

Content of this blog

 

This blog explains when this solution can be used, when it should not be used, how it works and what it can and cannot do.  It also gives an overview of the activities that need to be performed to implement the solution. The solution is based on my own investigation and experience, but also information from several notes, knowledge base articles and threads was used and combined to create a complete solution.

 

The solution and when to use it

 

You can use the solution when you need to differentiate between different groups of users who can perform IM /WM activities within parts of the same plant and warehouse.

 

The SAP SAP WM customzing and  authorization elements ‘storage location’ and ‘storage type’ form the basis for the solution. By properly defining the WM customizing authorizing on the authorization elements  them you can:

• Restrict IM movements based on storage location  to certain groups of users ( next to the normal restriction on movement type and plant)
• Ensure that ‘allowed processes ’ are  defined in WM customizing ( like storage type search settings ) so during WM processes users that needs to execute them are not hampered by authorization checks
• Restrict ‘manual’  WM movements based on the ‘source’ and ‘destination’ storage type to certain groups of users (next to the normal restriction on warehouse and WM movement type)

 

By authorizing on these two elements (storage location and storage type), you can create an authorization setup that only allows users with certain roles to perform specific IM and resulting WM movements for specific storage locations and restrict who can make ‘manual’ WM movements for specific storage types. In this case ‘Manual’ WM movements refer to transfer orders that are not triggered by an IM movement or other specific Logitical actios. For example the transfer orders of the movement type 999 that can be created manually via transaction LT01.

 

With such an authorization setup only the party that is responsible for the storage locations and storage types can keep control over the movements of stock located there while normal ‘Allowed’ warehouse processes are performed in a regulated manner and are not hampered by authorization restrictions.

 

When not to use it

 

Only use it when there is a hard requirement that these restrictions are enforced by the system. Implementing and maintaining the solution (for WM) can be complex.  If there is no hard requirement to enforce these restrictions in the system on such a detailed level don’t do it. In case checking if procedural agreements are adhered to is sufficient do not use authorizations for it.  It also makes no sense to put in effect restrictions in SAP if there are no physical restrictions as well.  if SAP blocks a user from moving materials from one part of the warehouse to another but there is no physical  restriction ( like a locked door or a fence) the person can still just move the materials and not register it. 

 

Prerequisites

 

Before this solution can be implemented a number of things need to be clear. If these aspects are not clear the solution cannot be implemented correctly and will only work partly or not at all.  The following must be determined:

• Ownership of all Storage locations
• Ownership of all Storage types
• Clearly defined logistical processes
• Which party executes which steps in these process

Combined ownership of storage locations and storage types should be avoided as much as possible as this will complicate and can (partially) undermine the solution. Where ever possible ownership of storage types for interim bins have to be determined as well.

 

The concept

 

Inventory Management

 

When an IM movement is made an authorization check on plant and movement type is executed. If the user is not authorized the movement cannot be made. By settings made in customizing a subsequent check can be activated whenever a movement is made for a certain storage location. This customizing switch is set per storage location. By default this customizing setting is off.   When this customizing setting for a storage location is activated it will trigger an authorization check for the combination of movement type, plant, storage location ( and of course activity)  whenever a IM movement is made using this storage location. The authorization object checked is M_MSEG_LGO.  See also SAP Knowledge Base Article 1668678.

 

So by only granting the roles for a certain party with the storage location/plants they are responsible for in combination with the movement types they are allowed to perform the required segregation in responsibilities can be made.

 

When a storage location to storage location movement is made both the ‘Source’ and ‘Destination’ storage locations are checked in case the customizing check is set for both storage locations. This would mean that a movement betweens storage locations ‘owned’ by different parties is blocked by authorizations. In those cases a ’two –step’ storage location to storage location movement can be made wherein the sending party executes the first step and the receiving party executed the second step. See also SAP note 205448.   

 

Warehouse management

 

The solution for warehouse management is more complicated and is based on the SAP WM Customizing like the concept of storage type search (strategies).

 

Authorization check for all transfer orders:

 

During the creation of a TO an authorization check on Warehouse is performed in all cases (Field LGNUM of object L_LGNUM).  At that point no check on Storage type is performed (LGTYP is checked with DUMMY) See also Knowledge base article 1803389. In case the user is not authorized for the warehouse the TO cannot be created

 

Authorization checks in relation to WM customizing:

When a transfer order is created, SAP will try to determine which storage type to pick the material from (source) or which storage type to put this material (destination).

 

To determine where to pick from SAP checks if it can find a suitable source storage type for removal by searching in the ‘storage type search’ table defined in WM customizing.  This search uses a number of variables like reference movement type, warehouse, pick strategy indicator in the material master and special stock indicator to find a suitable storage type. In case a suitable source storage type is found and used in the transfer order no extra check is performed.

 

The same method is used to determine the storage type to put away the material. In that case a suitable destination storage type is searched for in the ‘storage type search’ table in WM customizing.   In case found no extra authorization check is performed.

 

In a lot of cases WM movements are triggered by logistical activities like IM movements.  Under normal circumstances  the ‘storage type search’ WM customizing is properly defined for the logistical process , the necessary material master data is setup and the TO can be created without issues and without needing explicit authorization for the source or  destination storage types. This because it is an ‘allowed’ process and as such the extra authorization checks are not needed.

 

In case no suitable source or destination storage type is found in the  ‘storage type search ’ table and the user creates the transfer order in the foreground the user can enter a source or destination storage type manually. In that case and extra authorization check is executed.   This check is on the combination of Storage type and Warehouse.  The same object _LGNUM is used, for this check but now the field LGTYP is not checked with DUMMY but for the storage type (see FORM BERECHTIGUNG_LGTYP of include FL000F00).

This check is performed because the entered storage type is not found as a suitable storage type in the search strategy (see include LL03AF6I). This check on object L_LGNUM is executed separately for the destination and source storage type.   Also when the users creates the transfer order in the foreground and changes the source or destination storage type into a storage type that is not part of the applicable ‘storage type search ‘ table entry this extra authorization check on the source and / or destination storage type is executed.  See also Knowledge base article 1803389. A thread that also mentions this is https://scn.sap.com/thread/775605

 

Using what is explained above this extra authorization check can be used to restrict the deviations that a user can make compared to the ‘allowed’ processes that are defined in the WM customizing.  By only granting authorization for the storage types the user is responsible for the user can only make deviations to these storage types. This can be considered technically correct as the stock located there is under this user’s responsibility.

 

Authorization checks for ‘manual’ transfer orders

 

Some WM movements can be created manually and are not triggered by other activities like IM.  For instance transaction code LT01 to create a TO manually can be used. Normally these movements are WM supervision movement types like 999 .  Not all WM Movements can be created manually. Which WM movement types can be used to manually create TO’s depends on customizing.  For all movements that are created manually an authorization check on WM movement type in combination with Warehouse is executed. The object that is checked is L_BWLVS.  Also the general check on warehouse is executed.  During the creation of manual transfer orders the concept of ‘storage type search’ and authorizations also applies. By not setting up ‘storage type search‘ customizing  for those movements the extra authorization check is always executed.  By only providing authorization for the storage types s users can only move stock between these storage types they control using these ‘manual’ movements

 

Conclusion:

1. By restricting the access on IM level (movement type, plant and storage location) or other actions that trigger a Transfer order the authorization for the subsequent WM Movement  is restricted as well. If the user has authorization for the action with this the user also has authorization for the subsequent TO, but the manipulation of the storage types the material is picked or put away can be restricted to those defined as applicable in the storage type search (WM customizing) and those that are controlled by the authorization of the user (using roles)
2. The manual WM movements can be restricted based on movement types and to those storage types  that are controlled by the user’s authorizations (using roles)

 

What it cannot do

 

Warehouse management:

 

No authorization check on storage type is performed when a TO is confirmed. The Warehouse is checked but the storage type is not checked (Object L_LGNUM with DUMMY). This means that anybody with authorization for the warehouse and confirming any TO can confirm a TO for that warehouse. There is no way to restrict on storage type during TO confirmation using standard SAP.  Because a Transfer order needs to have been created in order for it to be confirmed and the creation of the TO is controlled this gap is not crucial for the solution. Also the storage type cannot be altered during confirmation.

 

Inventory Management:

 

In almost all situations a material document will contain a storage location.  There are however a few situations where a material document does not contain a storage location. This is when a goods receipt is performed and the materials are consumed upon receipt. This happens for instance if a PO has a cost center as account assignment.  You must determine if these situations are relevant and if this gap is relevant for your situation.  If for example goods receipts are always performed by one of the parties then only one of these parties should have the authorization to do goods receipts. Although this party could potentially do a goods receipt while the PO erroneously contains a storage location which is not ‘owned’ by this party they can still do the goods receipt. This will not be an issue as they are responsible for all goods receipts.   In case multiple parties need to be able to perform goods receipts for different storage location you can include an authorization check (on e.g. the storage location in the PO) using BADI MB_CHECK_LINE_BADI.   This is however not standard SAP.

 

How to set it up

 

Inventory Management:

The more easy part is the authorization restriction for Inventory Management.   This can be done in four steps:

 

1) Activate the check on storage location:

 

Activate the check on object M_MSEG_LGO in customizing (menu path “Materials Management –> Inventory Management and      Physical  Inventory –> Authorization Management –> Authorization Check for Storage Locations”) See also SAP Knowledge Base        Article 16686

 

    

 

2) Make storage location an organizational level:

Use program ‘PFCG_ORG_FIELD_CREATE’ to make the field LGORT an organizational level. See SAP note 727536

3) Update SU24 for relevant transaction codes:

All transactions that create, change or display IM movements need to be updated to have object M_MSEG_LGO set as ‘proposed = Y’  so that the object is populated in PFCG during role maintenance.

4) All roles that contain these transactions need to be updated to contain the M_MSEG_LGO object with the right plants, storage locations, movement types, and activity.  Important to know is that the check on M_MSEG_LGO is also performed when a material document is displayed. This means that also roles that provide display access to material documents ( like MB51) need to be updated to include the authorizations with activity ‘03’

 

Warehouse management

 

Setting up the solution for warehouse management is a more tricky part and consists of three steps:

 

1) Set up all necessary storage type search strategies to cover ALL ‘allowed’ processes:

 

Stock removal and stock placement storage types search entries have to be setup in WM customizing for all ‘allowed’ processes for which no additional authorization check on storage type is needed.

 

2) Make sure that the necessary master data (material master data etc) is set up correctly so that the correct storage type search can be found and used during ‘allowed’ processes

3) Update the roles:

All roles that contain the object L_LGNUM need to be updated so that they contain the authorization for the storage types belonging to the parties they are for. Please note that the object has no activity field and that some display transactions related to WM check on this object as well with DUMMY for the field LGTYP.

What to consider during implementation

 

Please keep in mind the below aspects in order to successfully deploy this solution:

1. WM storage type search (strategies/sequences):  All ‘allowed’ scenarios must be covered by stock removal and stock placement strategies else authorization checks on storage type will be triggered which can fail because the user is not authorized while he/she should be able to perform the step in the process. Considering there are many variables involved there are many strategies to be maintained.  Having the processes clear and involving a specialist in SAP WM is essential in order to cover everything needed.
2. Material master data:  In order for SAP to find the correct storage type in the ‘storage type search’ table the material master data fields like stock placement and stock removal strategy indicators need to be set correctly. This is crucial for the solution to work.  As there are a lot of material master records this can be quite some work. Most issues after introducing this solution will most probably be because of the incorrect or missing material master WM data.
3. Training (of key users): especially the WM part of the solution can be complex. Training of (key) users is important in order for them to understand the concept and to find the right solution when goods ‘get stuck’.
4. (temporary) Super role:   It can be very useful to (temporarily) have a sort of ‘super user ’ role available that can make transfer orders between storage types handled by different parties ( including those for dynamic bins). This can be done by granting this role authorization for all storage types or by creating a WM movement type that has search strategies for all storage types and granting access to that movement type. By assigning this role to a limited number of key users during the first phase after go-live a work around is available when a material movement gets ‘stuck’ while a real solution ( like material master data ,  WM search strategies of authorization roles changes) are being investigated and followed up.