Tell us what you think

We want to create the best possible experience for our learners. Your feedback helps us to improve the experience for everyone.

Explaining Defense Replenishment and Fulfillment

Objectives

After completing this lesson, you will be able to:

Explain the process requirements of stock and fulfillment based on AAC Results
Explain the concept of Condition Code
Explain the concept of loans
Explain the manual and automated Return Delivery

Stock Requirements and Fulfillment: Overall Process

The picture shows the process flow from the results of AAC (Authorized-Actual Comparison) planning to the goods receipt at the requesting unit.

The image shows a process flow diagram with two main components: Requesting Unit (Customer) and Supplying Unit (Supplier). The Requesting Unit starts with an AAC (Authorized Accounting Code) and follows a process of Proposal Based on AAC, Purchase Requisition, and Goods Receipt, ultimately leading to Material available. The Supplying Unit follows a process of Purchase Order, Delivery, Picking, and Goods Issue. The overall diagram depicts the procurement process between a customer and a supplier.

While the AAC can be run by the customer unit or by a responsible planning authority, the request is typically raised by the customer unit (the owner of the authorization). It is then processed by an authority with responsibility to supply the item nationally or regionally, such as an item manager, category manager, supplying unit etc. Upon a positive outcome of this processing, the request will turn into an order.

Delivery is an actionable object in a logistics supply center, where steps such as picking, packing, loading and goods issue can be performed. Our minimal scenario only shows picking and goods issue.

Once the goods are issued from the supply center, they will be in transfer until a goods receipt is processed by the requesting unit.

In the following, we will show how to create a Purchase Requisition (of the type Stock Transfer Request) based on the AAC results

The image depicts a process flow diagram showing the interactions between a Requesting Unit (Customer) and a Supplying Unit (Supplier) in a procurement process. The Requesting Unit starts with an AAC (Authorized Accounting Code), followed by a Proposal Based on AAC, a Purchase Requisition, and Goods Receipt, leading to Material available. The Supplying Unit receives a Purchase Order, then follows a process of Delivery, Picking, and Goods Issue. The overall diagram illustrates the procurement flow between the customer and supplier.

The Authorized-Actual comparison finds a gap in Rifles. There is no Stock on-hand, but in the Details of Authorized-Actual Comparison you can see that the existing requisition is attributed to one of the authorization assignments.

The image displays a comparison table in an enterprise software system, showing details about various force elements and their associated information, such as Variant, Adjusted Authorized, Actual, Ordered, Requested, Installed, Issued to Personnel, Material Indicator, and Storing Location. The table includes items like assault rifles, weapons, and vehicles, with their respective authorization and actual quantities. The overall image represents a management interface for tracking and comparing military equipment and resources.

The image displays detailed information about the 111th Tank Battalion/ASSAULT RIFLE 5.56mm in an enterprise software system. It shows the Variant, Ordered Quantity, Requested Quantity, Adjusted Authorized/Actual, Material Indicator, and Doctrinal Authorization (DCTRN) for this force element. The image also includes sections for Accompanying Parts, Models, and Products related to this specific military resource. The overall view provides comprehensive details about the management and tracking of this force element.

In the details of Authorized-Actual comparison, one can trigger creating a requisition based on the AAC

The image shows a Create Purchase Requisition interface in an enterprise software system. It displays various fields for entering information related to the purchase requisition, such as Receiving Element, Plant, Storage Location, Supplying Element, Plant, Storage Location, Material, Batch, Open Quantity, Delivery Date, and other details. The interface appears to be part of a procurement or inventory management system.

Stock Requirements and Fulfillment: Warehouse and Distribution Processing

The requisition is now processed by an authority with responsibility to supply the item nationally or regionally, such as an item manager, category manager, supplying unit etc. Upon a positive outcome of this processing, the request will turn into an order.

The image shows a process flow diagram depicting the interactions between a Requesting Unit (Customer) and a Supplying Unit (Supplier) in a procurement process. The Requesting Unit starts with an AAC, followed by a Proposal Based on AAC, a Purchase Requisition, and Goods Receipt, leading to Material available. The Supplying Unit receives a Purchase Order, then follows a process of Delivery, Picking, and Goods Issue.

There are several ways to convert a Purchase Requisition into a Purchase Order

R transaction /ISDFPS/DSP1
FIORI App Manage Purchase Orders

The image shows a procurement interface in an enterprise software system. The main section displays a list of purchase requisitions, with details such as Delivery Date, Text, Purchase Items, Quantity, Unit, Batch, Material, Material Description, Request Priority, Request Urgency, Acct Asst, Plant, and Plant Description. Below the list, there is a message indicating that a purchase order with the number 4500000051 was created successfully.

