BRD-STORES2-VIC-Draft-v0.2.pdf

Defense Logistics Agency

FedMall

STORES 2.0 VENDOR ITEM CATALOGS

Business Requirements Document (BRD)

Version 0.2 - DRAFT

Last Update Date: August 22, 2023

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

STORES Vendor Item Catalog 2

Table of Contents

EXECUTIVE SUMMARY

SCOPE

REQUIREMENTS

CREATE CATALOG

BASELINE CATALOG PROCESS

Current State Process Key Learnings from Requirements Discovery BPR Opportunities

PRODUCTION CATALOG SUBMISSION PROCESS VIA EDI-832

Current State Process Key Learnings from Requirements Discovery BPR Opportunities

PRODUCTION CATALOG APPROVAL PROCESS

Current State Process Key Learnings from Requirements Discovery BPR Opportunities

CREATE CATALOG IN EBS

Current State Process Key Learnings from Requirements Discovery BPR Opportunities

VIEW CATALOG IN STORES

Current State Process Key Learnings from Requirements Discovery BPR Opportunities

CATALOG EXPORTS

Current State Process Key Learnings from Requirements Discovery BPR Opportunities

HIDE CATALOG ITEMS

Current State Process in STORES Key Learnings from Requirements Discovery BPR Opportunities

ITEM REQUESTS

CUSTOMER-INITIATED REQUESTS

Current State Process Key Learnings from Requirements Discovery BPR Opportunities

VENDOR-INITIATED REQUESTS

Current State Process Key Learnings from Requirements Discovery BPR Opportunities

MANUAL ITEM REQUEST

Current State Process

STORES Vendor Item Catalog 3

Key Learnings from Requirements Discovery BPR Opportunities

UPDATE CATALOG

ADD/EDIT/DELETE ITEMS

Current State Process BPR Opportunities

CATALOG RUNS

Current State Process Key Learnings from Requirements Discovery BPR Opportunities

UPDATE CATALOG IN EBS

Current State Process Key Learnings from Requirements Discovery BPR Opportunities

APPENDIX A: BASELINE CATALOG UPDATE & APPROVAL PROCESS

APPENDIX B: CUSTOMER-INITIATED ITEM REQUEST

APPENDIX C: VENDOR-INITIATED ITEM REQUESTS

APPENDIX D: GLOSSARY OF TERMS

APPENDIX E: ITEM REQUEST FORM

STORES Vendor Item Catalog 4

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 Item Request and Catalog Update functional areas, which fall under the current-state STORES Catalog module. 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 Vendor Item Catalogs started on April 25, 2023, with the last regularly scheduled meeting ending on August 8, 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 2.0 remain “as is” when compared to the baseline requirements. Thus, it traces the

STORES Vendor Item Catalog 5 deliverables in the final buildout back to the requirements agreed to in the Functional

Requirements Document (FRD).

STORES Vendor Item Catalog 6

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 Vendor Item Catalog 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 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 Vendor Item Catalog 7

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

• Create Catalog

• Item Requests

• Catalog Approval Process

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

• STORES Vendor Item Catalog Requirements 8-8-23.xslx

This spreadsheet can be found in the VIC working group folder on the DLA Teams site.

The Catalog update and approval process flow is detailed in:

• Appendix A: Baseline Catalog Update & Approval Process

The customer-initiated item request process flow is detailed in:

• Appendix B: Customer-Initiated Item Request

The vendor-initiated item request process flow is detailed in:

• Appendix C: Vendor-Initiated Item Requests

A glossary of terms used in this document can be found in:

• Appendix D: Glossary of Terms

STORES Vendor Item Catalog 8

Create Catalog This section documents STORES business requirements related to creating, updating, and maintaining vendor catalogs.

The Catalog Update and Approval Process Flow in STORES is captured in Appendix A: Baseline Catalog

Update & Approval Process.

Baseline Catalog Process

The baseline catalog process in STORES allows Contract Specialists and Vendors to create new catalogs or modify existing catalogs.

Subsistence Requirement Requirements Elaboration Why Needed Ability to create a catalog in a format separate from a production catalog.

Ability to create a catalog in a side area/staging set-up to make changes that will not affect the production catalog -once live or prior to going live.

DLA and vendors need to make sure a catalog is fully populated with correct field info prior to it being evaluated to be activated for customers to view.

Current State Process

1. Contract Specialist (CS) creates initial baseline catalog.

The baseline catalog can be manually created or copied from an existing production catalog (existing vendor). It can also be submitted via an EDI-832 as a production catalog and copied over to a baseline catalog (new vendor). Vendors can choose which fields to copy from production to baseline

(for example, removing pricing or LSN fields) and can export in a spreadsheet or flat file formats.

Copying allows the vendor to populate the baseline catalog with the latest production data.

