BRD-STORES2-CatalogManagement-Draft1.pdf

i

Defense Logistics Agency

FedMall

STORES 2.0 CATLOG MANAGEMENT

Business Requirements Document (BRD)

Version 0.1 - DRAFT

Last Update: September 12, 2023

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

STORES Catalog Management i

Table of Contents

EXECUTIVE SUMMARY

SCOPE

REQUIREMENTS

STOCK NUMBER CREATION & ASSIGNMENT

ESTABLISH STOCK NUMBER

MAINTAIN E SERIES SPREADSHEET

Key Learnings and Notes BPR Opportunities

STOCK NUMBER BUILT WITHIN EBS (SYSTEM OF RECORD)

Key Learnings and Notes

EBS TRANSFERS LSN TO STORES

Key Learnings and Notes

FINALIZE STOCK NUMBER IN CATALOG SYSTEM

STOCK NUMBER MAINTENANCE

MAINTAIN ITEM CLASSIFICATION CODES (ICCS)

BPR Opportunities

MAINTAIN DISTRIBUTION FEES

MAINTAIN MASTER STOCK NUMBERS

Maintain Unit Data Maintain Detailed Descriptions of each Master Stock Number Maintain Standardization Levels for Each Master Stock Number Maintain Status Designations Maintain Sub Catalog Types Maintain Service Core Items Maintain Item Weight Data Master Stock Number Filtering

VIEW/PROCESS ITEM REQUEST PROCESS

Service Requirements

UNITIZED GROUP RATIONS (UGRA) MAINTENANCE

Maintain UGRA Master Menus Maintain UGRA Vendor Menus Standards Maintenance on Active Production Catalog

MAINTAIN CORE CATALOG

Key Learnings and Notes

MANUFACTURER MAINTENANCE

MAINTAIN MANUFACTURER INFORMATION

Key Learnings and Notes

MAINTAIN NAPA AGREEMENT ALLOWANCE

Key Learnings and Notes

MAINTAIN MPA MONTHLY IMPORT SUBMISSIONS

Key Learnings and Notes

IMPORT MPA SUBMISSIONS

Key Learnings and Notes

MERGE MANUFACTURERS

STORES Catalog Management ii

Key Learnings and Notes

CORE CATALOG REPORTS IN QLIK

Report: BDFA (Basic Daily Food Allowance)

REGION MAINTENANCE

MAINTAIN REGIONS

APPENDIX A: STOCK NUMBER CREATION & ASSIGNMENT

APPENDIX B: CUSTOMER-INITIATED ITEM REQUEST

APPENDIX C: VENDOR-INITIATED ITEM REQUESTS

APPENDIX D: GLOSSARY OF TERMS

STORES Catalog Management 1

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.

This Business Requirements Document (BRD) covers the functional areas associated with Catalog

Management, which include stock number creation and management, manufacturer maintenance, core catalog, pricing and distribution fees. 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 9, 2023, with the last regularly scheduled meeting ending on July 12, 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 Specification

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

The Functional Specification 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 Functional

Specification and the client agrees to find the product satisfactory if it does. Completing the

Functional Specification 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 Functional Specification. 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 deliverables in the final buildout back to the requirements agreed to in the

Functional Specification.

STORES Catalog Management 2

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 Catalog Management Functional

Specification document. 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 Specifications 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 catalog management capabilities in the FedMall system is dependent on completion and acceptance of the Functional Specification and resulting implementation requirements (user stories, design comps, and acceptance criteria). Therefore, a precise timeline for building out the catalog management capabilities in the FedMall domain has not been determined, although initial development is anticipated to begin at the end of Quarter 2 in FY2024.

STORES Catalog Management 3

Requirements The business requirements in this document are organized under the following functional areas or modules:

• Stock Number Creation & Assignment

• Stock Number Maintenance

• Manufacturer Maintenance

• Region Maintenance

The business requirements and BPR opportunities included in this document were initially captured in the notes taken for each IPT Working Group meeting held during requirements discovery.

These notes are in MS Word format and can be found in the Catalog Management working group folder on the DLA Teams site.

The stock number creation and assignment process is documented in:

• Appendix A: Stock Number Creation & Assignment

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 Catalog Management 4

Stock Number Creation & Assignment This section documents STORES business requirements related to creating and maintaining stock numbers.

The process for establishing a stock number and assigning it to an item of supply is documented in:

• Appendix A: Stock Number Creation & Assignment.

A stock number is a unique identifier for DOD sources of supply that are regularly procured, stored, and consumed, such as subsistence items. The following identifies the different elements of a stock number:

Element Description Federal Supply Class (FSC) Established by DoD/FLIS depending on what the product is.

Country of Origin Two-digit country code (01 – domestic).

E Series Number Established based on use/sale of product.

Unique ID Given/established by TQ and maintained on an Excel spreadsheet.

Establish Stock Number

Stock numbers are created and managed by the Tech Quality (TQ) and Catalog team in an Excel spreadsheet. Providing the stock number with all necessary information it to be orderable in STORES requires TQ to input information into EBS and STORES.