Stock is missing and create notes.

In "NCG Planning Workbench", transaction code /isdfps/dsp1, the item manager sees a list of work items (open requisitions to be satisfied) and can review the inventory of sullying FE to support the decision whether to fulfill the request, reject it or forward to another sullying FE.

The remaining steps in the fulfillment process are not specific to D&S and are performed using standard SAP Fioris/ work environments.

The conversion of an order into an outbound delivery is typically performed as a background job
Picking (as well as optional Packing, Loading) are Delivery-Processing steps in the supplying unit's warehouse
Goods Issue can be performed as a last step of an outbound delivery processing to document the handover of the items from the supplying unit's warehouse into distribution (stock-in-transfer)
Goods receipt will be performed in the requesting unit's warehouse to document the handover of the items from stock-in-transfer into the receiving warehouse.

The image shows an enterprise software interface for creating outbound delivery from a purchase order. It displays fields for entering Shipping Point/Receiving Point, Delivery Creation Date, and Calculation Rule Delivery Criteria. The interface also has sections for Purchase Orders, Material, and User Role, as well as an Add Criteria - Stock Transport Order feature. The second part of the image shows an Activities Due for Shipping view, listing details such as GI Date, Ship-to, Route, Originating Doc, Gross WUN, and Volume VUn.

Transaction codes VL10B, VL10D can be used to create a delivery from an order. The delivery is used to facilitate the work in the outbound warehouse.

The image depicts the processing of an outbound delivery in a Supplying Unit Warehouse within an enterprise software system. The main interface displays options for Change Outbound Delivery with sections for Document Flow, Overview, Header Details, Pack, and Post Goods Issue. The lower part of the image shows the Replenishment Div. 80000026 Change: Overview interface, which includes details like Outbound Delivery, Ship-to-Party, Picking, Loading, Shipment, and Goods Movement Data. The interface also provides access to various Services for Object related to the outbound delivery process.

Outbound delivery is processed in the delivery unit's warehouse to pick the items (serialized) and potentially pack and ship them.

The image depicts an Authorized/Actual Comparison (AAC) interface in an enterprise software system. The interface displays details related to the Goods Receipt process in the Requesting Unit, including information such as the Standard, Key Data, Force Element, Force Element Status, Evaluation Area, RRPO, Usage Type, Assignment Status, and Material Index. The main comparison table shows details like Variant, Adjusted Authorized, Actual, Adjusted Authorized (Subst.), Ordered Quantity, Requested Quantity, and Status for the material received.

Once the requesting unit received the goods into its Stock Element, you can see it appear under the Actual column in their AAC report.

Concept of Condition Code

To allow better inventory visibility and management of material usability, materials inventory may be separated by Condition Codes
In SAP for Defense, it is possible for a material to be:
- Batch Managed without Conditions
- Condition Managed without Batches (the batch is one-character long designating only the condition)
- Both Condition and Batch managed (the first character of the batch is the condition and the rest are vendor batches)

The image depicts an enterprise software interface for product comparison. The main section displays details about a 111th Tank Battalion/PISTOL 9mm product, including its accompanying RRPO, Model, and Serial Number/Equipment Details. The lower part of the interface shows a table with various equipment details such as Product, Equipment, Plant, Storage Location, Serial Number, and Batch. The image also contains a diagram with three categories: New, Used, Intact, and Require Laundry, Require Mending.

Armed forces are required to manage non-consumable materials pertaining to different levels of usability. While in a large distribution center it is possible to map the usability levels by dedicated storage locations, such a solution is not feasible for tactical-level logistics. It is therefore needed to be able to differentiate a few levels of usability within a single storage location.

Features:

Definition of the condition code as well as an initial condition per condition code in customizing
Batches (and therefore stocks managed with condition codes) are created when goods are received, but this can also be done at later stages
Transfer postings between conditions can be done (e.g. from "operational" to "non-operational")

Configuration tip:

In Material Master Data, Info on Condition Management can be found on Tab Page "Plant Data / Stor. 1". Batch Management needs to be enabled, and one of the options of Condition Management is to be selected.

In Configuration of DFPS/D&S → Materials Management → Condition Code, the condition codes list can be maintained, as well as whether the batches created by the condition codes are considered restricted or unrestricted inventory.

Reverse Logistics: Return Delivery