2. CS/vendor view/modify items on the baseline catalog.

New items must go through the item request process.

3. CS submits baseline catalog to promote it to a production catalog (pending).

They cannot choose which fields to promote (all fields are updated). The Baseline catalog can continue to be used to promote updates even after it has been promoted and is an active production catalog. If an item record is modified in the baseline catalog, then all fields for that record will overwrite the production record. If a record is unchanged then all fields for that record are left unchanged (similar to EDI-832 submission). A report showing what is about to change prior to overwrite is made available to the vendor by DLA Troop Support.

The baseline to production catalog update process is captured in Appendix A: Baseline Catalog Update &

Approval Process.

Key Learnings from Requirements Discovery

• Baseline catalogs are a side working area where catalogs can be worked on before they are ready to be reviewed and published to PROD.

• The Baseline Catalog Update process is used by or in support of non-EDI vendors.

STORES Vendor Item Catalog 9

• Vendors may only modify baseline catalogs that have a status of “Vendor Ready” and to which they are assigned with the role of “Vendor.” Only subsistence users can access a catalog with a

“Being Built” status.

• Baseline catalogs can be created from scratch or from a copy an existing catalog. For example, if there is an incumbent vendor that is receiving the same contract, they can copy the production catalog to baseline, associate the new contract number, and make any necessary modifications to it, before publishing it.

o Users can specify which fields in the Production catalog they want to copy over (for example, they may choose not to copy over pricing information if they are doing a price refresh).

• STORES allows users to compare the baseline catalog to the active production catalog and see any differences. The differences are detailed in the Pending Catalog Change Report.

o Records from the Baseline catalog overwrite records in the pending Production catalog.

o There is currently no way to excempt records or fields in the pending Production catalog from being overwritten by records or fields in the Baseline catalog.

• System checks records in Baseline Catalog (and EDI-832) to verify they are valid before updating the pending Production catalog.

• The system keeps a history of all changes to a catalog.

• A catalog update process is run each weekend (around 12 am ET on Sunday).

• Any updated records in the pending catalog overwrite the pending records in the active catalog.

• If a record in the production catalog has 10 fields and one of the fields was changed in the baseline, then all 10 fields will be overwritten.

• To determine an updated record, the system looks at the date/time stamp of the pending record, and if it is more recent than the date/time stamp of the active record, then the active record is updated.

• Unchanged records retain their date/time stamp so customers can see when information for an item in the catalog was last updated, such as price.

• Contract Specialist (CS) creates an initial baseline catalog in STORES.

• CS or vendor can view or modify items in the baseline catalog.

• Assuming everything looks right with the baseline catalog, the CS submits the baseline catalog for promotion to production.

• You can export the baseline catalog to a spreadsheet or flat file (CSV) that the vendor can import into their system. The typical process is to modify the catalog in STORES until you feel it is ready, and then export it.

• When copying a production catalog to a baseline catalog, you can specify which fields you want to copy over. For example, you can choose not to copy over vendor specific fields like LSN and price or fields that will contain new data once the new catalog is published.

• Baseline catalogs are most important for vendors who do not use EDI, like Produce and Market

Fresh Vendors.

• The system allows you to compare the baseline catalog to the active production catalog and see any differences. The differences are detailed in a report.

• Records from the baseline catalog (e.g., stock numbers) will overwrite records in Production.

• The system checks the records that are being submitted and warns you if there are any issues or errors. The errors must be fixed before the record is accepted.

STORES Vendor Item Catalog 10

• A baseline catalog can be updated at any time to reflect the production catalog.

• Currently there is no way of exempting certain fields/records from overwriting the corresponding fields/records in the production catalog. If this is something that is wanted, it would need to be captured as a BPR.

• Only records where there is a change are updated. Matching records are not overwritten by the update.

• When an EDI transaction comes in to update the catalog: If every field on the record is the same, STORES does not update the vendor item catalog record. This is important because the date/time stamp remains unchanged and thereby accurately reflects when the record was last updated.

• If a record in the production catalog has 10 fields and one of the fields was changed in the baseline, then all 10 fields are overwritten.

• The system keeps a history of all changes.

• This applies to both the EDI side and the Production Catalog. In the STORES Production Catalog, there is an active record and a pending record.

• The active record is what the customer will see as soon as the catalog update process is ran each

Sunday (at approximately 12 am EST).

• If a pending record has a more current time stamp than what is on Production, then the pending record is moved to the active record status.

• Changes in the baseline catalog update the pending record.

• The comparison being done is between the pending catalog and the baseline catalog or EDI-832 catalog update. Once approved, the pending record will overlay the active record.

• There’s one active record for every pending record in the catalog. The only time there is an active record and no pending record is when there is a delete request in the pending record

(system treats no record in pending catalog as a delete request).

