BRD-STORES2-Orders-Receipts-Invoices-v0.2.pdf

Defense Logistics Agency

FedMall

STORES 2.0 ORDER MANAGEMENT (ORDERS, INVOICES, RECEIPTS)

Business Requirements Document (BRD)

Version 0.2 - DRAFT

Document Date: August 9, 2023

DLA FedMall/STORES 2.0 - Business Requirements Document (BRD) Version: 0.2 - DRAFT

STORES Order Management (Orders, Receipts, and Invoices) 2

Table of Contents Table of Contents

Executive Summary

Scope

Requirements

Orders

Activity: Create Order Key Learnings from Requirements Discovery BPR Opportunities

Activity: Validate Order Key Learnings from Requirements Discovery BPR Opportunities

Activity: Resolve Order Creation Issues Key Learnings from Requirements Discovery

Activity: Create & Send PO or Requisition Order File Key Learnings from Requirements Discovery BPR Opportunities

Activity: Export Order Key Learnings from Requirements Discovery BPR Opportunities

Activity: Modify Submitted Order Key Learnings from Requirements Discovery

Activity: Cancel Order Key Learnings from Requirements Discovery BPR Opportunities

Activity: Receive Order Key Learnings from Requirements Discovery

Activity: Confirm Receipt of Order Key Learnings from Requirements Discovery BPR Opportunities

Receipts

Activity: Create Receipt Key Learnings from Requirements Discovery BPR Opportunities

Activity: Validate Imported Receipt Key Learnings from Requirements Discovery

Activity: Resolve Receipt-Related Issues Key Learnings from Requirements Discovery BPR Opportunities

STORES Order Management (Orders, Receipts, and Invoices) 3

Activity: Submit/Transmit Receipt

Key Learnings from Requirements Discovery BPR Opportunities

Activity: Adjust Receipt Key Learnings from Requirements Discovery BPR Opportunities

Activity: Export Receipt Key Learnings from Requirements Discovery

DLA Troop Support Problem Resolution Processes Late/Missed Deliveries Not In Stock (NIS) Issues Quality Issues

Invoices

Activity: Create Invoice Key Learnings from Requirements Discovery BPR Opportunities

Activity: Reconciliation Key Learnings from Requirements Discovery BPR Opportunities

Activity: Mismatched Invoice Lines Key Learnings from Requirements Discovery BPR Opportunities

Activity: Receipts without Invoices Key Learnings from Requirements Discovery Key Learnings from Requirements Discovery

Activity: Transmit Invoice Key Learnings from Requirements Discovery

Activity: View Invoice Information Key Learnings from Requirements Discovery BPR Opportunities

Activity: Resend Invoice Key Learnings from Requirements Discovery

Appendix A: STORES Customer Direct & DLA Direct (Depot) Order Flow

Appendix B: STORES Cargo Lift Freight (CLF) Order & Receipt Flow

Appendix C: STORES Customer Direct Receipting Flow

Appendix D: STORES DLA Direct Receipting Flow

Appendix E: Customer Direct Invoicing Flow

Appendix F: Order Adjustment Flow

Appendix G: Order Cancellation Flow

Appendix H: Invoice Reconciliation Process in STORES

STORES Order Management (Orders, Receipts, and Invoices) 4

Appendix I: Non-Standard Distribution Fees

Appendix J: Inbound and Outbound Interfaces & Transactions

Appendix K: Frequently Used Acronyms

STORES Order Management (Orders, Receipts, and Invoices) 5

Executive Summary STORES (Subsistence Total Order and Receipt Electronic System) is the ordering hub for the Defense

Logistic Agency’s (DLA) Subsistence supply chain. Built, updated, and enhanced over the course of several decades to support Subsistence’s unique business requirements, STORES provides customers across the globe with 24/7 access to over 550 catalogs where they can order a variety of food and beverage items, including fresh produce, packaged and canned goods, MREs, and operational rations.

STORES is comprised of the following modules:

• STORES MIS

• STORES Web

• STORES Admin

• STORES Catalog

• STORES Recon

This Business Requirements Document (BRD) covers the STORES ordering, receipting, and invoicing functional areas, which fall under the current-state STORES Web and STORES Recon modules. The intent of the Business Requirements is to provide stakeholders with a consolidated readout of all business requirements and learnings captured by the Integrated Product Team (IPT) during requirements discovery.

The business requirements for STORES 2.0 were reviewed, discussed, and expanded on over the course of several months during IPT working group sessions conducted over MS Teams. The weekly working group sessions for orders, receipts, and invoices started on March 7, 2023, with the last regularly scheduled meeting ending on July 6, 2023.

Where applicable, this document includes relevant background information and context for the requirements. It also identifies opportunities to modernize and improve processes, features, and capabilities in the buildout of the future-state system (STORES 2.0).

The following requirements documents are companion documents to the BRD:

• Functional Requirements Document (FRD)

While the requirements in the BRD focuses on why the system must support certain processes, functions, and capabilities, the requirements in the FRD will detail how the system will support those processes, functions, and capabilities.

