BRD-STORES2-AccessMgmt-Draft1.pdf

i

Defense Logistics Agency

FedMall

STORES 2.0 ACCESS MANAGEMENT & ADMINISTRATION

Business Requirements Document (BRD)

Version 0.1 - DRAFT

Last Update: October 7, 2023

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

STORES Access Management & Administration i

Table of Contents

EXECUTIVE SUMMARY

SCOPE

REQUIREMENTS

CUSTOMER ACCESS

CREATE NEW CUSTOMER ACCOUNT

Current State Process in STORES Key Learnings and Notes BPR Opportunities

CREATE NEW CUSTOMER ENTITY

Current State Process in STORES Key Learnings and Notes BPR Opportunities

LINK CUSTOMER ACCOUNT TO CUSTOMER ENTITY

Current State Process in STORES Key Learnings and Notes BPR Opportunities

MAINTAIN ACCESS TO CUSTOMER ACCOUNT

Current State Process in STORES Key Learnings and Notes BPR Opportunities

UPDATE CUSTOMER ACCOUNT INFORMATION

Current State Process in STORES Key Learnings and Notes

UPDATE CUSTOMER ENTITY INFORMATION

Current State Process in STORES Key Learnings and Notes BPR Opportunities

UPDATE LINKAGES

Current State Process in STORES Key Learnings and Notes BPR Opportunities

VENDOR ACCESS

CREATE VENDOR USER ACCOUNT

Current State Process in STORES Key Learnings and Notes BPR Opportunities

CREATE VENDOR ENTITY ACCOUNT

Current State Process in STORES Key Learnings and Notes BPR Opportunities

LINK VENDOR USER ACCOUNT TO VENDOR ENTITY

Current State Process in STORES Key Learnings and Notes BPR Opportunities

MAINTAIN ACCESS TO VENDOR ACCOUNT

STORES Access Management & Administration ii

Current State Process in STORES Key Learnings and Notes

UPDATE VENDOR ACCOUNT INFORMATION

Current State Process in STORES Key Learnings and Notes

UPDATE VENDOR ENTITY INFORMATION

Current State Process in STORES Key Learnings and Notes BPR Opportunities

UPDATE VENDOR USER TO VENDOR ENTITY LINKAGES

Current State Process in STORES Key Learnings and Notes BPR Opportunities

MANAGE MANUFACTURER INFORMATION

CREATE NEW MANUFACTURER ACCOUNT

Current State Process Key Learnings and Notes BPR Opportunities

MANAGE ACCESS TO MANUFACTURER ACCOUNT

Current State Process Key Learnings and Notes

UPDATE MANUFACTURER ACCOUNT INFORMATION

Current State Process Key Learnings and Notes

DLA ACCESS

CREATE NEW DLA USER ACCOUNT

Current State Process Key Learnings and Notes BPR Opportunities

LINK DLA USER ACCOUNT TO VENDOR ENTITY

Current State Process Key Learnings and Notes BPR Opportunities

MAINTAIN ACCESS TO DLA USER ACCOUNT

Current State Process Key Learnings and Notes

UPDATE DLA USER ACCOUNT INFORMATION

Current State Process Key Learnings and Notes

UPDATE LINKS BETWEEN DLA USER ACCOUNTS AND VENDOR ENTITIES

Current State Process Key Learnings and Notes BPR Opportunities

MANAGE SYSTEM ACCESS

SCHEDULE PLANNED DOWNTIME

Current State Process Key Learnings and Notes

PREVENT UNSCHEDULED DOWNTIME

STORES Access Management & Administration iii

Current State Process Key Learnings and Notes

INACCESSIBILITY PROCEDURES

Current State Process Key Learnings and Notes

CUSTOMER SURVEYS

SUBMIT FEEDBACK

Current State Process Key Learnings and Notes BPR Opportunities

APPENDIX A: GLOSSARY OF TERMS

STORES Access Management & Administration 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 Access

Management, which includes account creation and approval, user authentication and system access, user provisioning and set up, and customer surveys. 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 Access Management started on March 16, 2023, with the last regularly scheduled meeting ending on June 22, 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 stakeholders agree 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 Access Management & Administration 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 Access 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 3 in FY2024.

STORES Access Management & Administration 3

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

• Customer Access and Maintenance

• Vendor Access and Maintenance

• Manage Manufacturer Information

• DLA Access and Maintenance

• Manage System Access

• Customer Surveys

The business requirements identified in this document reflect the Access Management Business

Requirements spreadsheet that was reviewed and updated during the requirements discovery working group sessions. A copy of this spreadsheet is in the Access Management working group folder on the

DLA Teams site:

• STORES Access Management Requirements - 8-2-23.xlsx

The BPR opportunities identified in this document come from the business requirements spreadsheet, notes taken during the working group sessions, and enhancement requests received from the Military

Services.

A diagram depicting the relationship between STORES customer and vendor entities and modules is provided in:

• Appendix A: Entity Relationships in STORES

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