Maintain E Series Spreadsheet

The first step in establishing a stock number is to reserve it in the E Series spreadsheet. This spreadsheet is updated and maintained by the TQ team.

STORES Catalog Management 5

The following table defines the rules or requirements for stock number creation in the E Series spreadsheet.

Subsistence Requirement Requirements Elaboration Current Process in STORES The FSC needs to be defined as the first 4 position numbers

(determined by DoD/FLIS depending on product).

So that unique NIINs are maintained. a NIIN is the last 9 positions of the stock number.

External to STORES (spreadsheet) opportunity to automate in new modernized systems solution.

The 01 is a country code Identifying US E Series Number (or SUBS ID) based on type of item (Prime Vendor, Market Fresh, etc.).

So that unique NIINs are maintained. a NIIN is the last 9 positions of the stock number.

External to STORES (spreadsheet) opportunity to automate in new modernized systems solution.

TQ needs ability to add/edit/delete LSN Subs ID (series) 3 position alphanumeric ID which represents positions 7- 9 of the stock number, enter/edit a description for each sub ID. Must prevent deletion of subs id if subs id included in ANY master stock numbers).

So that unique NIINs are maintained. A NIIN is the last 9 positions of the stock number.

External to STORES (spreadsheet) opportunity to automate in new modernized systems solution.

TQ needs a 4-position numeric serial number counter 0000- 9999.

So that the item of supply is uniquely identified from other items of supply. The NIIN (last nine digits of the stock number) must be unique from other NIINs and must never change for that item of supply.

External to STORES (spreadsheet) opportunity to automate in new modernized systems solution

Key Learnings and Notes

• Four main activities on spreadsheet o Creating Service’s Requirements o Item request o Establish Stock Number o Maintain Master Stock Number

• Stock number format:

o NIIN is last 9 positions of stock number

▪ 8950********* (Federal Supply Class “FSC”) established by DoD/FLIS depending on what the product is

▪ ****01******* (Country Code) 01=domestic – should be added to spreadsheet

▪ ******E40**** (E Series number) Established based on use/sale of product

▪ *********#### (last four of LSN are unique. Given/established by TQ and maintained on an excel spreadsheet located on KDrive (shared drive).

• Subsistence uses about ten total FSCs (grouping of item)

STORES Catalog Management 6 o 8905 - Meat item o 8910 - Dairy

▪ Dropdown could be used in spreadsheet to capture FSC code

• Each NSN is unique

• One NSN can apply to more than one manufacturer

• If E Series is E62 then Subsistence knows it's a NAPA item. If it's E40 then its generic

• 0000-9999 - take the next available for E-Series when assigning

• Provide vendors, customers, and employees with an abbreviation key/legend o Helps others understand o Could have a new function that automatically shows/explains abbrev.

o Upload FSC/E Series list to system

BPR Opportunities

The following BPR opportunities are in relation to the E Series spreadsheet.

BPR Short Description & Notes Priority Incorporate E Series Spreadsheet into Future State System

Develop online capability to establish, issue and manage stock numbers.

Display abbreviation meanings to users.

Provide vendors, customers, and employees with an abbreviation key/legend .

• Helps others understand

• Could have a new function that automatically shows/explains abbrev.

Stock Number Built within EBS (System of Record)

Stock numbers must be entered in EBS and other fields for the record must be created and linked before orders can be placed for the stock number in STORES. The following requirements apply to the creation of the stock number in STORES.

Subsistence Requirement Requirements Elaboration Why Needed TQ needs to build eMaterial number in EBS (MM01)

EBS is the system of record.

Process should start and end here.

There is none.

TQ Needs to link LSN to eMaterial Number in EBS

(VB11).

EBS maintains its own material master number which is not is the format of DLA/military's stock #.

NSN/LSN entered into EBS.

Key Learnings and Notes

• EBS is the system of record. The process starts and ends here

• Unit of issue is set in EBS and should not change

STORES Catalog Management 7

EBS Transfers LSN to STORES

The following business requirement relates to the transfer of LSN data from EBS to STORES.

Subsistence Requirement Requirements Elaboration Why Needed EBS passes information for LSN into STORES.

Provide interface for importing Master Stock Number Catalog file from EBS with updated LSN information, including the eMaterial #, and UoI.

This is needed to push the LSN and Unit of Issue into the Cataloging System. This creates the shell of the stock number record before the TQ standardizes and finalizes it.

The following notes were captured in the IPT Working Group sessions:

• Need to document all fields currently being passed, and all that will need to be passed in modernized system.

• Also need to document the frequency/timing of the file transfer, file format, and the extent of error checking performed by STORES.

• Once the Master Catalog file with the new LSN is ingested into STORES, a partial record for the stock number is created in STORES with the information passed over from EBS.

Finalize Stock Number in Catalog System

The following requirement relates to the population and finalization of the stock number record in

STORES so that it can be added to a catalog and ordered by customers.