The FRD will serve as an agreement between the implementation team (FedMall, Partnet, Amyx) and the business stakeholders (STORES PMO, DLA Troop Support) where the implementation team agrees to provide the capabilities defined in the FRD and the client agrees to find the product satisfactory if it does. Completing the FRD will require continued collaboration and input from the STORES business and technical team members, FedMall PMO, and the FedMall implementation team (Partnet and Amyx).

• Requirements Traceability Matrix (RTM)

The RTM is a spreadsheet of all the functional requirements in the FRD. It will be used to ensure that the scope, implementation requirements (epics and user stories) , and deliverables for

STORES Order Management (Orders, Receipts, and Invoices) 6

STORES 2.0 remain “as is” when compared to the baseline requirements. Thus, it traces the deliverables in the final buildout back to the requirements agreed to in the Functional

Requirements Document (FRD).

STORES Order Management (Orders, Receipts, and Invoices) 7

Scope The project scope is the successful implementation of all features and capabilities needed in STORES 2.0 to satisfy the functional requirements being defined as part of the Order Management Functional

Requirements Document (FRD). All business requirements captured in this document should be considered in scope for the initial launch of STORES 2.0.

Business Process Reengineering (BPR) opportunities identified in this document will be evaluated in terms of business value to the customer (captured during working group sessions) and the level of effort involved with developing the capability (to be determined by technical members of the implementation team). The Functional Requirements Document (FRD) will include requirements for each BPR determined to be in scope based on the result of these evaluations.

The schedule for the build out of the STORES 2.0 order management capabilities in the FedMall system is dependent on completion and acceptance of the FRD and resulting implementation requirements

(user stories, design comps, and acceptance criteria). Therefore, a precise timeline for building out the order management capabilities in the FedMall domain has not been determined, although initial development is anticipated to begin in Quarter 1 of FY2024.

STORES Order Management (Orders, Receipts, and Invoices) 8

Requirements This section details the business requirements captured during requirements discovery. The requirements are organized by user or system activity under the following functional areas or modules:

• Orders

• Receipts

• Invoices

The business requirements and BPR opportunities included in this document were initially captured in the following MS Excel spreadsheets as part of requirements discovery.

• STORESOrderingBusinessRequirements-Final.xslx

• STORESReceiptingBusinessRequirements-Final.xslx

• STORESInvoicingBusinessRequirements-Final.xslx

• BPROpportunities-OrdersReceiptsInvoices- Final 6 July.xslx

The final version of these spreadsheets can be found in the Orders, Receipts, & Invoicing working group folder on the DLA Teams site.

Flow diagrams for STORES current state ordering, receipting, and invoicing processes are documented in the Appendices A-H:

• Appendix A: STORES Customer Direct & DLA Direct (Depot) Order Flow

• Appendix B: STORES Cargo Lift Freight (CLF) Order & Receipt Flow

• Appendix D: STORES DLA Direct Receipting Flow

• Appendix E: Customer Direct Invoicing Flow

• Appendix F: Order Adjustment Flow

• Appendix G: Order Cancellation Flow

• Appendix H: Invoice Reconciliation Process in STORES

• Appendix I: Non-Standard Distribution Fees

The inbound and outbound interfaces maintained by STORES to support the exchange of order-related transactions and files are identified in:

• Appendix J: Inbound and Outbound Interfaces & Transactions

Acronyms used in this document are identified in:

• Appendix K: Frequently Used Acronyms

STORES Order Management (Orders, Receipts, and Invoices) 9

Orders This section documents STORES business requirements and learnings related to order creation, processing, and routing. These requirements were reviewed as part of Order Management working group sessions.

The STORES current state order processing flows are detailed in the following appendices:

• Appendix A: STORES Customer Direct & DLA Direct (Depot) Order Flow

• Appendix B: STORES Cargo Lift Freight (CLF) Order & Receipt Flow

Activity: Create Order

The following table details the business requirements for system validation of order data used to create a STORES Purchase Order.

Requirement Why Needed?

Provide ability for a shopper/customer to create and save a template containing frequently ordered items.

To save customers time by allowing them to quickly reorder frequently purchased items.

Allow customers to create and submit an order in

STORES

So that customers can source and purchase subsistence items in support of their mission.

Allow requisitions created by the services in their

Food Service Systems (FSS) to be saved to a file format that can be imported into STORES and turned into an order.

To allow the services to use their FSS in conjunction with

STORES as an integrated solution for sourcing and ordering subsistence items.

Enable a STORES Admin to assess a non-standard distribution fee to a customer for items purchased in a regional catalog requiring non-standard distribution fees.

So that vendors are paid a premium in regions where there are elevated risks and dangers associated with delivery of items.

Table 1: Order Creation Requirements

Key Learnings from Requirements Discovery

The current-state STORES application enables customers to create an order by adding items from a catalog or by populating the order with items from an order template. STORES also allows the Services

(Army, Air Force, Navy, USMC) to create an order in their Food Management System (FSS), download it, and then upload it into STORES. An order can be saved before it is submitted. Any user with the same ordering point/ship-to assignment can access the saved order, make edits, and (send) submit it.

BPR Opportunities

BPR Short Description & Notes Priority

Enhanced DODAAC

Validation

DoDAAC validation in STORES is limited to verifying that the DoDAAC exists in STORES. STORES 2.0 should provide additional validation to

Very High