• Some reports look at the active record, some look at the pending record, and there is one report that allows you to choose what record to look at.

• The Baseline catalog and EDI-832 are only updating the pending record.

• A new feature is being added to STORES where items in the baseline catalog can be marked as

Item Requests so that they can be used to populate an item request instead of having to enter it in from scratch.

• To populate a baseline catalog with an EDI-832 update, you would just copy the production catalog to baseline after the EDI-832 is imported.

• A contract must exist in CCM and be associated with the vendor before the vendor can start building baseline catalogs or sending in EDI-832s.

• The catalog must be linked to an ordering point to be visible to a customer.

• There is a sub-scheduling process in CCM where you can specify the date you want the catalog to go live for an ordering point.

o The catalog is only be displayed to the customer when the date specified in CCM is reached.

• Nothing happens without the master stock number existing.

• When the master stock number is entered for item in the Baseline catalog, then the details for the stock number are populated but are not editable.

STORES Vendor Item Catalog 11

• The EDI -832 is checked for a valid stock number and that the information is correct for that stock number.

• Troop Support should determine what the LSN should be for an item even though customers are sometimes give the LSN currently—which leads to the problem.

Catalog Deletions

• To delete an item from a production catalog, a prime vendor will submit an EDI-832 with items marked for deletion. There is an indicator in the EDI-832 to that identifies deletions.

• Item can also be manually marked for deletion by someone at DLA (either TVLS or CS)

• Items marked for deletion are removed from the catalog after the weekend catalog run.

• TVLS should notify the customer of deletions or trends that they identify from updates.

• Unlike adds or modifications, deletions don't have to be approved. DLA can, however, acknowledge the deletion.

• When TS acknowledges a deletion, they can also select a reason from a dropdown list.

• It was recommended that the future-state system support capturing a reason for a deletion at a later point in time (after it is acknowledged).

Baseline Catalog Statuses

• Baseline catalogs in STORES have one of four statuses:

o Being Built.

o Review Ready o Vendor Ready o Submission Ready

BPR Opportunities

BPR Short Description & Notes Priority

Different way to change statuses between baseline, production pending and production active catalogs? Why is work needed on baseline once catalog is in production? Should customer have any sort of view/input to a baseline catalog?

Production Catalog Submission Process via EDI-832

STORES allows EDI-enabled vendors to create or update a Production catalog by submitting an EDI-832

Catalog Update file from their order management system.

Subsistence Requirement Requirements Elaboration Why Needed Ability to submit a catalog electronically for review.

Ability to transmit a catalog from data in the vendor's system directly to DLA's system for validation and review.

DLA and vendors need an automated process for the vendor to submit a catalog for validation of items and review of prices.

STORES Vendor Item Catalog 12

Current State Process

1. EDI vendor transmits EDI-832 Catalog Update to create initial production catalog.

If file is processed without errors, the catalog update is set to “Pending” status. Any catalog updates received from the vendor after 12:00 PM ET on Friday will not be processed (or reviewed) until the following week (after the Sunday 12:01 AM ET production update has run).

2. EDI vendor transmits EDI-832 to DAAS through their own 3rd party VAN.

If transmission fails, DAAS notifies the STORES team so they can notify the vendor.

3. DAAS transmits to STORES (flat file).

If transmission fails, the STORES database is monitored by STORES DBAs and they notify STORES

POCs for action.

4. STORES validates the catalog.

If no errors are found, the update is assigned to an Approval queue for review and approval. If file contains errors, it is assigned to an On-Hold queue (CS can notify the vendor to act or vendor can check the status). Validation of the catalog update file is specific to the EDI-832 version used by the vendor.

5. Vendor can continue to send EDI-832 Catalog Updates until the catalog is validated by the system for approval.

Updated records in the file will overwrite previous validations of the same record.

6. The Catalog Warning Error Update Report details records in the pending production catalog that were updated without warnings, updated (but with warnings), and records that were not updated due to errors with the data.

This report is not available to prime vendors within the STORES application but DLA Troop Support

(CS or KO) will email it to the vendor. The data in the report is overwritten each time an EDI-832 is submitted. Once the catalog is updated (either through normally scheduled weekend run or special run), the report is removed from the system.

The EDI-832 Submission process is captured in Appendix A: Baseline Catalog Update & Approval Process.

Key Learnings from Requirements Discovery

• Vendors are only required to include changes (adds, mods, deletions) in the EDI-832. They are not required to send the entire catalog.

• EDI-832s submitted after 12 pm EST on Friday will not be sent to TVLS for approval until after the weekly catalog update process is run on Sunday.

• Most Vendors use their own 3rd party VAN to connect to DAAS.

• Vendor or 3rd party VAN may not be set up to handle failure notifications from DAAS.