• Appendix B: Glossary of Terms

STORES Access Management & Administration 4

Customer Access and Maintenance This section documents STORES business requirements related to managing customer access to STORES.

The primary customers using STORES are the military services (Army, Navy, US Marine Corps, and Air

Force). Customers primarily interact with the system to submit orders, submit receipts, and request new catalog items.

Create New Customer Account

The following table details the business requirements for creating a customer account.

Subsistence Requirement Requirements Elaboration Why Needed Ability to validate an individual user so that they can have an account linked to the appropriate customer entity

(unit/ship/DFAC) to place and receipt orders.

Ability to direct requests to specific assigned approvers -final approval authority should be the business. Ability to assign separate permissions (shopper/buyer/HQs) - in total or by customer entity individually. Ability to have waivers for lack of CAC/ECA certificate. Ability for customer to list supervisor/have supervisor approval step and have validations/approvals for what permissions they are authorized.

Individual customers need access to view catalogs, place orders, receipt orders for a specific customer entity.

Current State Process in STORES

1. Customer requests AMPS account & STORES role (SAAR).

Request is validated and approved by TVLS data owner. J6 provisioner has final approval.

2. Customer requests STORES account.

Request is validated and linked by TVLS and STORES team. J6 provisioner activates account.

3. Customer provides ordering information.

Including shipping DoDAAC, name of activity/base, delivery address, estimated 1st delivery (date by which account is absolutely needed), billing DoDAAC, fund code, additional SLOA data, POC info (name, address, email, phone), types of food required, and special instructions (should be done prior to TVLS actions). TVLS/STORES team often already know if individual is a new user of an established customer entity.

4. Customer logs into STORES the first time.

Must meet certificate requirements (CAC or ECA), or be provided a waiver

STORES Access Management & Administration 5

Key Learnings and Notes

• The TVLS will validate customer information (including DoDAAC) based on their training and understanding.

• TVLS, CS, or KO can request VIC linkages and de-linkages (this may happen when a new contract is awarded and new catalogs need to replace old catalog or a new catalog is added and is not replacing an existing catalog). Requests are submitted to the STORES team.

Customer Account Creation/Approval

1. Customer submits role request in AMPS.

2. Troop Support Data Owner approval.

3. Provisioner on the STORES team (final approval).

* Provisioner and Data Owner are different individuals.

BPR Opportunities

The following BPR opportunities were identified for adding new customers.

BPR Source Short Description & Notes Priority

New Process for Completing DD2875

Working Groups

Use a different process to fill AMPS/DD2875 requirement? If AMPS is required, should it interface with system? Should STORES team or business be activating accounts? How to identify right business POCs for assistance? Should individual user be able to select specific DoDAAC - is DLA approval needed?

The DD2875 requirement will be satisfied through the use of PIEE for registering, approving, and authenticating users in the future state system.

STORES Access Management & Administration 6

Enhanced DoDAAC Validation

Working Groups

Provide DoDAAC validation to ensure it is valid and meets requirements (e.g., authorized for requisitioning if bill-to). Should include validation of signal code selection. FedMall provides real-time DoDAAC validation capabilities.

Change to Approval Workflow

ARMY Ability for HQs Army to approve all Army customer accounts (must have) - would also apply to ARNG/Reserve and could have different approval individuals.

Streamlined Access to Multiple Customer Profiles / Ordering Points

ARMY Ability to provide simpler/streamlined access to multiple ordering points/customer profiles for HQs users - HQs role

Enhanced Role for Financial Users

NAVY Expanded access for customer financial reps to research orders/receipts

Access to Sent Orders Error Report