STORES Order Management (Orders, Receipts, and Invoices) 10 verify a DoDAAC is active, and if it is authorized to be used for Bill-To, Ship-To, and Requisition purposes.

Support of Shopper &

Buyer Roles

Allows the work of creating an order to be given to a user who is not authorized to place an order, while requiring the order to be approved (submitted) by a user authorized to purchase (place orders) on behalf of the customer organization. This capability was once provided in STORES and has been requested for STORES 2.0.

Medium High

Automatic Reorders This could benefit customers that regularly place orders for the same items by allowing them to schedule a recurring order for the item.

Low

Pre-order Warning of RDD/Delivery Schedule Conflict

Notify the customer if the RDD for their order conflicts with the Vendor’s delivery schedule (assigned delivery days defined in their contract)

Medium

Pre-order Check to verify item meets the lead time defined by the vendor

Provide a check before order placement that captures if an item does not meet the lead time defined by the vendor. Require the customer to confirm availability with the vendor before placing the order and capture this in the order as a waiver that can be used as a metric for evaluating a vendor's performance.

High

Provide automated interface to import order files from the Services

This would save the services time by removing the need to download the file from their FSS and then log in to a separate system to upload the file. Part of this BPR is to determine if the Services can standardize on a single order file format.

High

Notify/alert customer if an item is out of stock.

Customers can currently see inactive stock items in Order Details but out-of-stock items may not be set to inactive and there may be items in their order that have run out of stock since the last catalog update and subsequent order refresh. This requirement is for the system to allow a vendor to provide pre-order and post-order notifications to the customer that an item is out of stock and replacement options.

Providing real-time visibility of vendor stock levels will require an interface with the vendor’s system.

Medium

Activity: Validate Order

The following table details the business requirements for validating order data used to generate a

STORES Purchase Order.

Requirement Why Needed?

Validate that all required data for an order is provided, that the data satisfies the business rules, and that it is properly formatted for generation of a STORES purchase order or requisition.

To ensure that the proper order files can be created and transmitted to the proper channels based on the collected data.

Identify issues preventing order import and allow the user to correct the issues.

In some cases, an imported order may not meet all the requirements for order creation in STORES. It is therefore necessary to identify the problem lines or issues preventing order creation and allow the user to fix them so that the order can be submitted.

Table 2: Validate Order Requirements

STORES Order Management (Orders, Receipts, and Invoices) 11

Key Learnings from Requirements Discovery

• When a user attempts to submit an order, STORES validates that all required fields are provided and that the data is properly formatted for processing and storage.

• STORES allows the user to select their Service (for example, Army) before uploading an order file to ensure the right validation is performed.

• STORES performs two levels of validation when an order file is imported by the Services:

o Data Validation: Required fields/elements are present and are correctly structured for import into the database.

o Business Rule Validation: These rules can be specific to the Service importing the order file and define things like document number creation and storage. DoDAAC validation is limited to verifying that the DoDAAC exists in STORES but does not check any 3rd party source to ensure the DoDAAC is valid or active.

• STORES flags lines (elements) that fail validation during file upload. The user can then fix the errors in STORES. Fixing an error with the file in STORES and not in the originating FSS presents audit readiness issues for the services.

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for order validation:

BPR Short Description & Notes Priority

Validate Catalog # during Order Import

Notify service customer if imported order file contains the wrong catalog number

High

Determine if data in order import file should overwrite information in

STORES.

Need to determine if data in the current-state system (including financial/SLOA info) is overwritten when it conflicts with data in the import files.

High

Activity: Resolve Order Creation Issues

The following business requirement identifies the need for TVLS Admin users to be able to perform order-related functions in the system on behalf of customers.

Requirement Why Needed?

Provide the ability for a TVLS Admin to perform order-related functions on behalf of a customer such as placing an order.

Internet outages or other problems may prevent

STORES customers from accessing the application when needed. Allowing an ADMIN to place an order

(or perform another function on behalf of a customer) allows that customer and organization to

STORES Order Management (Orders, Receipts, and Invoices) 12 continue to receive required sustenance items during these outage periods.

Table 3: Resolve Order Creation Issues Requirements

Key Learnings from Requirements Discovery

STORES allows TVLS Admins to perform order-related tasks on behalf of a customer, including submitting orders and receipts. This is done through user emulation, meaning the admin user assumes the identity of the customer user when performing the action.

The need for an Admin user to act on behalf of the customer is a result of some customers not being able to access the system. Although it would be beneficial to put the responsibility for order submissions back on the customer by having them engage their headquarters in these cases, TVLS Admins must be able to perform order-related tasks for customers in STORES 2.0.

See DLA Troop Support Problem Resolution Processes for more information.

Activity: Create & Send PO or Requisition Order File

The following table details the business requirements for post order processing and routing of STORES order files.

Requirement Why Needed?

Upon order submission, create the appropriate order file with the correct information and format for post order processing and routing.

So that downstream systems like DAAS, EBS, and Vendor systems will be able to process and route the order(s) correctly.

Send the STORES order file(s) to DAAS for post order processing and routing.

DAAS processing is required to transform and route the STORES order files so they can be ingested into the vendor’s order management system (EDI-850 only) and

EBS (EDI-850 & EDI-864).