• Only errors will prevent the EDI-832 from proceeding to the approval process. Warnings are reported but do not prevent the EDI-832 from being reviewed for promotion to production

"active".

• In rare cases, the flat file can fail to process during ingestion into STORES. STORES DBA monitors process and will notify DLA Troop Support via email indicating why the flat file failed to be imported by the database.

STORES Vendor Item Catalog 13

• Warning submissions are a subset of the update submissions, but the warning messages are unique to the Catalog Warning report.

• EDI-832 Versioning o There are three versions of the 832 (v1, v2, and v3).

o The goal is to get vendors updated to version 3 as there is more data.

o Version is set in CCM o Version 2 and 3 are similar (difference being CONUS/OCONUS) o EDI Translator at DAAS o Check at STORES is much more complex.

• EBS does not allow different Purchase Ratio Factors (PRFs) to be defined for a stock number on different catalogs from the same Vendor. Therefore, STORES must prevent this from happening.

o STORES currently checks for this condition when an EDI-832 is ingested into the system and requires a correction from the vendor if it does exist (PRF in incoming record is checked against existing records).

o If PRF for stock number in the EDI-832 import is different from the PRF for the stock number in the published catalog, then the system does one of the following:

▪ If the affected stock number only exists in the one vendor catalog, then the system allows the PRF for that item to be updated.

▪ If the affected stock number exists in more than one vendor catalog, then those records must be deleted and the vendor must send in another EDI-832 to assign the correct PRF to those catalogs.

o The future state system may want to prompt the user to update the PRF for all existing records if they are different from what is being imported.

• The Catalog Update report does not capture updates from the previous week and so the vendor needs to run the report weekly on Friday.

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for catalog submissions:

BPR Short Description & Notes Priority

Better process for submitting/validating

EDI-832

Is there a better process than submitting EDI 832? Better way to differentiate between transmission errors and content errors? Can there be notifications to the vendor through the system? Should validations be line by line or whole catalog checks/validations? Should there only be one version standard - have checks on optional fields?

Upon approval, send automated response to EDI-enabled prime vendors detailing which items were approved or rejected in the update

There is a tight schedule from Wednesday to Friday for the TVLS and CS to review and communicate rejections back to the vendor and then receive corrected updates in time to approve and still make the Friday cutoff time for that week’s approved production updates. Providing EDI-vendors with near real-time status on their EDI-832 updates would speed up the resubmission process. The most discussed approach for the message type is to send an email to the vendor with the LSN approval/rejection details. Email could be set up go to each vendor user associated with the catalog.

STORES Vendor Item Catalog 14

Enhanced pricing support

Can there be more pricing elements besides product price and distribution fee/price? For example, freight fee is built into distribution in OCONUS, but not CONUS?

PRF Update Process EBS does not allow different Purchase Ratio Factors (PRFs) to be defined for a stock number on different catalogs from the same Vendor. Therefore, STORES must prevent this from happening.

This BPR is to look for improved process for vendors to update PRFs when this condition is discovered. This issue and BPR opportunity are discussed in more detail in the previous section.

Production Catalog Approval Process

Any updates to a production catalog, whether submitted in STORES or through an EDI-832, must be approved by DLA Troop Support.

Subsistence Requirement Requirements Elaboration Why Needed Ability for DLA to validate and review vendor's catalog submission prior to catalog being active.

Ability for DLA to compare item details to master catalog information. Ability to review pricing for fair and reasonable determination. Ability to have a dual approval process based on roles and responsibilities.

Ability to do mass approvals.

DLA needs to vet the items on a catalog prior to it being active and the customers being able to view them.

Current State Process

1. TVLS approves/disapproves each item based on all information except for pricing.

Review and approval is done in STORES.

2. CS approves/disapproves each item based on pricing.

Review and approval is done in STORES.

3. KO approves the pricing offline before CS approves in STORES.

4. Production Catalog is activated one day before the catalog's effective date entered in STORES

CCM.

5. Catalog update runs at 0001 Eastern Standard Time (EST) Sundays at which point the catalog is now active.

Key Learnings from Requirements Discovery

• Pending catalogs (whether submitted from baseline or through an EDI-832) must go through the approval process.

• TVLS and CS should verify all items in update were previously approved through the Item

Request process before approving catalog update.

STORES Vendor Item Catalog 15

• TVLS and CS can see pending catalog updates that they need to approve (they can set up to 25 catalogs to watch in Preferences)

• Currently no way to see if counterpart has done their approvals without looking at catalogs individually.

• TVLS and CS Admins are able approve single items (LSNs) or all items in the catalog update.

Approved items will be published in the next update while items that are not approved will remain in a "pending" state. This capability is important to maintain in the future state.

• The Contracting Officer (KO) approves the pricing offline in SharePoint before the CS approves in