Subsistence Requirement Requirements Elaboration Why Needed Provide interface for TQ to populate Stock Number with all required fields (depends on level of standardization).

The Master Stock Number Maintenance screen is used by the current state system to create/update master stock numbers with all required information, including:

• Item Name (All Level STD)

• Item Description (All Levels

STD)

• Units Per Purchase Pack (UPP) (High Level STD)

• Package Size (All Levels STD)

• Package Unit of Measure (All Levels STD)

• Package Code (All Levels

STD)

• Vendor Unit of Measure (VUOM) (High Level STD)

So that customers can order a standardized stock number which can be added to the Vendor's Catalog via an 832.

Recipes, Pricing, Inventory, etc. rely on the accuracy of the fields that make up an LSN.

Required Fields differ from Catch Weight, NAPA, MPA, MPL, Core Catalogs).

STORES Catalog Management 8

• Purchase Ratio Factor (PRF) (High Level STD)

• PRF Lock (High Level STD)

• Item Classification Code (not required now, but should be)

• Once the stock number is created and the record is complete, the Stock Number must be set to

Active by TQ before it can be loaded on a catalog and ordered.

STORES Catalog Management 9

Stock Number Maintenance This section details business requirements for maintaining stock numbers.

Maintain Item Classification Codes (ICCs)

An Item Classification Code (ICC) is a five-character alphanumeric code grouping of food items associated with Attribute Values. It ties into a Stock Number, Distribution Fee Category, and PPI and provides additional defining attributes for the stock number.

The following business requirements relate to creation, maintenance, and assignment of ICC Codes.

Subsistence Requirement Requirements Elaboration Why Needed Need ability to define a one to five position item classification code, each subsequent position defining an additional level deep of the item classification hierarchy.

Build and maintain item classification hierarchy for use to properly classify master stock numbers.

So that master stock numbers are classified correctly.

Need ability to define/edit item classification code attributes.

Build and maintain item classification hierarchy for use to properly classify master stock numbers.

So that master stock numbers are classified correctly.

Need ability to define/edit all possible ICC attribute values related to an ICC attribute.

Build and maintain item classification hierarchy for use to properly classify master stock numbers.

So that master stock numbers are classified correctly.

Need ability to associate/disassociate ICC attributes to ICC codes.

Enables TQ to define a set of shared attributes that further define an ICC classification.

So that master stock numbers are classified correctly.

Need ability to export a list of filtered records to a spreadsheet file.

For external use outside of the system.

So that master stock numbers are classified correctly.

Associate an ICC code to a specific master stock #.

TS/Subsistence needs to be able to associate an ICC code to a specific master stock #.

To provide a higher-level classification and so that master stock numbers are classified correctly.

Need ability to assign attribute values associated to an ICC code which has been associated to a master stock number.

So that master stock numbers are classified correctly.

• Item Classification Code (ICC)

STORES Catalog Management 10 o Allows for “like” items to be searched and linked (for comparisons) o Can be drilled down to all descriptions o ICC tab can be viewed by all, but only changed by TQ o Assigned to be able to compare like items o Code assigned by using information about item on specification sheets and labels o ICC maintenance screen

▪ Where ICCs are built and maintained

▪ Broken down by standardization level and description of item

• Items can only have one level

• Attributes are assigned to the lowest level

▪ Around 56 attributes available and able to be assigned to ICCs o Does food service use ICCs?

▪ If so, what for and how?

▪ Possibly pricing?

o System can store around one year’s worth of ICC data

• PPI linked from ICC o ICC is assigned by user.

o System uses this info to assign a PPI o Allows for pricing maps within stores o PPI is more generic than an ICC

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for ICCs

BPR Short Description & Notes Priority

ICC Usage Report Would a report to determine if ICCs are used be helpful?

• Might be valuable to TQ

Maintain Distribution Fees

While creating a Baseline Catalog, each stock number is associated with a Distribution Fee Category and the appropriate distribution fee for that category. Post-Award, when a vendor submits a catalog update, the Distribution Fee Category and distribution fee are included for each item. A Distribution Fee

Category Source Code is a one-character alphabetic code representing a group to which a set of

Standardized Distribution Fee Categories are assigned (e.g., “C” for CONUS, “O” for OCONUS, “S” for

Contract Specific).

The following requirements relate to the setup of distribution fee categories.

Subsistence Requirement Requirements Elaboration Why Needed Support creation and maintenance of distribution fee categories.

TS/Subsistence needs to be able to set up distribution fee categories and codes that can be associated with distribution fees submitted by the vendor.

So that distribution fees can be grouped and categorized for reporting purposes. A distribution fee category is needed for each way a vendor is selling an item.

STORES Catalog Management 11

Key Learnings and Notes

• Distribution fees are set up per contract per option period. This is important because error checking in the item request process links back to this information in CCM where the distribution fee schedule is set up.

• Distribution Fee categories are tied to a specific unit of measure.

• Distribution fee categories are set by a specific unit of measure, such as pound or case.