Table 4: Create Purchase Order Requirements

Key Learnings from Requirements Discovery

Once an order is submitted by a user, STORES will either create an EDI-850 Purchase Order or an EDI-864

Text Message order file based on the contract code and CONUS/OCONUS indicator. During order processing, a separate order file (PO) is created for each vendor from which items were purchased.

EDI-850 Purchase Order

STORES generates a STORES Purchase Order (flat file) for Customer Direct orders placed against catalogs containing Prime Vendor, Market Fresh, or UGR-A items. These transactions are converted to an ANSI

X12 EDI-850 Purchase Order format at DAAS before being routed to the Vendor for order fulfillment, and to EBS for financial processing.

A STORES Purchase Order is also created for Cargo Lift Freight (CLF) orders although the format, processing, and routing of CLF order files is different.

For more information on the processing and routing of STORES Purchase Orders, see:

STORES Order Management (Orders, Receipts, and Invoices) 13

• Appendix A: STORES Customer Direct & DLA Direct (Depot) Order Flow

• Appendix B: STORES Cargo Lift Freight (CLF) Order & Receipt Flow

EDI-864 Text Message

STORES generates a MILSTRIP Requisition (flat file) for DLA Direct orders of depot stock items

(MRE/UGR-H&S/M). There are four catalogs in STORES that result in EDI-864 orders. The MILSTRIP requisition file is converted to an EDI-864 Text Message format at DAAS before being sent to EBS to create the Sales Order. The EDI-864 is blocked from further processing at EBS because there is no vendor for DLA stock items.

A member of the STORES Rations team assigns the EDI-864 order to the depot (DSS) for fulfillment. The depot is then responsible for shipping the ordered items. The delivery can be tracked in DSS Material

Tracker through the DDC (status can be provided to recipient if requested).

For more information on the processing and routing of STORES requisition order files see:

• Appendix A: STORES Customer Direct & DLA Direct (Depot) Order Flow

BPR Opportunities

The following table provides a summarized description of BPR opportunities for order creation and transmission:

BPR Short Description & Notes Priority

Populate the Sales Order up front with MILS financial information in the order IDOC, such as document numbers, signal code, fund code, and supplemental address.

STORES does not send MILS data for the customer in the initial order iDoc to EBS. It is provided in the receipt iDoc. Having the complete MILSTRIP billing profile at the time of order creation would be good for auditing and reporting purposes.

High

Provide the order number that is tied to the requisition to EBS

FedMall creates a unique order number but it is not currently being sent to EBS. In Fedmall, you can have multiple orders under the same Fedmall order number that contain multiple document numbers. To try and search for a particular one can be challenging if you only know part of it.

Providing the order number to EBS may be something the STORES team wants since many customers are billed based on the order number.

High

Make sure the Contracting Specialist (CS) is notified when an MRE order from Fedmall hits EBS and that the order file includes contact information for

Order/requisition file sent to EBS should be updated to include contact information for the person placing the order so that the CS can contact them if needed to resolve any issues. Currently the CS must contact Fedmall directly to identify the person placing the order.

Depots will not ship without POC information, so it is critical that it is provided up front.

STORES Order Management (Orders, Receipts, and Invoices) 14 the person who placed the order.

Activity: Export Order

The following table details the business requirements for order exports by Service customers.

Requirement Why Needed?

Provide customers with the ability to access and export order data in STORES for their own records or for ingestion into their FSS.

So that customers are able to access to STORES order data necessary to satisfy their auditing and reconciliation processes.

Table 5: Export Order Requirements

Key Learnings from Requirements Discovery

• STORES allows Service customers to export a copy of a STORES order that can then be imported into their FMS.

• This is currently a manual process done through the Send Order Report

• The USMC has been asking for a more automated integration because the STORES PO number is not communicated back to their system, but they are billed by the STORES PO number.

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for order exports:

BPR Short Description & Notes Priority

Automated Interface for

Exporting Order-Related

Data to Service Systems

The Services currently use the Send Order Report for this purpose but they have expressed a desire for the process to be more automated.

Activity: Modify Submitted Order

The following requirement captures the need for the system to be able to account for changes to an order that are communicated to the vendor outside of STORES.

Requirement Why Needed?

Provide the ability to capture and account for adjustments (decreases to the quantity ordered) communicated to the vendor outside of STORES.

Due to the short turnaround time with fulfilling orders in STORES, any order cancellations, decreases to the quantity ordered, or changes to the RDD must be communicated to the vendor by phone or email. Email.

The system must provide the ability for users to capture these changes within the system so that order documents in EBS are reconciled with GRF and so that the reason for a change to the RDD is recorded. This is important for both accounting and reporting purposes.

Table 6: Modify Submitted Order Requirements

STORES Order Management (Orders, Receipts, and Invoices) 15

Key Learnings from Requirements Discovery

STORES allows changes to a submitted order that are communicated outside of the system to be captured within the system. This communication outside of STORES is necessary because of the time-critical nature of ordering food items. For example, by the time a customer determines they need to make changes to an order, the vendor may already be in the process of loading the items for delivery.

Thus, there is a need for immediate communication of a modified order.

The current state procedures for handling changes to an order in STORES are described below:

• Customer Needs to Increase the Ordered Quantity: Customer places a new order in STORES for additional items.

• Customer Needs to Decrease the Ordered Quantity: Customer communicates the change to vendor by phone or email.

o If communicated before items are shipped, Vendor will adjust the shipment quantity as requested.

o If not communicated after items have shipped, then Customer will need to reject the delivery of the unneeded items.

• After the customer receives the shipment, they will receipt for the adjusted quantity and enter a short shipment code explaining the reason. The PO, PR, and Sales Order at EBS are updated with the adjusted quantity when the GRF is received at EBS.

• Customer Needs to Change the Required Delivery Days: Customer communicates the change to vendor by phone or email.

The current state process flow for order adjustments is detailed in Appendix F: Order Adjustment Flow.

Activity: Cancel Order

The following requirement captures the need for the system to be able to account for an order cancellation that is communicated to the vendor outside of STORES.

Requirement Why Needed?

The application will provide the ability to capture and account for order cancellations communicated to the vendor outside of STORES.

Due to the short turnaround time with fulfilling orders in STORES, an order cancellation must be communicated to the vendor by phone or email. The system must provide the ability for users to capture these changes within the system so that order documents in EBS are reconciled with GRF and so that the reason for a change to the RDD is recorded. This is important for both accounting and reporting purposes.

Table 7: Cancel Submitted Order

Key Learnings from Requirements Discovery

The process to account for an order cancellation communicated outside of STORES is similar to the process for making modifications to a submitted order. If a customer needs to cancel an order, they will contact the vendor by phone or email.

STORES Order Management (Orders, Receipts, and Invoices) 16

The order cancellation process flow is captured in Appendix G: Order Cancellation Flow.

• If the cancellation request is received by the vendor before the items have shipped:

o They will cancel the shipment and the order will be cancelled in STORES.

• If the cancellation request is received by the vendor after the items have shipped:

o The customer will either refuse the shipment or arrange to return the items. Customer will enter a 0-receipt and short shipment code to reflect the cancellation. Once the receipt is received at EBS, the PO and/or sales order are updated to reflect the receipt.

• When vendor doesn’t ship anything, they normally do not send 810 or enter an invoice in

STORES. Troop Support must then rely on the short shipment code entered by the customer for the 0-receipt, which is almost always set to “item not in stock – no replacement ordered”, which may not accurately reflect the cause of the cancellation.

• In some cases, the customer may not realize they are responsible for the short shipment (for example, they put in a lead time that conflicts with the vendor’s contractual delivery days)

• There is a current process in STORES for vendors to add/upload short shipment codes if they disagree with what the customer is attributing it to.

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for order cancellations:

BPR Short Description & Notes Priority

Allow a vendor to cancel an Order in STORES

Allow a vendor to cancel an order in STORES if an order cancellation is communicated to them in time by phone or email.

Changes to orders outside the system that aren’t accounted for in the system negatively impact the reliability of metrics and auditing capabilities within the system.

Activity: Receive Order

The following requirement captures the need for the system to capture customer profile information that is needed by an EDI vendor to set up the customer in their back-office system for order fulfillment.

Requirement Why Needed?

Provide a process for vendors to capture customer profile information in their system database so that they can process orders submitted to them by the customer in STORES.

To fulfill customer orders in STORES, the customer must exist in vendor’s order management system. The system should allow vendors to confirm the receipt of an order.

Table 8: Receive Order Requirements

Key Learnings from Requirements Discovery

• EDI Vendors need to set up a STORES customer in their system so that they can receive, process, and fulfill STORES orders received from the customer.

STORES Order Management (Orders, Receipts, and Invoices) 17

• The customer provides the TVLS with financial information (e.g., bill-to DoDAAC), locations, and other pertinent information.

• TVLS builds a profile for the customer in STORES and sends the profile information to the vendor so that they can set them up in their database.

Activity: Confirm Receipt of Order

The following requirement captures the need for the system to allow vendors to acknowledge the receipt of an order.

Requirement Why Needed?

Provide means for EDI and non-EDI vendors to acknowledge receipt of a STORES order, and to the extent possible, provide delivery information to the customer, including shipping status and estimated delivery date.

Capturing order status information from the vendor and making it available to the customer decreases uncertainty and improves the customer’s ability to plan their subsistence needs and activities.

Table 9: Confirm Receipt of Order Requirements

Key Learnings from Requirements Discovery

STORES currently provides the means for both EDI and Non-EDI Vendors to confirm the receipt of an order.

• Non-EDI Vendors confirm the receipt of an order through the Order Confirmations function in

STORES. Customers can see if an order was confirmed by the Vendor when viewing a pending receipt.

• EDI Vendors can send an EDI-997 Functional Acknowledgement back to STORES in response to receiving a STORES customer order. The Functional Acknowledgment is ingested by STORES and recorded in the pending receipt to be submitted by the customer.

There is no requirement in STORES for a Vendor to acknowledge the receipt of an order. During requirements discovery, a need was identified to determine why an EDI-997 isn’t sent back more often by EDI vendors (for example, is it due to the vendor’s EDI implementation or another reason).