The image depicts a logistics process flow diagram, highlighting the relationship between Forward Logistics, Replenishment, Return Process, Reverse Logistics, and Return. It includes two related military equipment images - an assault rifle and a night vision device. The diagram shows a circular flow, with Forward Logistics leading to Replenishment, which then connects to the Return Process, Reverse Logistics, and finally back to Return.

To establish a controlled returns process, one can use a reverse Requisition/ Order: Return Delivery. Return Delivery can be manual or automated:

Manual Return Delivery: can be used to return excess or no longer necessary material from the tactical level units back into Supply Units. It can be initiated by either the Supply Unit or the Tactical one.
Can be created using SAP Fiori GUI transactions in S/4 HANA D&S
Automated Return Delivery: is a background creation of Return Delivery when a tracked item is being issued from the supply unit to a requesting one. It facilitates a 1-1 exchange between the supply unit and the requesting one.
Automated Return Delivery is Based on Material Master and Customizing settings for Return Process

A typical use case for using automated return delivery is to request serviceable material and on goods issue automatically trigger a return of the unserviceable material.

Depending on system configuration, the return request will be produced automatically in accordance to a certain goods movement type.

Hence it is possible to create the return request automatically either on:

Goods receipt of the serviceable material in the unit or at
Goods Issue of the serviceable material in the warehouse

Return Delivery Processing

Disband Force Element App can be used for the Return Process.

Transfer Posting

A typical use case for using automated return delivery is to request serviceable material and on goods issue automatically triggers a return of the unserviceable material.

Depending on system configuration, the return request will be produced automatically in accordance to a certain goods movement type.

Hence it is possible to create the return request automatically either on:

Goods receipt of the serviceable material in the unit or at
Goods Issue of the serviceable material in the warehouse

Automated Return Delivery

Typical Process: Ask for a new item from a depot and return the faulty item from the unit.

The image depicts a typical process for replacing an unserviceable item with a serviceable one. The process includes the following steps: Change condition code of the unserviceable part, Create Requisition for a serviceable material, Create Purchase Order (STO), Create Outbound Delivery, Goods Issue, Goods Receipt of serviceable, and Automatically created return ST-Preq for the unserviceable item.

A faulty item will be put into condition code F (unserviceable) by movement posting. The automatically created return delivery requisition features the unserviceable condition code (configuration depending).

The image depicts a document overview interface in an enterprise software system. The main table displays information related to purchase orders, including Quantity, Unit, Material, Plant, Storage Location, and other details. The table provides a comprehensive view of the purchase order data, allowing users to manage and process the orders effectively.

In this document sequence, the automatically created return delivery can be seen as the last document. The date of the return requisition is set as the date of the Goods Issue of the new/ intact rifle from the supply unit. The batch of the return requisition reflects an unserviceable condition code.

Loans

The image depicts a process flow illustrating the transfer of equipment between two parties. On the left, there is an icon representing equipment we borrowed. In the middle, there is an icon labeled Our SLoc indicating an intermediate storage or processing step. On the right, there is an icon representing equipment we loan to the other party. The flow is visualized through yellow arrows connecting the left, middle, and right icons.

Loan

Is a temporary transfer of equipment (that is SN) or Material (that is quantity) between units
Can be done with or without transfer of ownership

Equipment from a loan can be used like any other asset of the unit owns

Can be issued to people
Can be maintained

Equipment Accountability in AAC Report

A loan does not create a new gap at the contributing unit
A loan does not create an excess at the gaining unit

Loans are a variant of Defense Replenishment process. Although there is no such restriction, the typical usage is when both the borrowing and the loaning unit are tactical level (consuming units). A loan requisition must be marked as such on the original request.

Loan Process Cycle

When a Purchase Requisition is defined as a loan, the system creates a return PREQ in the background.

When a loan requisition is converted to an order, a return requisition is created automatically. The return requisition generates an expected receipt for the issuing force element and an expected issue for the receiving force element.

The image depicts a process flow for managing the lifecycle of loaned equipment. The process consists of four main stages: Loan Planning, Loan Execution, Use of Loaned Equipment, and Return Planning and Execution. Each stage involves specific activities such as creating a loan purchase requisition, goods issue to the loan STO, maintenance and dispatch of the equipment, transforming the loan return, and goods receipt from the loan return STO.

Loan Workflow

A loan request from another unit is a type of request that triggers a future return:

Workflow of the loan process:

The image depicts a validation process for equipment loan requests. It shows that the loan request is converted into a stock transfer order, and the AAC (Authorized Approving Coordinator) must return the same result in the loan period as before the loan. Additionally, the return request is automatically created.