NAVY Visibility of Sent Order Error Reports (filtered by STORES PO #, catalog #, etc.) for review by Navy HQs

Access to Fill Rate Report NAVY Visibility of Fill Rate reports (filtered by STORES PO #, catalog #, time ranges, etc.)

Access to VIC Compliance Report

NAVY Visibility of vendor item catalog compliance report based on Master Load List requirements

Access to VIC NIS Report

NAVY Visibility of vendor item catalog NIS reports (filtered by STORES PO #, catalog #, time ranges, etc.)

Create New Customer Entity

The following table details the business requirements for creating a new customer entity.

Subsistence Requirement Requirements Elaboration Why Needed Ability to establish a customer entity with various relationships between the unit, delivery locations, and billing options.

Ability to provide specific contact info, delivery POCs, special instructions, etc. Ability to link specific vendor items with specific delivery locations.

Ability to define customer entity identifier (DoDAAC) for imported/transmitted orders from customer service systems and transmitted orders to vendors systems (EDI Vendors need to be set up correctly on their side to receive orders transmissions, while non-EDI vendors receive their orders from EBS and do not require prior coordination before orders are placed). Ability to establish mandatory receipting periods (grace periods) to enforce timely receipting (preventing new orders being submitted until old orders are receipted).

Customer entities need to be defined in a way to accept orders from service systems to ease order imports/transmissions and to transmit to vendor systems. Customer entities may be in different locations but must only be associated with specific vendor coverage per geographic area.

Customer entities may have different billing depending on operational needs.

STORES Access Management & Administration 7

Current State Process in STORES

1. TVLS requests ordering point creation.

STORES team creates ordering point (Add/Edit Requests). Ordering point can be single stock fund (Yes or No). This determines how STORES purchase orders will be created (from document number or ship-to DoDAAC).

2. TVLS requests catalogs be linked to ordering point.

STORES team creates the linkage (Add/Edit Requests).

3. TVLS validates the ship-to, document number, and supplemental DoDAACs in the DoDAAD.

TVLS verifies the authority codes are active and valid (00 or 01 for ship-to, 00 for billing).

4. TVLS creates customer profile/MILSTRIP profile (delivery location/billing profile).

This is done in Add/Edit Ship to Customer.

5. Additional Standard Line of Accounting (SLOA) information is currently optional, but allowable so it can be passe to EBS.

6. TVLS provides customer profiles/MILSTRIP to vendor to set up in their system.

This is required for transmission of EDI orders to the vendor. The same unit in multiple locations or with multiple billing options has multiple profiles

7. Customer validation with MILSTRIP report - limited amount of information

8. Established set-up info viewable in Add/Edit ShipTo Customer; View Ordering Point; View

Vendor Contract-Ordering Point Association; View Contract/Ordering Point Associations

Key Learnings and Notes

• TVLS requests ordering point creation.

• STORES team creates ordering point.

• STORES links geographical catalogs through ordering points.

• TVLS confirms DODAACs are valid, active, and using proper authority code.

• TVLS goes into CCM and creates Customer Profile (hybrid MILSTRIP) with specific delivery location and billing profile, which is tied to an ordering point/ship-to combination (unit, DFAC, Ship).

• Customer Profile is also referred to as Customer Entity

• Example: Navy customer on ship going to several ports in the Pacific that are linked to different catalogs:

o Would set up different profiles for each delivery location (port) so that they can be linked to the different catalogs, delivery locations, and different billing (if needed).

o A Navy ship might be associated with many (10-20) customer profiles.

o SOP is to add a new profile when needed instead of editing an existing one as this can cause issues.

• An Ordering Point is a group of catalogs.

o Can be set up for a region.

• Can consist of different catalog types (for example):

• Bread

• Prime Vendor

• Rations

• Soda

STORES Access Management & Administration 8

• Market Fresh

• Produce

• Need to support purple service for joint bases (e.g., USMC customers on assignment at Army base).

• DLA Troop Support has regions but they are different than that they represent different branches.

o Some are tied into BDFA.

o This regionality is different from ordering point regionality.

• It's possible for a region to change when a contract is updated.

• When creating an ordering point or profile, should the final authority for approving/activating rest on the business or STORES team?

• TVLS provides customer profiles to EDI vendors so they can be set up in their system.

• If customer profile is not set up in Vendor system, then the order will still flow out of STORES but will not be received/ingested by the vendor.

• Once the customer is set up in the vendor's system, they will let the TVLS know. The TVLS will then link the customer account to the customer profile. If customer is linked to profile before vendor setup, then they could submit an order that would not be received by vendor (want to avoid this).

• For Non-EDI vendors, customer email and fax must be set up in EBS so that they can receive the customer orders.

o Question: Is phone number/fax passed in the EDI-850 transaction so that EBS knows where to send the order, or is a look up done based on the vendor’s name?

• Customer can view MILSTRIP report in STORES that shows MILSTRIP information for each assigned Ordering Point/Ship-To

• Customer must select ordering point so that they are linked to the right customer profile when ordering.

• The future state system does not need to use same solution as the current state system to satisfy a particular business requirement (e.g., administration catalogs aren't required in the future state but the ability to group items in different ways to different customers so they can use different payment methods and be assessed different fees is required).

• The ability to segregate catalogs for customers is a requirement that is currently solved through ordering points (different approach or solution could be used in future state system).

• The receipt blocking process in STORES allows Grace Period days to be set by a Customer Profile at Ordering Point and ShipTo level as well as at the Vendor Item Catalog level so that ordering is blocked at the appropriate number of days for each site.

• Ordering Points place food orders using STORES.

o ShipTo’s, also known as "MILSTRIPs," are recipients of food ordered through STORES, but do not place the orders directly.

o Ordering for ShipTo’s is accomplished through an associated Ordering Point.

o Each ShipTo is associated with an Ordering Point. Therefore, when setting up a ShipTo, the Ordering Point for the association must already be in the system.

• Ordering point can have one or more ship-to locations (example in Lanica's demo had 32 associated ship-to locations).

• The future state system needs to be able to associate a delivery location with specific geographic catalogs and a billing profile. Using ordering points and profiles is one possible solution but not required.

• Would the Services want to be able to use GPC in future state (currently restricted to MILSTRIP payments).

STORES Access Management & Administration 9

• Can system be designed so it knows what types of items are not allowed to be paid for with SIK fund or can it be designed to allow fund codes to be toggled without switching profiles?

• Army and Navy orders contain more detail than Air Force and Marine Corps orders.

Creating or Editing Ordering Points

• TVLS can no longer create or edit ordering point or ship to information. These requests have to be emailed to STORES team to do. The reason for this change should be looked at in determining what user types or roles can create/edit this information in STORES 2.0. Limiting the number of users with this capability is the current recommendation.

o Stock Fund field (Yes or No) is important when creating/requesting an ordering point as it affects how the STORES Purchase order is created and how customer entities are billed.

• Process for Creating an Ordering Point:

o Add six-digit ID for ordering point

• Lots of users use DoDAAC as ID because it is six digits but this is not what it should be.

o Stock Fund (Default is no)

• To set this correctly, TVLS should understand how the customer wants to be billed and how the PO # is created based on this selection.

o Add Name, State, and Country.

o Identify catalogs the ordering point should be linked to.

o Add an effective date.

o Save and submit.

• Association Request o Can add a contract/catalog to an ordering point.

o Can set effective date.

Deliver Locations (Ship-To’s)

• Add/Edit Ship-To/Customer o How long they have for receipts o Facility name o Base name

• All demographics for user o Delivery instructions o Site Group (financial piece)

• For prime vendor and market fresh orders, STORES doesn't care what the TAC2 is because they are using the address in STORES (this address may or may not match TAC2 address).

• For operational rations (Oprats), the address in STORES is not important. The TAC2 address will be used as the ship-to because order is being fulfilled from the Depot.

o Future state will need to account for these ship-to scenarios.

• STORES uses A, B, J signal codes.

• In EBS, the imported order has the DODAAF and billing information (imported order doesn't have an ordering point but has a ship-to DODAAC). Info in the imported order overwrites any info in STORES.

• In EBS, only Army and Navy are billed by line item (document number). Army, USMC, and Coast Guard are billed by PO. Even though in STORES it looks like it should be billing the document

STORES Access Management & Administration 10 number DODAAC, it could be billing the ship-to DODAAC if that is how the STORES Purchase Order was created. Not everyone realizes this and it can cause billing errors.

• You could have two customer profiles where everything is the same except for the ordering point and fund code. If you wanted to bill to differently because of what they are ordering, you would set up a different ordering point because all these customer profiles are identified by a unique ship-to-ordering point combination. So, you would have the same ship-to but a different ordering point that then would have a different fund code.

• SLOA was added a few years ago but virtually no customers are using it.

o Customers don't know the fields that are required. Most of the customers don't understand the financial side of doing things.

• Uncheck the box so it doesn't have to be filled out.

o SLOA was a mandate across DOD and so it was added to meet requirement.

• Need to make sure SLOA is available to customers in FedMall but not require it.

• Add/Edit Requests is where ordering points can be linked to a contract. Ordering points can be added one at a time, or all ordering points from another contract/catalog can be added to the selected contract.

• There are two ways of removing an item from a particular ordering point/ship to location:

o Hide items (done at Ordering Point level).

• Create an Administrative Catalog that does not contain the items.

The following BPR opportunities were identified for creating customer entities.

BPR Source Short Description & Notes Priority Multiple Working

Groups Ordering points not specifically needed if another way to link catalogs to delivery locations geographically can be done. If ordering points continue to be used, should they not be DoDAACs/6 digits? Ordering points restricted by service (joint basing issues)? Set descriptions for ordering points/customer profiles vs. free text fields?

Should STORES team or business be creating/linking?

Should premium transportation costs be built in by location/catalog up front? Should customer funding be tied to a customer entity? Should view screens be consolidated with more filters rather than multiple screens? Should financial validations be added?

Allow Ordering Point to Be Service- Specific

Working Groups

Segregate Ordering Points by Service, especially if the future state maintains the same type of billing. There have been cases in the current state where a Service unit (e.g., Marine Corps) was assigned to an Army ordering point during combined training. This can result in billing issues if the ordering point is not set up right.

Simplified Setup for Navy Ships

Working Groups Navy has indicated they would like a simpler process for identifying a ship and then different dropdowns to select ship-to locations (ports) and billing.

Enhanced View of

Working Groups There is currently no way for a customer to see all the ordering points/ship to combinations they are assigned

STORES Access Management & Administration 11

Ordering Point/Ship To Assignments to in a single view or report. This is something that would be useful for the Services in STORES 2.0. One option is to provide an additional customer role for the Service headquarters that provides better access to data they need, like ordering points and ship to information.

Enhanced DoDAAC validation

ARMY

Working Groups

Ability to have validations on DoDAACs/signal codes/fund codes/SLOA info - with warnings/errors and corrective actions.

More validations in data? Linkages to DoDAAD (is DoDAAC valid/active/proper authority code)?

Support for multiple LOAs

ARMY Ability to add multiple lines of accounting.

Rework of Customer Profile Set Up

NAVY

Working Groups

Fewer profiles but with more options (ordering points, delivery locations, billing options)

Simplify one unit in multiple locations and multiple billing options (drop downs)?

Change to Ordering Point

US Marine Corps

Ability to consolidate ordering points so that Prime Vendor and Operational Rations can be ordered under one centralized ordering point.

Link Customer Account to Customer Entity

The following table details the business requirements for linking customer account to a customer entity.

Subsistence Requirement Requirements Elaboration Why Needed Ability to associate a customer account with one or more customer entities.

Ability to copy one customer's linkages to another customer.

Individual customers may need to order/receipt for multiple customer entities that may be in multiple locations with multiple billing info.

Current State Process in STORES

1. TVLS links customer account to customer profile(s) - should wait for vendor acknowledgement

Key Learnings and Notes

• Should Subsistence continue to do customer linking? There is a question as to whether there will be a dedicated FedMall team to take this on.

• Should final approvals be done by someone in J6 or done by the business?

o TVLS can only update customer profile in CCM. They can't set up ordering points or linkages.

▪ These requests must be sent to a STORES PMO J6 user to complete.

STORES Access Management & Administration 12

BPR Opportunities

The following BPR opportunities were identified for linking customer accounts to customer entities.

BPR Short Description & Notes Priority

Allow Customer to Set Up Linkage to Customer Entities

Simplify one unit in multiple locations and multiple billing options (Should customer be able to link themselves - streamline process?

Final DLA approval?

Maintain Access to Customer Account

The following business requirements captures the needs for maintaining access to a customer account.

Subsistence Requirement Requirements Elaboration Why Needed Ability to restrict customer access and activate/deactivate as needed.

Ability to set inactive/retire timeline to meet business needs (NG/Res). Ability to identify those specialty customers who may need waivers (up to 60 days). Ability to reactivate inactive/retired accounts.

Individual customers need to validate their access and the business needs to be able to activate/deactivate accounts as needed.

Current State Process in STORES

1. Customer must log into STORES every 30 days or account is inactivated, every 45 days or account is retired.

2. Customer must revalidate account in AMPS yearly.

3. Customer works with TVLS if account needs to be reactivated/unretired.

Key Learnings and Notes o Customer can update certain fields in AMPS and STORES.

o TVLS makes changes that the customer cannot make themselves.

o Customers must:

o log on to STORES every 30 days or account is deactivated.

o log on to STORES every 45 days or their account is retired.

o do a yearly revalidation in AMPS o Customer works with TVLS if an account needs to be reactivated or retired.

o 30- and 45-day timelines don't always work for National Guard and Reserves customers that may only be logging in monthly or less frequently.

The following BPR opportunity relates to the maintenance of customer account access.

STORES Access Management & Administration 13

BPR Short Description & Notes Priority

Extend Sign In Window Have more realistic log in windows to accommodate National Guard and Reserves customers.

Update Customer Account Information

The following business requirement captures the need for updating customer account information.

Subsistence Requirement Requirements Elaboration Why Needed Ability to update customer account information.

N/A Individual customers may need to update their personal information.

Current State Process in STORES

1. Customer updates certain fields as necessary in STORES and/or AMPS.

2. TVLS maintains communication with the customer for any changes customer cannot make themselves.

Key Learnings and Notes

• Last name of user cannot be changed in STORES (requires getting a new STORES account)

• Users can update their email address in STORES but not in AMPS (email is primary key in

STORES)

• Only profile information a user can't change in STORES is Last Name and User ID

Update Customer Entity Information

The following business requirement captures the need for updating customer entity information.

Subsistence Requirement Requirements Elaboration Why Needed Ability to update a customer entity with different unit, delivery location, billing options, and/or additional details.

N/A Customer entities may need to be updated based on changing delivery, billing, or other info, as well as new/expired vendor contracts.

Current State Process in STORES

1. Customer notifies TVLS if a customer profile needs to be updated.

2. TVLS relies on business rules to validate changes.

3. TVLS updates the profiles.

4. TVLS requests ordering point - vendor item catalog linkages/delinkages.

STORES Access Management & Administration 14

Key Learnings and Notes

• Customer & Contract Maintenance (CCM) is used to update customer and vendor information and linkages to ordering points and contracts/catalogs

• Future state system needs to allow a customer to be tied to different catalogs depending on their location and to use different pots of money to pay for different types of food.

• There is a need to capture all the things CCM does today and make sure they are accounted for in future state requirements.

• Customers have access to MILSTRIP report that shows funding details for their ordering point/ship to combinations.

o If they see something they want to change, they need to reach out to their TVLS to make the change before they place their order. This could potentially be done without

TVLS involvement in STORES 2.0 if sufficient data validation is able to be built into it.

BPR Opportunities

The following BPR opportunities were identified for updating a customer entity.

BPR Short Description & Notes Priority

Need more validations/documented business rules (wizard)? Should STORES team or business be linking?

Update Linkages

The following business requirement is associated with adding removing links between a customer account and a customer entity.

Subsistence Requirement Requirements Elaboration Why Needed Ability to link/delink a customer account from one or more customer entities.

Ability to copy one customer's linkages to another customer.

Customer accounts may need to be linked/delinked based on changing assignments or added/removed customer entities.

Current State Process in STORES

1. TVLS links/delinks customer account to/from customer profile(s).

Key Learnings and Notes

• Linkages are set up by the TVLS before the account is approved.

BPR Opportunities

The following BPR opportunities were identified for updating the linkages between customer users and customer profiles.

STORES Access Management & Administration 15

BPR Short Description & Notes Priority

Determine who should be linking accounts

Allow customers to link their accounts with final approval coming from DLA TS?

STORES Access Management & Administration 16

Vendor Access and Maintenance This section details business requirements for managing vendors access to STORES.

Vendors interact with the STORES system in a variety of ways. For the purposes of order fulfillment, vendors process and acknowledge orders, submit invoices, and work with the TVLS to resolve any discrepancies between their submitted invoice and the customer receipt. Vendors also support catalog creation, new item requests, and catalog updates.

Create Vendor User Account

The following requirement applies to the creation of vendor user accounts.

Subsistence Requirement Requirements Elaboration Why Needed Ability to validate an individual user so that they can have an account linked to the appropriate vendor coverage.

Ability to direct requests to specific assigned approvers -final approval authority should be the business. Ability to assign separate permissions (catalog/recon). Ability to have waivers for lack of CAC/ECA certificate.

Individual vendors need access to update catalogs and submit invoices.

Current State Process in STORES

1. Vendor requests AMPS account & STORES role

Account is validated/approved by CS/KO data owner. STORES team/J6 provisioner does final approval.

2. Vendor requests STORES account (catalog and/or recon account)

Account linkages are done by CS/KO. STORES team/J6 provisioner activates account.

3. Vendor provides information (contract/catalogs, CAGE code, POC info (name, address, email, phone), and delivery dates).

This should be done prior to CS/KO actions (CS may already know if individual is a new user of an established vendor entity).

4. Vendor logs into STORES with their approved account and credentials.

Depending on vendor, they may authenticate via a CAC, ECA, or username and password

(requires a waiver).

Key Learnings and Notes

Customer Vendor Account Creation/Approval

1. Customer/Vendor submits role request in AMPS.

2. Troop Support Data Owner approval.

3. Provisioner on the STORES team (final approval).

STORES Access Management & Administration 17

Provisioner and Data Owner are different individuals.

BPR Opportunities

The following BPR opportunity was identified for creating a vendor user account.

BPR Short Description & Notes Priority

Account Activation Should STORES team or business be activating accounts? Combine catalog and recon accounts? How to identify right business POCs for assistance? Should individual user be able to select specific contract/CAGE code - is DLA approval needed?

Create Vendor Entity Account

The following business requirement is associated with creating a vendor entity in STORES.

Subsistence Requirement Requirements Elaboration Why Needed Ability to establish a vendor entity with multiple vendor coverages linked to one awarded vendor contract/cage code. Ability to link specific vendor coverage with specific delivery locations. Ability to provide additional information related specifically to the awarded contract.

Ability to provide different items to different customers in the same geographic area and/or to provide different pricing on the same items based on specific delivery locations within the same geographic area (Vendor Item Catalogs). Ability to identify type of contract/catalog (PV, MF, etc.); set CONUS/OCONUS due to pricing or regional data;

set different currency conversations; set versioning;

set EDI info; set linkages to current/previous contracts (admin catalogs/bridges/adjacent zone); set option periods and min/max contract limits. Ability to set vendor entity as EDI or non-EDI user. Ability to set contract/catalog go-live date(s). Ability to set contract closeout date for archiving and record deletions (NARA compliance).

Vendor entities need to be defined in a way to provide different items/prices to different customer entities/delivery locations withing their overall vendor coverage defined in their vendor contract.

STORES Access Management & Administration 18

Current State Process in STORES

1. CS/KO requests vendor Entity creation.

STORES team creates account capturing contract/catalog number, Cage Code, sets EDI identifiers and EDI-832 version (if vendor is EDI-enabled), currency info, POC info, and other contract/catalog specifics (Add/Edit Requests.

2. CS/KO requests catalogs be linked to ordering points.

STORES team creates linkages (Add/Edit Requests).

3. CS/KO reserves admin catalog numbers in STORES.

Main contract number is assigned in eProcurement and then entered/reserved in STORES

(Add/Edit Vendor Catalog Reservations. Also viewable in Reserved Vendor Item Catalog Report.

4. CS/KO sets base and option periods, contract award amounts, min/max amount percentages.

This is done in (Add/Edit Option Period).

5. CS/KO sets distribution fees for different distribution categories per catalog.

Admin catalogs can have same items, but different distribution fees. This is not mandatory and is not validated against vendor catalog submissions (baseline EDI-832).

6. CS/KO sets contract/catalog closeout date for inactive catalogs.

Date entered sets a six-year countdown but this can be edited (Maintain Vendor Catalog

Closeout Information).

Key Learnings and Notes

• Information set up for the Vendor Entity is accessible/viewable from the following locations in the current state STORES application:

o View Contract o Maintain Vendor Item Catalog Closeout Information o View Vendor Information o View Vendor Contract-Ordering Point Association o View Contract/Ordering Point Associations o Add/Edit Option Period o Add/Edit Vendor Catalog Reservations o Add/Edit Distribution Fees o Reserved Vendor Item Catalog Report

• Vendors can be assigned two roles: one for catalog access, and one for recon access:

o Vendor (vendor user that performs catalog maintenance) o Vendor Recon (vendor user that maintains invoice information)

• View Contract/Ordering Point Associations o Admins can see all contracts/catalogs associated with a particular ordering point o Can request a catalog to be removed

STORES Access Management & Administration 19 o There is some overlap of views and functions in CCM that can be addressed in the future state system.

• Should premium transportation costs be handled upfront as part of the primary order to prevent the secondary process used today to create a second order for the non-standard distribution fee? Non-Standard distribution fees are covered in more detail in Appendix I of the

Orders, Receipts, and Invoices BRD.

o For Iraq, the premium transportation costs were all associated with one catalog (single vendor). Customer funding for the order would come from one pot of money (Bill-To

DoDAAC) while funding for the premium transportation costs would come from a different pot.

• Maintain Vendor Item Catalog Closeout Information o This is where a CS sets the Closeout Date for the Contract or Catalog.

▪ Once the date is reached, the catalog will be archived and no longer available in the system for receipting and invoicing.

• The Litigation Hold flag is used to identify catalogs where the contractor and Government are in litigation. Selecting this flag will put a hold on all transactions (including catalog updates, orders, receipts, and invoices) until the litigation date is reached.

o Once a catalog is closed out, the data is archived for seven (7) years, unless the contract is under litigation; in which case it is archived for 12 years.

o Catalog Statuses:

▪ Active: Catalog is active in the system and can be ordered against.

▪ Inactive: Catalog is no longer available for ordering or updates, but existing transactions like receipts and invoices can still be entered and processed.

▪ Closed Out: Catalog data is archived. The catalog is no longer available to users in the system for any purpose other than reporting.

BPR Opportunities

The following BPR opportunities were identified for creating a vendor entity.

BPR Short Description & Notes Priority

Rework of Vendor Contract/Catalogs/CAGE Code Relationship

Should a different process than multiple vendor item catalogs under one vendor contract/cage code be used?

Determine who should set up/manage vendor linking

Should STORES team or business be creating/linking?

Web service or other direct interface with EBS

Direct link/interface to EBS to ensure information is the same (e.g., CAGE codes).

Add ordering controls and thresholds to Contracts

Should contracts/entities have order min/max built in - waivers; total contract min/max built in - prevents exceeding max; expiration dates that prevent orders past that date - allows other functions?

Enhanced Validation of Admin Catalogs

If admin catalogs continue to be used should more validations/warnings/up-to-date contract listings be bult in?

Improved/Simplified User Interface

Should view screens be consolidated with more filters rather than multiple screens?

STORES Access Management & Administration 20

Distribution Fee Management

Should distribution fee management remain under vendor entity set up or be more aligned with contract/catalog submission?

Capture Delivery Days Should delivery days be established to vet order RDDs against?

Link Vendor User Account to Vendor Entity

The following business requirement relates to the linking of vendor and vendor entity accounts.

Subsistence Requirement Requirements Elaboration Why Needed Ability to associate a vendor account with one or more vendor entities.

Ability to copy one vendor's linkages to another vendor.

Individual vendors may need to process catalogs or invoices for multiple entities under one or more vendor contracts.

Current State Process in STORES

• CS/KO links vendor account to vendor cage code/vendor item catalogs.

Key Learnings and Notes

• View Contract Information o Under view Contract Number, the Contract Number may be the Catalog Number.

o If a contract has multiple catalogs, they will not all be displayed under the parent

Contract in View Contract. You would need to look up each Catalog separately by the catalog #.

• Important to put in correct Country Currency for transmission to FedMall.

o FedMall suite supports foreign currency conversion but it is not currently set up or configured.

• STORES 2.0 must support currency conversions.

The following BPR opportunities was identified for the linking of vendor user accounts to a vendor entity.

BPR Short Description & Notes Priority

Allow Vendors to Set Up Links

Should vendor be able to link themselves for more streamlined process? Require final approval from DLA?

Maintain Access to Vendor Account

The following business requirement captures the need of vendors to access their account.

Subsistence Requirement Requirements Elaboration Why Needed

STORES Access Management & Administration 21

Ability to restrict vendor access and activate/deactivate as needed.

Ability to set inactive/retire timeline to meet business needs.

Individual vendors need to validate their access and the business needs to be able to activate/deactivate accounts as needed.

Current State Process in STORES

1. Vendor must log into STORES every 30 days or account is inactivated, every 45 days or account is retired.

2. Vendor must revalidate account in AMPS yearly.

3. Vendor works with CS/KO if account needs to be reactivated/unretired.

Key Learnings and Notes

• None

Update Vendor Account Information

The following business requirement captures the need for vendors to update information associated with their account.

Subsistence Requirement Requirements Elaboration Why Needed Ability to update vendor account information.

N/A Individual vendors may need to update their personal information.

Current State Process in STORES

1. Vendor updates certain fields as necessary in STORES and/or AMPS.

2. CS/KO maintains communication with the vendor for any changes vendor cannot make themselves.

Key Learnings and Notes o None

Update Vendor Entity Information

The following table details the business requirements for updating vendor entity information.

Subsistence Requirement Requirements Elaboration Why Needed

STORES Access Management & Administration 22

Ability to update a vendor entity with different information/dates.

N/A Vendor entities may need to be updated based on changing information or expiration dates as well as new/expired customer entities.

Current State Process in STORES

1. Vendor notifies CS/KO if their vendor entity profile needs to be updated.

2. CS/KO maintains a list of vendors/catalogs that are active and to which customer profiles they should be linked.

3. CS/KO updates the profiles/additional information.

4. CS/KO requests ordering point to vendor item catalog linkages/delinkages.

STORES team creates linkages.

Key Learnings and Notes

• View Vendor Information o Displays vendor information, including the following:

▪ Primary (Awarded) Contract Number

▪ Name

▪ Status

▪ Effective Date

▪ Address

▪ Type of Contract (e.g., Prime Vendor)

▪ CONUS/OCONUS

▪ DLA Account Manager/Contact Information

▪ Order Delivery (EBS or Fax)

▪ If EDI-enabled, IDs for 850 (PO) and 832 (Catalog Update) transactions.

o Types of Contracts should be cleaned up/reorganized in future state system.

o For example, Cargo could be for Prime Vendor or Produce Catalogs. Therefore, it should probably be a sublevel contract/catalog.

o Some Prime Vendors have Produce contracts (Admin Catalog) underneath them because no market fresh vendor bid for the location.

o Should consider making type of contracts and subcontracts something that can be managed/modified as part of a configuration change without requiring a code change.

o SALTS USER? Setting refers to really old contracts. Not used anymore and should be removed.

o CAGE Code should likely be displayed on this page because it is a primary key for Vendor information in STORES.

▪ CAGE code status can be validated through SAMS.gov. Is there a need to validate it in STORES? Web service look up could also check for other mistakes like misspellings, changes of address, etc.

▪ FedMall already has interface to SAM.gov so it could potentially be used to populate some of the contract information in STORES.

o Contracts are set up and awarded in eProcurement.

• Add/Edit Option Period

STORES Access Management & Administration 23 o Original Awarded Contract # is the Primary (Basic) contract #. Vendor Catalog number may be different if it is an Admin Catalog.

o An Admin Catalog is a secondary catalog. Often times it used when there is a subset of customers that need different items, or they need the same items but different pricing.

▪ For large contracts that have hundreds of items, it may make sense to create an Admin Catalog with a subset of the contract items instead of trying to go in and hide all of the items for the customer(s) that don’t want them in the catalog.

▪ Admin catalogs are also used to assess different distribution fees depending on the delivery location (example provided was Alaska: Anchorage vs. Fairbanks).

One vendor awarded contract for Alaska but needs to assess different distribution fees.

▪ Most Admin catalogs are for OCONUS locations because of distribution fees.

▪ Admin catalogs are also used for non-foods items where different billing is required.

o In most cases, the catalog will be the same as the contract#. It is a minority of vendors that have multiple Admin catalogs.

o Should examine ways to consolidate View Contract/View Vendor information screens in future state as much of the information is duplicated.

o Effective Date of Change is the date you want the vendor or contract information to be updated in the live system.

o The Contract Expiration Date isn't always accurate. The contract does not turn off automatically when this date is met. Action needs to be taken to inactivate the contract and underlying catalogs.

▪ Tie into eProcurement to make sure the date is accurate would be helpful.

o Add/Edit Option Period shows award amount and period of performance data. It does not show how much of the awarded $ amount has already been received. They would need to generate a report to see that information.

▪ A feed from eProcurement could populate this information.

• Add/Edit Vendor Catalog Reservations o Allows user to reserve a Catalog Number for an Admin Catalog.

o The following information is required when reserving a catalog number:

▪ Two-digit year

▪ Contract Type o Once you click Reserve it will pull up the next available catalog number.

o If after you reserve the catalog number, you decide you don't need it. You can release the reservation so that another party can use it.

o This needs to be done when you are getting ready to award a contract number.

o Primary (main) contract numbers come from eProcurement. Contract #s for Admin

Catalogs are added in STORES underneath a main contract.

o Once the Admin catalog number is reserved, they would then go in and add the catalog details in CCM.

o You can look up how many catalogs are reserved by a particular user.

o You can also…