The aim for the future state is for every order be acknowledged by the vendor (via 997 Functional

Acknowledgement, EDI-856 Advance Ship Notice, or within the system). The order delivery process should follow what is prescribed by the Defense Logistics Management Standards (DLMS).

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for order acknowledgements:

BPR Short Description & Notes Priority

Require vendors to confirm receipt of orders.

The aim for the future state is for every order to be acknowledged by the vendor (via EDI-997 FA, EDI-856 ASN, or manually confirmed within the system).

STORES Order Management (Orders, Receipts, and Invoices) 18

Receipts This section captures the business requirements and key learnings from requirements discovery for the

STORES receipting processes.

The STORES current state receipting process flows are detailed in the following appendices:

• Appendix B: STORES Cargo Lift Freight (CLF) Order & Receipt Flow

• Appendix C: STORES Customer Direct Receipting Flow

• Appendix D: STORES DLA Direct Receipting Flow

Activity: Create Receipt

The following requirements are related to the customer need to create receipts in the system for ordered items after they are delivered by the vendor.

Requirement Why Needed?

Provide the capability for a customer to view/submit a receipt in the application for each placed order.

So that the customer can record the receipt of ordered items and the system can identify reasons for discrepancies between what was ordered and receipted.

Provide the ability for Army, Air Force, USMC, and

Navy users to import a receipt into STORES.

So that receipts can be created in the customer's Food

Service System yet be processed in STORES and transmitted to the Recon Tool and EBS for reconciliation.

Table 10: Create Receipt Requirements

Key Learnings from Requirements Discovery

STORES creates a pending receipt for each order submitted in STORES. Once the ordered items are received by the customer, they look up the pending receipt in STORES and update it to reflect the delivery date and quantities received. If a quantity is adjusted, then a reason code is required.

Like the Import Order function used by the Services, STORES allows Army, Air Force, and USMC customers to create a receipt in their FMS, download it, and then upload it into STORES. Once the receipt is successfully imported, it will overwrite the pending receipt in STORES.

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for receipt creation in STORES:

BPR Short Description & Notes Priority

Integrate the Service systems with STORES so that receipting transactions in STORES are propagated to the

Keeping data in sync between systems is important for reporting and auditing purposes. Changes to quantities made in STORES are not automatically applied in the services FMS. This type of integration is being asked for by the USMC who is looking for standards and formats to pass order and receipt data between their service/financial system and STORES.

STORES Order Management (Orders, Receipts, and Invoices) 19 service system (and vice versa).

Bypass Recon Tool if order (or receipt) is for UGR-A items.

UGR-A orders are not invoiced in STORES. Therefore, any resulting receipts created in STORES should bypass the Recon tool and be sent directly to EBS so that EBS processing isn’t delayed. UGRA orders can be identified by the contract of the catalog they were ordered from.

UGR-A orders are invoiced in WAWF and not in STORES. Receipts and Receipt adjustments submitted in STORES for these orders are propagated to the Recon Tool but because they aren’t being invoiced in STORES, they will set there for 90 days before being sent on to EBS.

Medium

Activity: Validate Imported Receipt

The following requirement capture the need for the system to validate receipt files imported into

STORES by a customer.

Requirement Why Needed?

The system shall validate imported receipts based on STORES business rules and service-specific requirements.

To ensure that imported receipts are structured, formatted, and populated as required for processing by STORES and downstream systems like EBS.

The system shall identify any errors during file import and display them to the customer.

So that the customer can correct the errors and reimport the receipt for processing.

Table 11: Validate Imported Receipt

Key Learnings from Requirements Discovery

• Army, Air Force, and USMC customers can import receipts created in their FMS.

• Receipt files imported into STORES by the Services, go through a similar validation check as order imports to ensure they are correctly structured and formatted, and that the data satisfies

STORES business rules for receipt processing and transmission.

• The receipt upload files used by the Services do not share a standard format; however, they are very stable.

• Services have option to fix upload errors in STORES or to fix them in their FSS, and then re-upload the file into STORES.

• Army is only service currently submitting receipt adjustments from their FSS. There is a three-digit identifier in the upload file that identifies it as a receipt (D6U) or receipt adjustment (REV).

• STORES 2.0 should allow military service customers to submit both receipts and receipt adjustments from their FMS.

STORES Order Management (Orders, Receipts, and Invoices) 20

Activity: Resolve Receipt-Related Issues

The following requirement captures the need of TVLS Admins to be able to perform receipting-related tasks in the system on behalf of the customer:

Requirement Why Needed?

The system shall provide the ability for a TVLS

Admin to complete receipting-based tasks on behalf of the customer, such as importing a receipt and submitting a receipt.

Cases exist where a customer may not have access to the STORES application to do receipting.

Identify and save information about each action taken by the TVLS Admin on behalf of a customer, including the date/time of the action and the user ID of the TVLS Admin.

So that the data can be provided for auditing and reporting purposes.

Table 12: Resolve Receipt Related Issues Requirements

Key Learnings from Requirements Discovery

STORES allows TVLS Admin users to submit receipts and receipt adjustments on behalf of the customer.

This is done through user emulation, meaning the TVLS Admin user can assume the identity of the customer user to perform the action.