STORES (KO does not approve in STORES directly but has the final say as to whether a catalog is approved).

• Deletions do not require approval but the TVLS is expected to acknowledge them.

• Each catalog in CCM is supposed to have an assigned TVLS, CS, and KO. This would be an easy way for the system to automatically determine which catalogs an Admin type should be able to view. The problem with this today is that the assignments in CCM are not kept up to date.

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for the catalog approval process:

BPR Short Description & Notes Priority

Determine update process for production catalogs.

Different way to change statuses between baseline, production pending and production active catalogs? Why is work needed on baseline once catalog is in production?

Include approval number from Item Request Process for adds to a catalog

Tie any adds in an EDI-832 to an approval number from the item request process if it is a prime vendor catalog. This way the TVLS or CS doesn’t have to take additional steps to verify the item.

When viewing catalog updates needing approval, identify if counterpart has approved on their side

Allow the TVLS to see each catalog update that the CS has approved (and vice versa) without having to look at each catalog update individually.

Create Catalog in EBS

Once a catalog update is published to the live production site, a copy of the catalog is transmitted to EBS so that orders can be processed.

Subsistence Requirement Requirements Elaboration Why Needed Ability for DLA to create the catalog in the financial system or record.

Ability to create the catalog with all the appropriate information from STORES in EBS so orders can be correctly matched to items.

DLA needs to be able to push item information from the feeder system to the financial system so orders can be created.

STORES Vendor Item Catalog 16

Current State Process

1. STORES transmits catalog to DAAS (flat file).

If transmission fails, DAAS notifies STORES DBAs for action.

2. DAAS transmits catalog to EBS (EDI-832).

If transmission fails, it is unclear if anyone is notified but the STORES team can investigate.

3. Catalog IDOC (TQ-INT-0301) is created by middleware translator and then ingested by EBS.

If IDOC creation fails, it is unclear if anyone is notified but the STORES team can investigate.

Successful processing of the IDOC will update item pricing, PRF, and other data in EBS. PRF creation can affect orders, but pricing information comes from the order IDOCs, not from any pricing tables updated in EBS by the catalog update.

4. IDOC updates master record in EBS.

If IDOC fails, TQ BPA is notified for resolution.

More information on the transmission of the catalog update file from STORES to EBS is provided in

Appendix A: Baseline Catalog Update & Approval Process.

Key Learnings from Requirements Discovery

• STORES sends flat file to DAAS as part of daily batch process.

• DAAS processes flat file and generates ANSI X-12 standard EDI-832 Catalog Update.

• If processing at DAAS fails, DAAS communicates the failure to STORES DBA team.

• A middleware translator application used by DAAS, converts the EDI-832 into an IDOC format for ingestion by EBS.

o There is a question as to whether failures converting the EDI-832 to IDOC format are captured at DAAS.

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for catalog updates sent to EBS via DAAS:

BPR Short Description & Notes Priority

Better integration between DLA feeder systems, STORES, and

EBS.

Is there a better way to make sure updates from DLA's feeder system to EBS happen?

Better way of capturing post-transmission errors at DAAS and EBS

Is there a way to ensure all errors are identified and corrected?

View Catalog in STORES

The following table details the business requirements for viewing catalogs in STORES.

STORES Vendor Item Catalog 17

Subsistence Requirement Requirements Elaboration Why Needed Ability for Customers to view catalog items.

Ability for Customers to view geographically grouped catalogs and search for specific items through a variety of ways. Specific item can only be on one catalog in a geographic grouping.

Customers need to be able to view items on various catalogs to be able to order.

1. Customer can view any catalogs they are linked to via their assigned ordering points.

2. Customer selects View Catalog to view all catalogs and items based associated with their selected ordering point.

Customer can change ordering points to view other catalogs (can view one catalog at a time and sort by different fields).

3. Customer can download one catalog at a time in Text (.txt) format or all catalogs at once in Excel format (.xls).

4. Customer selects Search Catalog to search by different fields for a specific item on the associated catalogs

Search can be executed against a single catalog or all catalogs.

5. Customer selects View Master Catalog to view item information separate from a specific VIC.

6. Vendor can view any catalogs they are linked to via their assigned cage codes/catalogs.

7. Vendor selects View/Modify Production Catalog to view all catalogs and items.

8. Vendor selects View Master Stock Number to view item information separate from a specific VIC.

9. Vendor selects View Master Catalogs to view item information separate from a specific VIC.

10. DLA can view catalog reports in Admin.

Report include Catalog (current active), Catalog Snapshot (specific date), Ordering Point Items