Fulfillment of the loan request and the return is the same as for any other request for NCGs

Typically a loan request is raised against a stock element, not a provisions element (=> a unit lends its own equipment).

A loan is usually not transferring maintenance responsibility to the receiving unit.

Loan Process doesn't influence Authorized / Actual Comparison:
- Loan Purchase Requisition not taken into account as "Planned" quantity
- Loan Purchase Order taken into account as "Converted" quantity, but balanced by Return Delivery Purchase Requisition (Loan), created automatically in the same process step ("Planned" quantity)
The requester asks another unit for a material and specifies the date for the material return
At the time a loan request is converted into a stock transfer order, a return request is also created automatically. In essence a stock transfer request is created switching requester and supplier from the original request including the return date.
For the loan transaction, the authorized/actual comparison must return the same result in the loan period as before the loan.
The loan has no impact on AAC when the request is turned into stock transfer order, because a return request is created.
Different Document Types used for Loan Purchase Requisition, Loan Purchase Order and Return Delivery Purchase Requisition (Loan) than those used for respective documents during standard process for Material Request / Return Delivery process

Fulfillment of the loan request and the return is the same as for any other request for NCGs.

The Manual and automated Return Delivery

A comparison of the features of Automated Return Delivery and Loan Process.

(Automated) Return vs. Loan Process

Return Process	Loan Process
Intact material is required as a substitute for defective material Defective material has to be sent back in exchange for the intact material Determined by return code (material master) Return purchase requisition created at goods issue time at the supplier Return date equals the goods issue date	Material is only temporarily requested. A loan request can be determined by loan identifier and return date assigned to purchase requisition Return delivery purchase requisition created when original purchase requisition is converted to a purchase order. Return date already specified in original purchase requisition.

The Manual and Automated Return Delivery

When creating a loan requisition, one needs to mark it as such and specify the return date.

The image shows a create purchase requisition form in an enterprise software system. It contains various fields such as Receiving Element, Plant, Storage Location, Supplying Element, Plant, Storage Location, Material, Batch, WBS Element, Open Quantity, Delivery Date, Return Date, Regent Urgency, Advice Code, and Status Code. The form also includes options for Loan and Change of Ownership.

Example: Typical process for an initial supply.

The image depicts a flow of steps for assigning Field Equipment (FE) with Flexible Maintenance Planning and Operations (FMPO) variants, which are initially supply relevant. The steps include: Assigning the FE with FMPO Variants, validating that the initial supply was not executed yet, triggering initial supply, specifying required urgency and usage of supply relationships, and creating purchase requisitions for the FMPOs that are initially supply relevant.

Initial Supply is designed to be executed once, when the Force Element is established or is reallocated into a mission. Hence, controls exist in place to make sure the Initial Supply is not executed again for the same Force Element and FMPO assignment.

Once consumed, the follow-on supplies are designed to be non-D&S specific (e.g. MRP)

FMPO-Variant Assignment Information : Initial Supply

The meaning of "Relevance for Initial Supply" is that there are product ACPs for that FMPO.

The image explains the concept of Initial Supply Relevance. It states that if the FMPO-Variant is relevant for Initial Supply, the planner can define whether it will be provided to the Field Equipment (FE) itself or sent to the Supplier based on Supply Relationships. The image also shows an Assignment Information section with various fields such as Quantity, Minimum Quantity, Maximum Quantity, and an Initial Supplies section where the Initial Supply Relevance and Initial Supply Status of Material can be defined. Additionally, it explains that the Initial Supply Status of Material is a system indicator whether the initial supply has already been activated.

The image shows a SAP screen for the Initial Supply of FMPOs and Products. It displays the Element Awaiting Supplies section, which includes fields for Force Element, Delivery Date, Assignment Date, Requirement Urgency, Evaluation Path, Include Lower-Level FEs, Maintain at the Supplier, and Use Supply Rel. The values for the Force Element, Delivery Date, and Assignment Date are highlighted in red, indicating they have been entered.

First run in "Test Mode" to check if everything works and no error messages appear. Then run with the check-mark removed → the Initial Supply is executed, the system generates a Purchase Requisition Number from the associated FMPO´s of the Force Element.

Evaluation path helps selecting subordinate Force Elements and their authorizations. Requirement urgency is used similarly to the Urgency in Stocks Requesting.

An exception scenario exists to enable initial supply even for Force Elements without the ability to store provisions - by sending them to the supplier's warehouse to be withdrawn by the requesting FE.

Next lesson