The need for an Admin user to act on behalf of the customer is a result of some customers not being able to access the system. Although it would be preferred to put the responsibility for receipting back on the customer by having them engage their headquarters in these cases, STORES 2.0 must allow a TVLS

Admin to submit receipts and receipt adjustments on behalf of the customer. The customer should be notified of actions taken by the TVLS, and the changes should be captured for auditing and reporting purposes.

See DLA Troop Support Problem Resolution Processes for more information.

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for resolving receipting-related issues:

BPR Short Description & Notes Priority

Capture issues on the customer and vendor side with out-of-stock items.

This will help to correctly attribute the causes of missed deliveries and identify vendors that are consistently offering out-of-stock items in their catalog(s).

There needs to be a way to capture issues on the customer and vendor side with out-of-stock items. For example, should customers continue to place orders for out-of-stock items to show there is a demand or order substitute items? Should vendors be penalized or flagged if they regularly provide out-of-stock in their catalog?

High

Define SOPS for delivery or fulfillment-related issues, including short

The current policy or expectation is that a customer will refuse any non-ordered items or items in excess of the adjusted order quantity (the exception is catch-weight items). This doesn’t always happen.

STORES Order Management (Orders, Receipts, and Invoices) 21 shipments, substitute or replacement items, large quantity orders that are not needed (cancelled), returns, etc.

Customers will sometimes keep substitute or replacement items from the vendor or quantities above what was ordered for an LSN. These situations are handled on a case-by-case basis by a TVLS to figure out things like whether the customer should pay for extra items in the shipment even though they weren’t ordered.

Having a set of SOPs in place will not only set customer and vendor expectations for how issues and exceptions will be handled, but could have design implications for the future state system if the system will be used by the STORES team in addressing or mediating these situations.

Activity: Submit/Transmit Receipt

The following requirements relate to the processing and routing of receipts once they are submitted by the customer.

Requirement Why Needed?

Provide the ability for STORES customers to submit a receipt for reconciliation with the vendor invoice.

So that discrepancies between what was reported delivered and what was reported received can be identified and resolved by the vendor, customer, and

TVLS.

The system shall transmit receipt lines to EBS (via

DAAS) for processing.

So that the receipt can be reconciled with the PO, sales order, and PR.

The system shall allow a privileged admin to set the number of days a customer has to submit a receipt for an ordering point/catalog. If a receipt is not submitted within that timeframe, the application shall prevent the customer from submitting any additional orders for that ordering point/catalog until all past due receipts have been submitted.

To help motivate customers to receipt orders in a timely manner.

The application shall transmit receipt adjustment lines to EBS (via DAAS) for processing.

So that the receipt adjustment can be reconciled with the PO, sales order, and PR.

Table 13: Submit/Transmit Receipt Requirements

Key Learnings from Requirements Discovery

• When a receipt is submitted by the customer, it is added to the Recon Tool so that it can be reconciled with the vendor invoice.