(multiple geographic catalogs), and Hidden Items (on a specific ordering point and/or catalog number(s).

11. DLA can view catalogs and catalog reports in Catalog - various baseline, production pending, and production active (depending) catalog fields and associated reports.

12. STORES runs a duplicate item report to identify if an LSN is on more than one catalog linked to a specific ordering point

A specific item should only be offered by one vendor per delivery location.

STORES Vendor Item Catalog 18

Key Learnings from Requirements Discovery

• A catalog becomes viewable to a customer once it is assigned to the customer's ordering point and the "publish date" has been set in CCM is reached. This is normally done before the catalog update is processed.

Item Request Report

• Shows every request whether it was submitted or not.

• Unsubmitted requests are not available to view in STORES.

• Report data is manipulated in Excel (using pivot tables) - Item Add Requests.xls.

• All the data in the report comes from the weekly STORES Item Request Report

• Report sent out by Subsistence Team has a lot of data in it (one example had 14K+ rows)

• These spreadsheets are available to DLA TS in TEAMS folder under Item Reports.

• Spreadsheet is sent to senior leadership and branch chiefs to help guide their workload.

• All report views in spreadsheet can be filtered by request submit date.

• Dropdown lists any date a request was submitted. If request was not submitted, it is blank

(these are filtered out).

• Can filter on statuses. Lauren takes out all that are completed (requests that are not active

[approved, accepted rejection, deleted before completed).

• Total Requests Processed/In Process: All requests regardless of status.

• Lauren's report is critical tool for TVLS's and contracting.

Catalog Workload Report

• The Catalog Workload Report is a hard copy report sent out on Thursdays and Fridays that lets users know what catalogs need to be approved but it is not real-time.

o It lets users know what catalogs need to be approved but the data is not in real-time.

o BPR opportunities discussed for the catalog workload report include the following:

▪ Making it available in Qlik

▪ Updating it more frequently so the data is more timely

▪ Allowing it to be filtered by region so TVLS and CS can more easily determine actions they need to take for their catalogs.

▪ Make report available immediately after weekend update so that Subsistence can immediately see what was done and not done.

Catalog Change Report

• The Catalog Change Report shows changes between the data in the catalog update and the production catalog.

o Customers have access to this report but they may not be aware or use it.

o Is there a better way of notifying customers of changes than the Catalog Change

Report?

o Is there a better way to determine trends?

Historical Reports

STORES Vendor Item Catalog 19

• Subsistence would like the ability to access historical reports in the future.

• Troop Support would like to be able to view the Catalog Update Error & Warning Report at a particular point in time (e.g., enter in date and time that the data should reflect and click generate).

Recatalog Advice Report

• Compares the item to the standards (master stock number data) and highlights differences.

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for viewing catalogs:

BPR Short Description & Notes Priority

Better way to view product/item brand info? Way to view images -directly attached or carried over from item request process? Better way for Unit of Issue/Unit of Measure conversions (PRFs) - UoI still needed by services (tied to ordering/inventory)? Better way to prevent duplicate items on geographically grouped catalogs? How should items be defined - LSNs, SKU, Part #, GTIN, FIC, etc. - or multiple ways (ties into barcoding/overlap with Catalog Management group)?

Catalog Exports

The following requirement captures the need for the system to allow customers from the Military

Services to export a catalog in a format that can be imported into their Food Service System (FSS).

Subsistence Requirement Requirements Elaboration Why Needed Ability for Customers to export a catalog to their Service System.

Ability for Customers to be able have their Service System updates with the latest catalog information from DLA.

Customers that order through a Service System need to have to most accurate catalog information - items and pricing.

1. Customer can export any catalogs they are linked to and update their Service System.

2. Customer selects Export Catalog to export all catalogs and items regardless of the ordering point they are currently under.

Export is a text file formatted for their specific Service System. It can be a single text file or a Zip file with multiple text files if they selected multiple ordering points. Customer can also download a catalog (text or excel format), but the fields are slightly different than the export and they can only download catalogs on the currently selected ordering point

STORES Vendor Item Catalog 20

3. Select customers get catalog information directly transmitted to them.

These are specially designed transmissions, not standardized (Air Force process; soon to be Marine

Corps process; and potentially a new Navy process).

Key Learnings from Requirements Discovery

• Baseline catalog can be exported to a spreadsheet or flat file (.txt) that the customer can import into their system.

• There is a need to ensure that when a production catalog is updated in STORES, that the catalog is immediately updated in the Service System. Orders created from an outdated catalog in the

Service System can cause issues with order processing in EBS, thereby requiring manual intervention to resolve.

BPR Opportunities

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

BPR Short Description & Notes Priority

Automated interface for updating catalog in

Service system

Different type of transmission (EDI)/direct interface?

Hide Catalog Items

The following requirement captures the need for DLA to hide/unhide items from customers based on their ordering point.

Subsistence Requirement Requirements Elaboration Why Needed Ability for DLA to hide specific items from specific customers.

Ability to hide items based on specific Service requirements;

seasonality; not in stock status;

or multiple other reasons.

DLA needs to be able to restrict certain customers from viewing/ordering specific items as needed.

Current State Process in STORES

1. DLA can hide items from specific customers by ordering point.

2. TVLS selects Hide Catalog Items (Manual) or (Copy), selects catalog, ordering points and specific items to hide/unhide.

3. Items can be hidden/unhidden at any point for various reasons.

Key Learnings from Requirements Discovery

• Items can be hidden from customers based on their ordering point.

STORES Vendor Item Catalog 21

• In the current state system, this is done in CCM (Production Catalog Maintenance->Hide Catalog

Items (Manual).

• The hiding and unhiding of items are immediately reflected in the production catalog

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for hiding catalog items:

BPR Short Description & Notes Priority

Advanced options for hiding/unhiding items

Way to hide by a specific delivery location? Logic to hide seasonal items? Hiding vs. requesting item again in future?

STORES Vendor Item Catalog 22

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

Item Request process in STORES.

The current state Item Request process flow for STORES is documented in the following appendices:

• Appendix B: Customer-Initiated Item Request

• Appendix C: Vendor-Initiated Item Requests

STORES houses SPV catalogs from which customers order items. Any new items submitted by a vendor on a catalog update must first have been requested by a customer and then approved by DLA’s Item

Request process. Likewise, DLA Troop Support Subsistence personnel should not add any items onto the catalog without the same approval process being completed and the Vendor acknowledging the item should be added.

There are three types of item requests in STORES:

• Customer-Initiated Item Requests – Brand new item that the Customer wants cataloged.

• Vendor-Initiated Item Change Request – Existing item on the catalog where the Vendor is changing an aspect of its characteristics (Supplier, Description, Units Per Pack (UPP), Average

Weight, etc.). Requires a new LSN.

• Vendor-Initiated Item Replacement Request – Existing item on the catalog where the Vendor is only changing the Part Number. Does not require a new LSN.

Customer-Initiated Requests

The following requirement captures the need of STORES customers to request new items be added to a catalog or catalogs.

Subsistence Requirement Requirements Elaboration Why Needed Ability for Customers to request a specific item be added to a specific catalog.

Ability for Customers to request one or multiple items be added to one or multiple catalogs they are associated with. Need to be able to include reason needed, estimated usage, and approval from their proper authorities.

Ability for Vendors to offer an item to meet the Customer's request and supply all information and documentation for the item.

Ability for DLA to review the item/information and approve or reject that it can be added to a catalog.

DLA/Customers/Vendors need a traceable and auditable way to add new items to a catalog.

STORES Vendor Item Catalog 23

Current State Process

1. Customer creates item request based on their requirement, service approval, and estimated usage.

2. Customer selects Create Item Request (single item for single catalog) or Create Multi Item Request

(up to 10 items for one or more catalogs) and enters all required information - can save and submit.

3. Customer selects View/Modify Item Request to see a request's status or to modify/submit a request if it was only saved previously.

4. Submitted request passes through stages to Vendor, TVLS, TQ, NAPA/MPA, CS, KO for final approval.

5. Vendor submits an item to meet the customer's request with all required information and documentation.

6. Request can be rejected back to any stage for modification or a request can be terminated (and archived)

7. All stages can add additional comments to the status/comment log at any point - selected viewability.

8. All requests once complete are archived for auditability - reporting functionality built off of this.

See Appendix B: Customer-Initiated Item Request for a visual representation of this process.

Key Learnings from Requirements Discovery

• Customer Item Requests must be submitted in STORES. This allows Item Requests to be viewed at any point between creation by the Customer and final approval by the KO, providing full visibility and transparency of the process in STORES.

• Customer determines the item they want and receives authorization from their Approval

Authority.

• If the Customer wants a specific item, they or the Approval Authority should consult their Service Buyer’s Guide to determine if the item meets their service requirements before any submission is made.

• If the item does not meet the service requirements or the Approval Authority disapproves the item for any other reason, then the process ends.

• Customer creates a new Item Request in STORES by filling out all required information (should be as detailed as possible).

• Approval Authority documentation is required for:

• Navy and Air Force Customers in CONUS.

• All Customers in OCONUS.

• Navy Master Load List (MLL) items are automatically authorized for Navy MLL users and documentation can be a form letter.

• After submission, the Customer receives an email notification and can check the request progress throughout its life cycle.

• Once a

Item Request Comparison:

• Screen highlights any discrepancies between what was requested by the customer and what is being recommended by the vendor.

• Discrepancies are marked with a red “!”

STORES Vendor Item Catalog 24

• Item request comparison tracks the evolution of an item through the request process.

• When item information is updated and saved by any contributor in the review process, the comparison screen is updated to reflect it.

STORES Item Request Report

• Shows every request whether it was submitted or not.

• Unsubmitted requests are not available to view in STORES.

• Lauren takes report and manipulates the data in Excel (using pivot tables) - Item Add

Requests.xls.

• Report sent out by STORES Team has a ton of data in it (example we looked at had 14K+ rows)

• These spreadsheets are available in TEAMS folder under Item Reports.

• Lauren sends spreadsheet to senior leadership and branch chiefs to help guide their workload.

• All report views in spreadsheet can be filtered by request submit date.

• Dropdown lists any date a request was submitted. If request was not submitted, it is blank

(these are filtered out).

• Can filter on statuses. Lauren takes out all that are completed (requests that are not active

[approved, accepted rejection, deleted before completed).

• Total Requests Processed/In Process: All requests regardless of status.

• Lauren's report is critical tool for TVLS's and contracting.

• STORES Item Request Reports includes all requests whether they were submitted or not.

o Unsubmitted requests are not available to view in STORES.

• All data in her report comes from the weekly STORES Item Request Report

Approvals

The following describes each step in the approval process for a customer-initiated request, including the role responsible.

• Item Request Submission: Customer creates a new Item Request in STORES by filling out all required fields and submits the request.

• Being Built by Vendor: Vendor receives the Item Request and submits their item to DLA by filling out all required fields.

o Vendor must acknowledge request from customer

▪ Changes request status from “not acknowledged” to “acknowledged”

• Initial TVLS/Contract Specialist Review: TVLS reviews the Item Request to make sure the

Vendor’s submitted item meets the Customer’s request (this is a very basic review – Ex. Item should not be peas if the Customer wants carrots) and that the attached documentation (from both the Customer and Vendor) is legible and matches the submitted item.

• Tech Quality Review: Cataloging reviews the Item Request to verify that it meets the Service

Buyer’s Guide requirements and assigns an LSN. Cataloging has up to 5 business days to assign an LSN if the item is not identified as having a NAPA/MPA discount and up to 10 business days if the item should have a NAPA/MPA discount.

• Final TVLS/Contract Specialist Review: CS reviews the Item Request to confirm the item meets

F&R pricing. OCONUS F&R team can perform this step as well.

STORES Vendor Item Catalog 25

• KO Review: KO reviews the Item Request and confirms the item can be added to the SPV catalog. KO has up to 5 business days to accept or reject the request.

• Once an Item Request is approved by the KO, the following occurs:

o The request is removed from the pending request list.

o Notifications are sent to the customer and vendor informing them of the approval and the assigned LSN. (This only means the item is approved to be added to the catalog, not that it is now on the catalog.)

Item Rejection Notes:

• A Vendor can reject an unsubmitted request back to the customer as necessary. However, once the vendor submits the request, they can no longer reject it but it can be rejected by the TVLS, Tech Quality, or the Contracting Officer during their review.

• An Item Request can be rejected at any stage by the current approver back to any previous stage for a legitimate reason.

• Reasons for Rejection should always be given and should be recorded in the Status/Comment

Log as well.

• Previous stages can request an Item Request be rejected back to them for edits.

• There are two types of rejections:

• Reject with Recourse should be resubmitted for action.

• Reject without Recourse cannot proceed and must be accepted by the Customer to end the process. Once a customer accepts a rejection, the request is removed from Item Requests but an archived copy of the request is saved in the system for historical/reporting purposes.

Approved Item Requests:

• Approved items are not automatically added to a catalog. The Vendor has a contractually obligated amount of time to add the item once it is approved.

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for customer-initiated requests.

BPR Short Description & Notes Priority

Improvements to

Notifications & Metrics

Should there be more notifications in the system? Should metrics be easily identified?

Vendor-Initiated Requests

The following requirement captures the need of STORES vendors to request changes to existing items in a catalog.

Subsistence Requirement Requirements Elaboration Why Needed

STORES Vendor Item Catalog 26

Ability for Vendors to request a specific item be used to change or replace an already existing item on a specific catalog.

Ability for Vendors to request one item be changed or replaced by a new item on one or more catalogs on a cage code they are associated with.

Need to be able to supply all information and documentation for the item.

Ability for DLA to review the item/information and approve or reject that it can be added to a catalog. Ability for Customers to track the process and give input as needed.

DLA/Customers/Vendors need a traceable and auditable way to replace or make a change to an existing item on a catalog.

1. Vendor creates item request due to a current product changing/being discontinued - customer's requirement based on original item (must have been on the catalog within the last 90 days).

2. Vendor selects Create Item Request (single item for one or more catalogs with their cage code) and enters all required information and documents - can save and submit.

3. Submitted request passes through stages to TVLS, TQ, NAPA/MPA, CS, and then KO for final approval.