• TS tried to have a one-to-one measure between the distribution fee category and unit of measure.

o There are cases where a specific distribution fee category (category of items) is being priced two different ways (for example, being sold by some vendors by the pound and some vendors by the case). These should be a one-to-one relationship. Otherwise, you cannot guarantee that the distribution fee on the contract schedule is going to match what is being sent in on the 832. If selling by bottle, then how many bottles are in a case. Some contracts may need to add some distribution fee categories.

o PV normally sells spices by the "each" and they had inadvertently removed "each" and instead had case. Each had to be re-added because PVs purchase by the case but sell by the each.

o PVs will prorate distribution fee (divide unit of measure that they are selling by (e.g., bottle or per by the unit of measure specified in the contract [e.g., case]).

o Could have category with different distribution fee for spice by case or spice by pound.

o There needs to be a human factor (reviewer)

• Need distribution fee category for each way a vendor is selling an item o Distribution category should be set correctly dependent on product

▪ 1:1 between distribution category and UOM

▪ If not, an additional element is needed to calculate the correct price (for example, spices are bought by case, and sold by each)

• Distribution Fee can be prorated by amount bought

Maintain Master Stock Numbers

This section provides requirements for supporting master stock numbers.

There are three types of fields associated with a Master Stock Number record:

• Optional: The data may or may not apply to the item record.

• Mandatory: The data always applies to the item record and must be defined.

• Standardized: If a standardized field is used, the data in the field must be matched by the LSN when a vendor submits a catalog update.

The following are mandatory (required) fields on the Master Stock Number Maintenance screen:

• UPPP – units per packaging

• UOI – unit of issue

• PK Code – packaging code

• PK UOM – packaging unit of measure

• PK Size – packaging size

STORES Catalog Management 12

• Vendor UOM – vendor unit of measure

• PRF – Purchase ratio factor = UOI/Vendor UOM

• Brand

• Item description/name

The following table details business requirements captured for the creation and maintenance of stock number records:

Subsistence Requirement Requirements Elaboration Why Needed Provide ability for TVLS to create, edit, and delete master stock number records and data.

Master stock number records simplify the process of adding items to a catalog (can populate new record with master stock number record).

Master stock numbers also ensure that the same item is defined consistently across STORES catalogs.

So that customers can identify an item and have confidence in what they are ordering in terms of quality, packaging, weights, measurement, units of issue, and so on.

Validate optional, required, and standardized fields when creating or updating a master stock number record.

There are three types of fields associated with a Master Stock Number record:

• Optional: The data may or may not apply to the item record.

• Mandatory: The data always applies to the item record and must be defined.

• Standardized: Standardized fields are not only mandatory but the data in the field must be matched by the LSN when a vendor submits a catalog update.

So that master stock number records are consistent and provide all necessary information needed by customers when ordering the item, and all information needed by a vendor to match an item.

Maintain Packaging Data for Each Master Stock Number

The following table details the business requirements for packaging data that is associated with a master stock number.

Subsistence Requirement Requirements Elaboration Why Needed Capture the following packaging information for a master stock number: UoI, Packaging Code, UPP, Packing UoM, Packaging

Size, Vendor UoM, PRF, Brand, Item Name/Description.

Defines the specific packaging detail.

TQ must be able to view/edit the master stock number data.

Non TQ Admin users should be able to view, but not edit this data.

Needed to define customer requirement when ordering, used for customer recipes, etc.

STORES Catalog Management 13

Key Learnings and Notes

The following notes were captured in the IPT Working Group sessions:

• Three fields on the right side of STORES master stock number screen under packaging tab o Evaluation of UoM o Qty of Eval. UoM per Vendor UoM o Qty. of Eval. UoM per UoI

▪ Populated automatically by system from other values entered by TQ

• In future, should be updated in real time

▪ System tries to fin the lowest common denominator to allow the comparison of like items.

• Largest advantage is price comparison

▪ Creates a price per OZ, FLO, of EA

• Comes from OZ/UoI

▪ Unit of issue pricing

• Used by contracting and others

▪ Populates in other reports as well o Like products can be liked using ICC – item classification code

▪ Code created and maintained by TQ

▪ Products are assigned and ICC by TQ from the given information in the specification sheet and label o TQ defines the values for the LSN, then vendor matches this standard

▪ Can be changed if LSN is brand new and not on any catalog

The following table provides a summarized description of BPR opportunities identified for maintaining the packaging data for a stock number:

BPR Short Description & Notes Priority

Provide users with access to glossary of terms and abbreviations.

New function could show/explain abbreviations or some type of glossary.

Enhanced Search Functions.

Would it be helpful to return other terms related to the search term when conducting a search? For example, searching for an abbreviation like "LT" would return items with “lite” (non-abbreviation) in their description, and vice versa.

Abbreviations are documented on the Subsistence website.

Provide vendors and/or customers with read-only access to Master Stock Number screen.

Should vendors/customers also have access to this screen or just the underlying reports generated from the master stock number screen?

STORES Catalog Management 14

Maintain Unit Data

The following requirement captures the need for the system to capture and maintain DLA Unit of Issue

(UoI), Vendor Unit of Measure (UoM), and the ratios between the two.

Subsistence Requirement Requirements Elaboration Why Needed Need ability to display DLA Unit of Issue (UoI). (Note: This field is exported from EBS as part of the Establish Stock Number activity. This field should never be editable once the initial value has been established.)

The UoI defines the unit the military inventories and buys an item in. This field often differs from unit that defines how the vendor sells and prices an item.

The UoI does not change throughout life of the record (maintained in EBS). If UoI has to change, a new stock number should be assigned.

Customers need to be able to understand and order items using units of supply they are familiar with (UoI in this case).

Need ability to maintain a standardized Vendor Unit of Measure (UoM).

The UoM defines the unit the vendor both prices and sells the product in.

Vendors needs to be able to create/update LSNs using units of supply they are familiar with (UoM in this case).

Need ability to maintain a standardized Purchase Ratio Factor (PRF).

The PRF defines the relationship between the unit of issue and the vendor unit of measure.

The system needs to capture the relationship between the Vendor Unit of Measure and Customer Unit of Issue.

System should automatically assign and calculate evaluation unit of measures for each master stock number.

Need to maintain comparable evaluation unit calculations so accurate price comparisons can be performed for like items with different unit of measures.

To ensure accuracy of price comparisons.

• DLA Unit of Issue (UoI) for a master stock number is defined in EBS and sent to STORES

• UoM – vendors are supposed to have a set list

• Purchase Ratio Factor (PRF):

o UOI is not supposed to change throughout life of record – maintained in EBS o If UOI needs to change, a new stock number must be assigned o Is there ever a time where the denominator is greater than “1”? if not, can we eliminate the 1 altogether with the understanding that the PRF denominator will always be “1”

• Could decimals be added into the PRF field o Non-integer o PRF Lock is populated by user o Error message (warning) is thrown if required fields are not populated

• STORES allows individual PRFs per catalog but EBS limits per CAGE code.

STORES Catalog Management 15 o Makes it difficult when changing a PRF for an item on multiple catalogs with the same CAGE code. Updates do not flow smoothly to EBS and items have to be deleted and then readded.

o Error checking is built in STORES to prevent this from happening. This same check will need to be built into the future state system.

o There used to be a report in STORES that would identify if different PRFs were associated with a stock number existing on multiple catalogs for the same vendor. User would reference report and then fix it in EBS.

o Fee/price management and PRF mismatch report are not used by TQ o The current state system checks for this condition when an EDI-832 is ingested into the system and requires a correction if it does exist (PRF in incoming record is checked against existing record).

o If the PRF associated with the record(s) on an existing catalog are determined to be incorrect, then they must be deleted and the vendor must send in another EDI-832 to assign the correct PRF.

o System requires that the PRF be the same for a given stock number across catalogs for a given Vendor (CAGE).

o Future state system may want to prompt user to update PRF for the existing records if they are different.

o UOI – info sent over from EBS to Stores o Can we list out of Greg’s spreadsheet o UOM – vendors are supposed to have a set list

The following table provides a summarized description of BPR opportunities identified for maintaining unit data:

BPR Short Description & Notes Priority

Adding decimals to the

PRF Field

Can decimals be added into the PRF field?

• Non-integer

• PRF Lock is populated by user

• Error message (warning) is thrown if required fields are not populated

Allow Users to Save PRF Data without Publishing

Is it beneficial/feasible to allow users to save their work and resume at a later time?

• Support a Save and Publish action o Save will save the work for the user o Publish will push it to the next step (or allow others to see)

Maintain Detailed Descriptions of each Master Stock Number

The following requirements relate to the descriptions provided for each master stock number.

Subsistence Requirement Requirements Elaboration Why Needed Need ability to maintain an

Extended Item Name which

Standardized item description used for matching vendor

The Extended Item Name is manually entered by TQ (in EBS and STORES).

STORES Catalog Management 16 describes the higher-level category of item (50-character limit in STORES) descriptions. Can only contain 80 characters (do we keep --ask customers). Vendor should try and match our standards.

Need ability to maintain an Extended Item Description which provides the verbose details that fully describe an item (240-character limit in

STORES)

Subs requires a longer description so everyone understands exactly what they are looking at.

The Extended Item Description is manually entered by TQ (in EBS and STORES). Descriptions need to be specific to decipher one product from another. Abbreviations are used to keep desc. short. Some Vendors are limited to certain number of alpha/numeric characters. QUESTION:

Do we need the extended item description, or can extra information be captured in the comment??

Need ability to maintain an 80-character Standardized Item Description

A standardized description is maintained to ensure a uniform description is applied across all vendor item catalogs.

The Standardized Description is enforced in multiple functional areas within STORES

Need system to automatically concatenate the extended item name and extended item description into the 80-character Standardized Description.

So that TQ does not need to manually re-type the Standardized Item Description

STORES performs the stated requirement as described.

Need system to detect when the concatenated extended item name and extended item description result in a truncated 80-character Standardized Item Description.

A standardized description is maintained to ensure a uniform description is applied across all vendor item catalogs.

STORES performs the stated requirement as described.

• Maintain detailed description o Truncated check box o Item name/description o Standardized item description used for matching vendor descriptions

▪ Can only contain 80 characters

▪ Do we want to keep or change

▪ Do we want to make the whole description available to customer? Or just the truncated version?

• Evan will reach out to services for opinions o Some vendors are limited to a certain number of characters, and are required to match

DLA Standardized description

▪ “Accepts Standards” field is available on EDI master – clicked if vendor agrees their product matches the standardized description

STORES Catalog Management 17

• All standardized fields have to match o Important for price comparison

▪ If this filed is not clicked, item will not show up as “standardized” on the report o 86 – 90% of descriptions match standards from an EDI perspective

▪ There are tools available to make this number closer to 100%

▪ Used to be only 12% before DLA started the standardization program o There is an analysis tool to pull the 10 – 14% of descriptions that are not standardized and tell the used why they are not

• Who owns the contracted item description?

o All items have to be approved by DLA before being used by customer o DLA can decide is Standards do not match, but still gets pushed through o DLA has the power to make changes to items (discouraged)

▪ because vendor agreed to standards o Any EDI changes must be communicated to the vendor

• Is there a need to have three different description fields?

o Setup was initially brought over from other system (EBS) o Makes it easier to group like items

• Name from Product Spec/Label

• Description from extra info given in request

• Descriptions need to be specific to decipher one product from another

• Abbreviations were created to help keep descriptions specific and short o List/glossary of abbreviations are located on Teams shared files, Subsistence Website, and KDrive.

• In the future, the glossary might be uploaded to system so one can search for items by both full words and abbreviations. Ckn = chicken

• Extended item name (50 characters)

• Extended item description (240 characters)

• Standardized item description (80 characters) o Combined extended item name and description

• Truncate check box o System automatically checks off box and truncates description if total character is over

80 characters o TQ uses a lot of abbreviations to keep the numbers of character in each description as low as possible

▪ Sometimes info gets dropped, but descriptions are as standardized as possible to avoid this

▪ Vendors are trying to match the standardized item description

• Mandate of business process – or determined by Service Legacy system

▪ Are Services still limited to the 80 characters for descriptions?

• Yes, locked in.

• We do not want to limit this number of characters anymore

• More characters = more precise standardization

▪ System creates a flag when description is over the 80-character limit

▪ User can go back into the system and change all three of these fields if system did not adjust them correctly

STORES Catalog Management 18

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for managing stock number descriptions.

BPR Short Description & Notes Priority

Predictive Text Fields Provide predictive text fields that will suggest abbreviations when typing in description.

Glossary Provide users with a glossary of terms and abbreviations (CKN=Chicken). See previous section (Key Learnings and Notes) for additional information.

Consolidate or Reduce the Number of Description Fields.

Is there a need for three different descriptions field? Evan will ask customers.

Maintain Standardization Levels for Each Master Stock Number

The following requirements relate to the linking of an item to a master stock number and inheriting the standards (such as the descriptions) defined for the master stock number.

Subsistence Requirement Requirements Elaboration Why Needed Need ability to mark whether an item is standardized or not.

Need ability to define whether an item is high level or low level standardized.

This bleeds into the Vendor Item Catalog. "Accepts Standards" is a field available on the EDI master. If clicked the vendor agrees their product matches the standardized description. If not clicked, the item does not show up as standardized.

TQ Admins can change Vendor item names and description (although this is rare). All items are approved.

Standardization defines exactly what a stock number is. Without this an item would be generic in nature and would not guarantee that the item the customer is ordering is what they are actually receiving.

Need to be able to denote when an item will be held to a High- Level Standardization

High level standardization is preferred. This includes all the packaging fields and ensures the item provides as much information as possible.

So that customers can complete confidence that they are ordering what they think they are.

Lower-Level Standardization Reserved for NAPA/MLL items.

Stock # is linked to one Vendor SKU (UPP, UoM, PRF all left blank). Manually set by TQ.

To allow standardization of items that do not include all information needed for high-level standardization.

Key Learnings from Requirements Discovery

STORES Catalog Management 19

• A change to the Master Stock Number record represents a change to the entire record as a whole—not just the LSN.

o Changes are infrequent due to high volume of use by customers, vendors, and others involved in the process.

• If vendors do not continue to match standards, an error is reported and the item is flagged.

• Is it easier to maintain standards in EDI or Online?

o Online

• Autofill is based off previously entered information.

o Does leave less room to play with

• High vs. Low Level Standardization o Most items are high level (95%) o Low-level standardization is used for MPL items (5%)

▪ Only require a few fields to be populated

• Some fields for a master stock number record (like item description) can be changed, while other fields (like packaging) should not change.

o Fields that do not change are known as "standardized" fields o Item records in catalog updates are checked to ensure they match "standardized" fields

▪ If they don't match then it produces an error preventing that item from being updated.

• Catalog item does not match standard:

o Used throughout Stores and QLIK to filter out such items o Standardization defined/completed by including as much information on the item as possible o Combined fields help determine when something isn’t standardized o Validation process also in use to make sure items are matching standards

Maintain Status Designations

The following table captures requirements for applying and maintaining statuses for Master Stock

Number records.

Subsistence Requirement Requirements Elaboration Why Needed Apply Master Stock Number

Statuses

Need ability to maintain five master stock number statuses:

Being Built, Active, Flagged- Phasing Out, Discontinued, and Retired.

It is important to be able to track and determine the status of a master stock number throughout its lifecycle so that it is only used when it is active and available for order.

Only Allow Master Stock Numbers with Appropriate Status(es) to be Published in Vendor Item Catalog

Prevent master stock numbers with a status of Being Built, Discontinued, or Retired from being added to vendor item catalogs.

To prevent master stock numbers that are still being created or are no longer available from being added to catalog for order by a customer.

Make sure that Active Stock Numbers contain all required information and standardizations.

Only allow standardized, fully defined stock numbers to be moved into an Active status.

To prevent items with partial or incomplete product data from being added to a vendor item catalog.

Allow stock number status changes to be scheduled

Allow users to set future pending dates and associated

So that user can specify the date while doing updates and not have to set a

STORES Catalog Management 20 pending status for a stock number.

reminder and come back into change the status.

Automatically change a stock number to active when the active date is reached.

System should automatically move the pending status to the active status when the pending date is reached.

So that user can specify the date while doing updates and not have to set a reminder and come back into change the status.

Key Learnings and Notes

The following notes were captured in the IPT Working Group sessions:

• There are five item statuses for a master stock number

• Being built

• LSN is in the process of being created, standardized, etc.

• Not allowed to be added to a catalog yet

• TQ changes status from being built to active once all required info is added

• Active

• LSN is ready for use: standardized

• Ready for use on a catalog

• Flagged/Phasing out

• LSN is on an active catalog, but is eventually going to disappear and not be used

• Discontinued

• Stock number cannot be added to any catalogs, but may be still present on old catalogs

• Warning flags thrown to deplete supply

• Retired

• LSN is obsolete and not on any current catalog

• LSN cannot be added to any future catalogs

• IF an LSN is in the “discontinued” status, and falls off current catalog, the system will automatically move the LSN from “discontinued” to “Retired” status

• System automatically runs this report and preforms every two weeks

• All changes to the status must be done manually by TQ, except for discontinued to retired.

• Status is most often changed when there is a manufacturer change to the product (NAPA items).

• Examples of changes are different pack-out size, SKU/part change, etc.

• Date is always given as to when status is changed (reflected in system)

• Future dates can also be set so status changes automatically when date arrives

• Stock number status is very important as it communicates to everyone involved where the stock number is in the process

• Need to define what the status is, why it is needed, and how the status is used in other areas of the system?

• Replacement stock numbers can be noted/added to a current LSN – added by TQ and used when other LSN is officially retired

• Replacement stock numbers are DIFFERENT from Acceptable replacements

• NAPA office/team sends out a report on which LSNs are being discontinued

• Will update and send out to vendors

• System sends to DLA; DLA then sends out to anyone who needs it

• Use of comment section – system added comments as well as users

• IAW or not IAW comments

STORES Catalog Management 21

• Waivers

• Updates on status

• Replacements

• EBS info

• MLL or MPL status

BPR Opportunities

The following table provides a summarized description of BPR opportunities identified for master stock number statuses.

BPR Short Description & Notes Priority Automatically remove discontinued stock numbers

Could there be a function for the system to automatically recognize, remove from catalog, and send out an email when stock numbers are discontinued/phased out/retired?

Maintain Sub Catalog Types

The following requirement captures the need to associate manufacturer information with a master stock number for an MPA or NAPA item.

Subsistence Requirement Requirements Elaboration Why Needed Need ability to associate manufacturer information to a master stock number for NAPA and/or MPA items.

There is a one-to one relationship between the NAPA/MPA item and the manufacturer.

So that the pricing of associated LSNs on Vendor Item Catalogs will be updated when pricing is changed for the master stock number.

• Maintain catalog subtypes:

o SubCat – Subcatalog type

▪ LSN, NSN, Market Fresh, non-food, MPL, MPA, OpRats, School Lunch, NAPA, grade certification, green certification, FSOS, FSE, Produce o ServCore – Service Core Items:

▪ Navy MLL, FIC, Cargo, Q-COG, BDFA, Wartime, Army Dining Army Field, AF, AF

Opt, Marine Corps

• Stores Maintenance – SubCat/ServCore o Associate manufacturer information – push button when item is a NAPA/MPA item, and associate info

▪ Standard Description

▪ Stock Number

▪ MFR Code

▪ SKU

• SKU is part of the UPC (unique product code)

STORES Catalog Management 22

• Can add UPC to new system

▪ GTIN

▪ Brand o Using GTIN would allow for just one number to be used per unique product globally

▪ Not everyone uses because companies have to pay for a GTIN

▪ Managed by a global organization o NAPA = CONUS

▪ MFRs have to go through NAPA team for a MFR number, then LSNs can be assigned later

• Allows for discounts to vendors and customers

▪ NAPA LSNs are determined and given during the building process – this number will correspond with E Series (E59/60/6162) o MPA = OCONUS o US 1:1 – Third party website that allows generics to also have allowances (managed by

NAPA team) o 16,000 NAPA LSNs used (sold) last year, but there are many more in the system

Maintain Service Core Items

The following requirement is related to maintaining Service Core items.

Subsistence Requirement Requirements Elaboration Why Needed Access Core Catalog Need the ability to view which core catalogs a master stock number belongs to.

So that a stock number can be used with a core catalog project.

• Navy MLL/FIC are pulled from other parts of the system – sent over by Wanda’s team o Need to determine check boxes that are not being used and other obsolete things sent over from Zap-it so they aren’t included in future-state system

• MLLs are created by Navy

• FICs are assigned to primary LSNs, then others can be linked to the Primary as a replacement

• Core Catalog – items can be added to more than one catalog o System needs to know replacements to allow core catalog to exist o Primary = parent o Acceptable replacements = child numbers

Maintain Item Weight Data

The following requirements relate to maintaining weight information for items, including catch weight multiples.

Subsistence Requirement Requirements Elaboration Why Needed

STORES Catalog Management 23

Capture item weight information.

TQ needs to be able to specify the item weight data and ranges for a stock number.

So that pricing can be accurately calculated/reflect for items with slight variations in their weight.

Capture catch weight data and ranges for an item.

TQ needs to be able to mark catch weight items and set the upper and lower ranges for the catch weight unit and multiplier.

So that pricing can be accurately calculated/reflected for items with slight variations in their weight.

• Maintain – Weights o Item description does not always tell item weight, so pricing is usually done with weight units o Used for items that are sold priced by the LB (case weights may vary) o TQ builds limits, system develops a range, then vendors must comply with this range

▪ Catch weight item

▪ Catch weight lower limit

▪ Catch weight upper limit

▪ Non-Catch weight lower limit

▪ Non catch weight upper limit

▪ Catch weight multiple lower limit

▪ Catch weight multiple upper limit

▪ Product net weight o TQ enters some required fields, then system calculates automatically o Catch weight multiples are submitted with products by vendors

▪ Ramifications in ordering

▪ Allows for slight weight range in product, but customer still gets the ordered amount

▪ Example: 28- 27LB boxes = 27- 28LB boxes

▪ Bottom line: did the Services obtain the amount of product they ordered?

• Is always rounded up, so no one is ever shorted o Product net weight is used when item is priced by the pound o Some fields under this tab can be removed b/c no longer used

Master Stock Number Filtering

The following table details the business requirements for filtering master stock number records.

Subsistence Requirement Requirements Elaboration Why Needed Master Stock Number Filter Need ability to filter on a specific master stock number, by default.

Allows users to quickly locate a single stock number to view/update.

STORES Catalog Management 24

Category Filter Need ability to filter on a specific category of stock numbers.

To provide more precise results.

Status Filter Working in combination with other applied filters, need the ability to filter on one or more master stock number statuses necessary to return only a subset of the data that can only be defined by using a set of multiple criteria.

To provide more precise results.

Advanced Filters Need ability to set a list of various specific filtering commands in order to pinpoint/return a specific set of records (for example, Query Builder)

To provide more precise results.

Export Need ability to export a list of filtered records to a spreadsheet file.

So, records can be used outside of the system.

• Record Filter o Display all o Specific stock number o NAPA o NAPA generic o MPA o MPL o LSN o NSN o OpRats o Non-Food o Market Fresh o School Lunch o Items with FIC o UGRA End Items o UGRA Generic Component o UGRA Specific Component o Green Certified o FSOS o FSE

STORES Catalog Management 25 o Produce

• Search by filters, then pulls up first/latest stock number that meets the criteria described

• Defaults to Specific Stock Number

• Not used for searching LSNs as much as the query builder o Record number results are recorded at the bottom right of the screen (ex: 1 of 55322) o Can move right and left through records using arrows on other sides of the record results

• Record status can be filtered out as well

• Filters can be used in combination with one another o Can select one, more, or none for results

• Filter status as a possible BPR- make this another statement under query builder

• Abbreviated table view gives some fields for items but not all o Subset/information of records selected o All fields are represented when an excel sheet is exported o Comment section included in extra fields

• Can we flip through different products and still have the main search function remain?

o Add extra fields?

▪ Latest comment

• Query Builder:

o Used in abbreviated table view o Fields can be added and LSNs are filtered down by adding new clauses o Cannot save user-built queries – would be nice…