• TVLS Admin users can set a grace period (# of days) that the customer has to enter a receipt before they are prevented from placing new orders. This setting is applied in the customer’s

MILSTRIP profile at the Ship-To/Catalog level. This means that the restriction is only applied to the customer if they are trying to place an order on a catalog for a ship-to location that has

STORES Order Management (Orders, Receipts, and Invoices) 22 pending receipts. The customer is not prevented for submitting orders for other ship-to locations.

• Receipts and receipt adjustments are batched and sent at 6 PM EST each day.

• Receipt and receipt adjustment files sent from STORES to DAAS include a modification numbers.

The initial receipt for an order is always mod 0. Any subsequent receipt adjustment is all marked as mod 1, instead of mod 1, mod 2, mod 3, and so on.

• In the rare case multiple adjustments are sent on the same day, the DAAS can have trouble determining which adjustment is the final one.

• STORES 2.0 will need to be able to determine the sequence of all adjustments.

• An email is sent to a Troop Support distribution group detailing the number of receipts and receipt adjustments sent in the batch.

• For group rations, the order is receipted in STORES, but the receipt is archived in STORES and not sent on to EBS.

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for receipt transmissions:

BPR Short Description & Notes Priority

Fix any batching and sequencing issues causing receipt adjustment IDOC failures

Receipt Adjustments sent to DAAS on the same day as another receipt adjustment may cause the IDOC generation to fail. Receipt adjustment to 0 after the customer has paid their bill can fail as well.

These are rare exceptions that are caused by batching on the STORES side and processing on the DAAS.

Receipt and receipt adjustments all get modification numbers. Initial receipt is mod 0, and any subsequent receipt adjustment are all marked mod 1, instead of mod 2, mod 3, and so on. When multiple adjustments are sent on the same day, the systems can have trouble determining which adjustment is the final one. Although this doesn’t happen often, it does happen and the future state system should be able to identify the sequence of all adjustments.

If an item is 0-receipted initially, it will be processed fine by EBS. If a line is originally receipted at a positive quantity, and DLA bills the customer, and the customer pays the bill, and then does a receipt adjustment to 0 afterwards, the receipt adjustment IDOC will fail.

High

Activity: Adjust Receipt

The following requirements capture the need for customers to adjust a receipt, and how the system should process and handle a receipt adjustment.

Requirement Why Needed?

The system shall allow a customer to adjust a receipt and submit it for processing. The system shall process the receipt adjustment, post it to the

Customers need the ability to adjust and submit a receipt in cases where the receipt was entered incorrectly the first time.

STORES Order Management (Orders, Receipts, and Invoices) 23

Recon Tool, and add it to the daily batch sent to

DAAS for processing.

Table 14: Adjust Receipt Requirements

Key Learnings from Requirements Discovery

• The Adjust Receipts feature allows customers to look up receipts to adjust by the PO number.

• The customer can only decrease the quantity receipted and change the RDD.

• STORES allows a receipt adjustment to be made up to 180 days after the RDD.

• Army users can submit receipt adjustments through their FMS (AFMIS).

• Receipt adjustments are recorded in the Recon tool and then sent to DAAS where an IDOC is generated and sent to EBS.

• Receipt adjustments for DLA direct and CLF orders are not transmitted to EBS.

• The initial receipt and any subsequent receipt adjustments include a sequential mod number so that STORES and downstream systems like DAAS and EBS can correlate and handle the transactions.

• Receipt adjustment on the same day as initial receipt or subsequent adjustments may cause the

IDOC to fail.

• Receipt adjustment to zero after vendor has paid their initial bill will cause IDOC to fail.

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for receipt adjustments in STORES:

BPR Short Description & Notes Priority

Prevent Service customers from making receipt adjustments within the system if customer is importing receipt adjustments.

Currently only the Army is submitting receipt adjustments from their FMS. The primary purpose for this BPR is to keep data in sync between systems for reporting and auditing purposes. Changes to quantities made in STORES are not automatically applied in the Service’s FMS. Should the services be required to make these adjustments in their FMS/financial system and then upload/transmit the data to STORES.

Activity: Export Receipt

The following table captures the need of Service customers to be able to export a receipt to their Food

Management System:

Requirement Why Needed?

The system shall allow Navy and USMC customers to download a receipt in a format that can be imported into their Food Management System.

Navy and USMC customers can currently import STORES receipts into their FMS for reconciliation or reporting-related purposes.

Table 15: Export Receipt Requirements

STORES Order Management (Orders, Receipts, and Invoices) 24

Key Learnings from Requirements Discovery

The Export Receipt function allows USMC and Navy customers to export receipts to their FMS. It is not widely used today.

The USMC has asked for a standard format for a receipt export that can be ingested by both their food management system and their financial system. Automated transmissions of orders and receipts to the service systems needs to be discussed with the services.

DLA Troop Support Problem Resolution Processes

TVLS Admins actively work with vendors and customers to resolve issues with order fulfillment. Most of the steps taken to handle these types of issues are communication-based actions done over phone or email outside of STORES. While the requirements for the system functions needed to resolve these issues is already captured in other sections, the standard procedures followed by the TVLS, customer, and vendor are detailed below and should be considered in the design of STORES 2.0.

Late/Missed Deliveries

Process:

1. TVLS communicates with customer and vendor to prevent "missed deliveries".

2. TVLS notifies customer of contractual vendor delivery days.

3. TVLS works with CS and vendor for emergency deliveries.

4. Vendor (or TVLS when requested) communicates with customer on delivery ETAs.

Not In Stock (NIS) Issues

Processes:

1. TVLS communicates with customer and vendor to prevent "missed deliveries".

2. TVLS notifies customer of contractual vendor delivery days.

3. TVLS works with CS and vendor for emergency deliveries.

4. Vendor (or TVLS when requested) communicates with customer on delivery ETAs.

Quality Issues

Processes:

1. Customer notifies vendor of spoiled/damaged product within certain timeframe - should notify

TVLS.

2. Vendor notifies customer of recalled items - should notify TVLS and CS

3. Customer adjusts receipt in STORES (non-consumed, no partial UoM) with the correct short shipment reason code.

4. STORES transmits receipt adjustment to DAAS.

5. DAAS sends Receipt Adjustment IDOC to EBS (OF-INT-0074B) - DLA direct and CLF adjustments do not transmit.

STORES Order Management (Orders, Receipts, and Invoices) 25

Invoices This section captures the business requirements and key learnings from requirements discovery for the

STORES invoicing processes.

The STORES current state invoicing process flow is detailed in Appendix E: Customer Direct Invoicing

Flow.

Activity: Create Invoice

The following requirements capture the need of vendors to submit invoices into the system.

Requirement Why Needed?

Provide interface to ingest and post EDI-810 invoice files to the Recon Tool.

So that the invoice can be reconciled with the STORES receipt before being sent to EBS for final processing and release of payment to the Vendor.

Provide capability for non-EDI vendors to create an invoice in STORES based on the customer PO.

So that Vendors not using EDI can submit an invoice for reconciliation with the STORES receipt before being sent to EBS for final processing and release of payment to the

Vendor.

Table 16: Create Invoice Requirements

Key Learnings from Requirements Discovery

STORES supports two methods for creating an invoice:

• Ingestion of EDI-810 Invoice Sent by Vendor via VAN/DAAS

• Invoice Creation in STORES (Recon Tool)

Ingestion of EDI-810

EDI-enabled prime vendors create the invoice in their order management system and then send an EDI-

810 Invoice file to STORES through a 3rd party VAN.