System Change Requests Header

Unlike submitted Support help tickets, System Change Requests (SCR's) can only be submitted through your organization's appointed and authorized ELMS CCB member representatives, or otherwise if no CCB representatives have yet been appointed, your Primary Information Owner appointee. If you are unsure of who your organization's appointed ELMS CCB member representatives or Primary IO are, you may email the ELMS Support team to request that information: This email address is being protected from spambots. You need JavaScript enabled to view it..

To learn more about the process, please visit our CCB Responsibilities and Meetings page. Below you will find all SCR's that have been submitted, and what their status is. To download a blank form, you may visit our Reference Library and download the SCR Form.

Enter your SCR Number in the filter below, or click the column title header to sort by that column. You may also download an Excel file of the record data by selecting the blue Excel logo in the upper right corner of this page.

Filter 
SCR Number Title DPAS Module Reporting
Organization 		State Description
02173 Electronic Weapon Record Book PA,MU,Warehouse,Materiel Management USMC New
Change Request: New Process

Description:
 
The USMC requires an enterprise-wide capability to automate the collection, entry, and reporting of PEI maintenance and operational data through an Electronic Weapon Record Book (EWRB). The absence of this capability will result in a critical data gap adversely impacting the Ordnance community’s ability to track and analyze key metrics such as round counts, effective full charge, pullover gauge measurements, maintenance costs, availability, and readiness for weapon systems. This data is essential to inform decision-making across strategic, operational, and tactical levels of command and to support life cycle management and resource allocation decisions. Additionally, the capability must extend beyond the Howitzer community to accommodate broader USMC ground equipment and weapons platforms, while incorporating role-based access control to safeguard data integrity. Without this integrated and customizable EWRB capability in ELMS, the Marine Corps risks losing visibility into critical performance metrics, reducing the effectiveness of sustainment planning and readiness reporting. The absence of this capability in ELMS represents a Significant Deficiency, as it limits USMC's ability to track and report maintenance and operational data for serialized ordnance assets. This impairs readiness reporting, life cycle decision-making, and auditability across weapon systems.
 
Recommended:
 

REQ-001 - Electronic Weapon Record Book Capability. ELMS shall provide an Electronic Weapon Record Book (EWRB) capability to collect, store, and report serialized ordnance data, including component configuration, inspection results, and firing data. Supports data-driven decision-making for life cycle management and readiness reporting of Marine Corps weapon systems. Users can enter, update, and report weapon-specific data (e.g., round count, component swaps, EFC) for serialized equipment.

 
REQ-002 - Parent-Child Quality Record Structure. ELMS shall implement a parent-child data structure for weapon records, allowing summary data roll-up from child entries (e.g., Gun Book Part I and II) to the parent weapon header. Enables accurate aggregation of inspection and firing metrics for each weapon system. Child entries (e.g., Pullover Gage, EFC) are reflected in summary fields on the parent record automatically upon save.
 
REQ-003 - Weapon Component Tracking and Swap Logging. ELMS shall allow tracking of major weapon components (e.g., tube, breech block, breech ring) with fields for serial number, install date, and configuration changes. Provides traceability and auditability for configuration changes and maintenance history. Users can log new components, track EFC baselines, and deactivate prior configurations.
 
REQ-004 - Charge and Round Entry with EFC Calculation. ELMS shall allow entry of charge and round types to automatically calculate Equivalent Full Charges (EFC) and update total EFC per component. Standardizes performance tracking and avoids manual errors in EFC computation. System auto-calculates EFC and updates roll-up fields upon entry of round count and charge type.
 
REQ-005 - Role-Based Access Control for Data Integrity. ELMS shall implement role-based access control for the EWRB functionality, including read, write, and update privileges aligned to user responsibilities (e.g., Maintenance Clerk, Officer). Ensures least privilege and protects data integrity in serialized weapon records. Users can only perform functions (view, edit, update) permitted by their assigned roles.
 
REQ-006 - Audit Trail and Administrative Overrides. ELMS shall provide an administrative override function for manual EFC entry and require justification comments for audit traceability. Supports rebaselining and audit compliance when non-standard updates are required. Administrative EFC updates prompt for reason code and are logged with timestamp and user ID.
 
REQ-007 - Inspection and Technical Measurement Fields. ELMS shall support data entry for maintenance metrics such as pullover gage readings, elevation/cant/azimuth, and borescope inspections. Captures critical maintenance data used to assess weapon condition and performance. Users can input and update required inspection metrics with validation and summary roll-up.
 
REQ-008 - Reporting and Data Export Capabilities. ELMS shall support advanced search and export functionality for EWRB records, including filters by SN, EFC %, inspection date, and other metrics. Enables strategic and tactical reporting for sustainment planning and audit readiness. Users can generate reports and export to Excel-compatible formats with full field sets and filters.
 
REQ-009 - Document Attachment and Multimedia Upload Capability. ELMS shall allow users to attach multimedia files (e.g., images, PDFs, inspection reports, modification instructions) to specific weapon or component records. Enhances record completeness, enables visual and documentation-based validation, and supports audit and technical inspection requirements. Users can upload and view attachments associated with weapon records and all attachments are stored and retrievable per record.
 
REQ-010 - Disconnected Field Data Entry and Sync Capability. ELMS shall support offline (disconnected) data entry for EWRB functionality, with synchronization to the central system upon reconnection to MCEN. Supports continued operations in field environments with limited or no connectivity, ensuring timely data capture and delayed sync. Users can enter and save EWRB data offline and synchronize it with the main system once a secure network connection is restored.
 

Mission Critical:
 
 
Benefits:
- Meets MARCORLOGCOM's business model
- Assists in 100% accountability of assets
- Complies with current audit controls 

Frequency: 
Daily

Users: 
All USMC Users
02172 Communication Tracking and Tasking Tool PA,MU,Warehouse,Materiel Management USMC New
Change Request: New Process

Description:
 
ELMS currently lacks a centralized, audit-ready task management capability, resulting in fragmented communication, inconsistent accountability, and limited visibility across MARCORLOGCOM and enterprise stakeholders. If unchanged, task coordination will depend on manual tools such as emails and spreadsheets, which lack standardization, traceability, and support for audit compliance (e.g., FIAR, OMB A-123). This capability gap is a Significant Deficiency that impairs ELMS’s ability to synchronize logistics operations, defend audit findings, and ensure timely execution of mission-critical actions. Implementing the Communication Tracking and Tasking Tool (CTTT) will close this gap by enabling structured, role-based tasking with integrated workflow, sub-tasking, document management, scheduling, and dashboard oversight.
 
Recommended:
 

(Requirement Group 1.0: Task Initiator Information)

REQ-1.1 - Title: Capture Task Initiator Full Name Requirement Statement: The system shall capture and display the Task Initiator’s full name (Last Name, First Name, Middle Initial) at the time of task submission to ensure traceability and accountability of the originator. A temporary Task identification number will be assigned to the draft request and will only be deleted once a CTTT tracking number has been assigned and the task is saved and submitted.
REQ-1.2 - Title: Record ELMS User Number Requirement Statement: The system shall record the unique ELMS User Identification Number associated with the Task Initiator's user profile to facilitate system-level traceability and user authentication.
REQ-1.3 - Title: Capture Organizational Details Requirement Statement: The system shall capture the Task Initiator’s organizational details, to include:
•DoDAAC (Department of Defense Activity Address Code) or UIC (Unit Identification Code),
•TAC-1 Address (Transportation Account Code primary mailing address), to enable command-level attribution and routing.
REQ-1.4 - Title: Capture Task Initiator Contact Information Requirement Statement: The system shall record and store the Task Initiator’s primary contact information, including:
•Government Email Address
•Commercial or DSN Telephone Number to support communication and task validation efforts.
REQ-1.5 - Title: Autofill from User Profile Requirement Statement: The system shall autofill all Task Initiator information (Full Name, ELMS ID, DoDAAC/UIC, TAC-1, Contact Info) from the authenticated user’s profile upon new task creation to reduce data entry errors and streamline workflow.
REQ-1.6 - Title: Display Initiator Information in Task Header Requirement Statement: The system shall display the captured Task Initiator data in the task header of each record for visibility to all users with access to that task.
REQ-1.7 - Title: Editability Restriction of Initiator Fields Requirement Statement: The system shall restrict manual edits to Task Initiator information by non-system administrators to ensure data integrity. Only the authenticated user or authorized admin may update profile-linked initiator data.
REQ-1.8 - Title: Retain Historical Initiator Information Requirement Statement: The system shall retain the original Task Initiator information even if the user’s profile is later updated or deactivated to ensure historical audit traceability.
REQ-1.9 - Title: Capture Task Initiation Timestamp Requirement Statement: The system shall automatically timestamp the date and time (in UTC) a new task is initiated to support time-sensitive performance tracking and compliance reporting.
REQ-1.10 - Title: Capture Initiator’s Command Hierarchy Requirement Statement: The system shall optionally allow the capture of the initiating command’s hierarchy (e.g., MARCORLOGCOM > WSMC > Section) to enhance filtering, reporting, and command-level oversight.
B.
CTTT Header Section – Task Metadata and Assignment Requirements (Requirement Group 2.0: Task Details and Assignment Routing)
REQ-2.1 - Title: Capture Task Title Requirement Statement: The system shall provide a mandatory field for users to enter a concise Task Title (maximum 150 characters) that summarizes the task’s purpose for identification in dashboards, notifications, and search queries.
REQ-2.2 - Title: Capture Task Description Requirement Statement: The system shall provide a mandatory rich text field (maximum 1,000-character limit) to allow users to describe the purpose, background, scope, and objectives of the task in narrative format.
REQ-2.3 - Title: Capture Classification Level Requirement Statement: The system shall require the user to select a Classification Level from a predefined list (e.g., Unclassified, Controlled Unclassified Information (CUI), Confidential, Secret) to ensure proper handling of sensitive information. Note: Only Unclassified and CUI tasks may be processed through ELMS; others will be rejected or flagged.
REQ-2.4 - Title: Capture Urgency of Need (Priority) Requirement Statement: The system shall require the user to select an Urgency of Need level from the following dropdown values:
•Critical (Immediate action required)
•High (Action required within 3 business days)
•Medium (Action required within 5–10 business days)
•Routine (No fixed suspense, monitoring required) This selection shall influence dashboard filtering and notification frequency.
REQ-2.5 - Title: Provide Free-form Text Block (Operational Notes) Requirement Statement: The system shall provide an optional free-form text field (max 2,000-character limit) titled Operational Notes where the Task Initiator can input supplemental, non-structured data such as references, coordination history, or unofficial context not suitable for the formal Task Description.
REQ-2.6 - Title: Capture and Display ELMS Government Task Manager (Assignment Target) Requirement Statement: The system shall populate the ELMS Government Task Manager field based on pre-defined business rules or assignment criteria (e.g., by DoDAAC, task category, functional module). If assignment criteria are not met or unknown, the field shall
remain blank and routed to the MARCORLOGCOM CTTT Office for manual task manager assignment.
REQ-2.7 - Title: Allow Manual Override of Task Manager Assignment Requirement Statement: For users with appropriate permissions (e.g., CTTT Admin, ELMS PMO), the system shall allow manual override of the assigned Task Manager to accommodate exceptions or emergent reassignments.
REQ-2.8 - Title: Include Pre-Tasking Workflow Routing Flag Requirement Statement: The system shall include a logic-driven routing flag that indicates whether the task requires pre-tasking coordination or approvals (e.g., Immediate Supervisor, Commanding Officer, SupO, Finance, etc.), and dynamically generate a corresponding workflow approval path if applicable.
REQ-2.9 - Title: Auto-Save Function During Header Data Entry Requirement Statement: The system shall support auto-save functionality every 60 seconds while users are entering header data, preserving partial entries in draft status to prevent data loss due to session timeout or system interruption.
REQ-2.10 - Title: Unique Task Draft ID Requirement Statement: The system shall assign a temporary Task Draft ID to each initiated task before final submission and tracking number assignment. This ID shall be visible to the user and included in the activity log for traceability.
C.
CTTT Header Section – Task Classification & Equipment Details (Requirement Group 3.0: Task Type and Item Metadata)
REQ-3.1 - Title: Capture Type of Request Requirement Statement: The system shall provide a required dropdown field labeled “Type of Request”, allowing users to select the nature of the task from a predefined list, including but not limited to:
•Supply
•Maintenance
•Data
•Quality Assurance
•Services
•Financial
•Audit/Compliance
•Policy/Instruction
•Technology/IT
•Facilities/Infrastructure
•Training The list shall be configurable by system administrators to support future task type additions.
REQ-3.2 - Title: Allow Editable Task Type by Authorized Users Requirement Statement: The system shall allow authorized personnel (e.g., ELMS PMO, Task Manager) to edit or refine the Type of Request during the Task Acceptance/Assignment phase prior to official task activation and routing.
REQ-3.3 - Title: Enable Entry of Equipment-Related Task Data Requirement Statement: If the task type selected requires identification of specific equipment (e.g., Supply or Maintenance tasks), the system shall display a conditional “Type of Equipment” entry section with fields for:
•National Stock Number (NSN)
•TAMCN (Table of Authorized Materiel Control Number)
•Serial Number
•Nomenclature (Item Name)
•Manufacturer/Model (if applicable)
•Quantity
REQ-3.4 - Title: Integrate with ELMS Catalog for Item Lookup Requirement Statement: When a valid NSN is entered, the system shall query the ELMS Item Catalog to retrieve and auto-populate known extended attributes of the item (e.g.,
Nomenclature, Unit of Issue, Unit Price, Condition Code) to reduce manual data entry and improve accuracy.
REQ-3.5 - Title: Support Manual Entry of Equipment Data Requirement Statement: If a match to the ELMS Catalog is not found or the NSN field is left blank, the system shall allow the user to manually enter equipment-related metadata using free-text or selectable List of Values (LOVs), with required fields highlighted dynamically.
REQ-3.6 - Title: Allow Multiple Equipment Line Items Requirement Statement: The system shall allow users to enter multiple equipment line items within a single task record, each with its own equipment metadata and associated task notes (e.g., one task with five NSN/TAMCN items needing separate tracking).
REQ-3.7 - Title: Track Equipment Metadata Edits by Authorized Users Requirement Statement: The system shall allow authorized users during the Task Acceptance/Assignment phase to update or correct equipment details, with all changes logged in the task audit trail to maintain data integrity and version control.
REQ-3.8 - Title: Conditional Required Fields for Equipment Tasks Requirement Statement: If the Type of Request is classified as Supply, Maintenance, or Quality, the system shall require entry of at least one equipment item record before allowing task submission or activation.
REQ-3.9 - Title: Validate NSN Format Requirement Statement: The system shall validate NSN inputs for proper format (13-digit numeric) and display user guidance or input constraints to reduce formatting errors during task entry.
REQ-3.10 - Title: Support Attachment of Item Documentation Requirement Statement: The system shall allow users to upload supporting item documentation (e.g., technical manuals, calibration reports, service histories) alongside the equipment metadata to provide full context to downstream reviewers and action officers.
D.
CTTT – Task Acceptance, Approval, and Assignment Requirements (Requirement Group 4.0: Government Task Manager Controls)
REQ-4.1 - Title: Automatic Assignment of CTTT Tracking Number Requirement Statement: Upon task approval by the Government Task Manager, the system shall automatically assign a unique CTTT Tracking Number formatted as: [Requestor DoDAAC]-CTTT-[YYMMDD]-[Serial Number] (e.g., M30201-CTTT-250527-0012), which shall serve as the system’s primary key, official task ID, and reference point for audit and tracking purposes. This action shall also capture the origination system date/time stamp for reporting.
REQ-4.2 - Title: Refine Type of Request from Assignment-Level List of Values (LOV) Requirement Statement: The system shall allow the Government Task Manager to select a refined Type of Request from an expanded List of Values (LOV), specific to assignment-level tasking needs. Example values include but are not limited to:
•Supply
•Maintenance
•Equipment Return
•EOP (Equipment Optimization Plan)
•M2OG (Material Management Operating Group)
•Data Analysis
•Transportation
•Inventory Adjustment
•Customer Assistance
•Technical Support This refined list is used for downstream reporting, routing logic, and priority scoring.
REQ-4.3 - Title: Assign and Update Task Request Status Requirement Statement: The system shall allow the Government Task Manager or authorized personnel to assign and update the Task Status field using a predefined set of values, including:
•Pending Review
•Working
•Awaiting Information
•Awaiting Shipment
•Assigned
•Response Provided
•Returned
•Closed
•Reopened
•Cancelled Task Status shall be system-audited and version-controlled with timestamps and user ID for all changes.
REQ-4.4 - Title: Derive and Apply Task Priority Using UMMIPS Format Requirement Statement: The system shall enable the Government Task Manager to assign task Priority using UMMIPS-aligned urgency formatting (e.g., “01-F/AD I UND A”), composed of:
•Force/Activity Designator (F/AD I–III)
•Urgency of Need Designator (UND A–C) This value may be either manually selected or automatically derived based on business logic using task metadata (e.g., Request Type, Mission Dependency, Source of Request, Equipment Type).
REQ-4.5 - Title: Permit Authorized Priority Overrides Requirement Statement: The system shall allow authorized personnel to override automatically derived UMMIPS priority values when validated by supporting justification or command authority. All overrides shall be logged and require a mandatory justification note.
REQ-4.6 - Title: Record Task Approval Date and Approving Official Requirement Statement: Upon assignment of a CTTT Tracking Number, the system shall capture and store the Task Approval Date/Time and Approving Official (Full Name and Role) as part of the official task metadata.
REQ-4.7 - Title: Assign Task to Action Office or Entity Requirement Statement: The Government Task Manager shall be able to assign the task to a designated Action Officer, Team, or Organizational Entity (e.g., Warehouse Ops Team, WSMC Branch, etc.), based on role-based selection menus. Assignment metadata shall be included in the task header and used to generate routing logic and notifications.
REQ-4.8 - Title: Editable Assignment Fields by Authorized Users Requirement Statement: During the Task Acceptance/Assignment phase, all assignment-related fields (e.g., Refined Type of Request, Status, Priority, Assigned Entity) shall remain editable by users with elevated permissions (e.g., Task Manager, CTTT Admin, ELMS PMO) until the task is officially moved to "Working" status.
REQ-4.9 - Title: Task Routing Audit Trail Requirement Statement: The system shall maintain an audit log of all assignment actions, including field changes, status updates, and reassignments, with time stamps and user ID visible through the task’s activity history tab for transparency and compliance tracking.
REQ-4.10 - Title: Task Assignment Comment Block Requirement Statement: The system shall provide a required Assignment Comments text box during task approval/assignment for the Task Manager to enter rationale, expectations, or context for the task. This comment shall be visible to all task participants and remain part of the permanent record.
E.
CTTT – Task Acceptance, Approval, and Assignment Requirements (Requirement Group 5.0: WORMG Assignment, Task Assessment, Equipment Status, Document Tracking)
REQ-5.1 - Title: Assign Work Order Resource Manager Group ID (WORMG_ID) Requirement Statement: The system shall provide the Government Task Manager with a searchable List of Values (LOV) for selecting a Work Order Resource Manager Group Identification Number (WORMG_ID). The format shall follow [DODAAC]-[Command]-[Functional Area], such as:
•M98822-LOGCOM-DISPO
•M67854-MARCORSYSCOM-ENGSUP This value shall be stored as a primary grouping element for analytics, reporting, and workload segmentation.
REQ-5.2 - Title: Capture and Store Task Assessment Problem Statement Requirement Statement: The system shall include a required Task Assessment Problem Statement field for the Task Manager to input a succinct operational-level summary of the task’s underlying issue or challenge. This problem statement should be written in a clear, mission-relevant format suitable for command reviews and risk discussions (max 2000 characters).
REQ-5.3 - Title: Capture Operational Status of Selected Equipment (When Applicable) Requirement Statement: If the task involves specific equipment, the system shall display an Operation Status dropdown for the Task Manager to select one of the following predefined values:
•Supply Action Pending
•In-Service
•Out-of-Service
•Awaiting Parts
•Transferred
•Disposed
•Returned to Stock This field shall appear conditionally based on the equipment metadata fields entered during task creation.
REQ-5.4 - Title: Assign USMC Document Number (When Applicable) Requirement Statement: For applicable tasks (e.g., involving property movement, supply issue/return, or disposition), the system shall allow the Task Manager to generate and assign a USMC-standard Document Number using the format:
[DODAAC]-[Julian Date]-[4-digit Serial Number] Example: M98822-2135-0001 This document number shall be uniquely associated with the CTTT tasker and linked to any subsequent logistics transactions, audit logs, or warehouse actions.
REQ-5.5 - Title: Ensure Document Number Uniqueness and Reusability Controls Requirement Statement: The system shall ensure that each generated Document Number is unique per DODAAC and Julian date and may not be reused for another task. In the case of correction or cancellation, the Document Number must retain association with the original task ID and reflect its changed status.
REQ-5.6 - Title: Editable Fields by Authorized Task Owners Post-Acceptance Requirement Statement: Fields in this section (WORMG_ID, Task Assessment, Operational Status, Document Number) shall remain editable during the Task Acceptance/Assignment phase by authorized personnel (e.g., Task Lead, Program Manager, CTTT Admin), and locked once the task reaches “Working” or “Open” status unless elevated access rights are applied.
REQ-5.7 - Title: Link Document Number to Audit Trail and Transactions Requirement Statement: The assigned Document Number shall be linked to the CTTT task audit trail and visible in all task-related transactions, comments, or document uploads to ensure traceability and alignment with USMC logistics audit standards (e.g., FIAR compliance).
REQ-5.8 - Title: Conditional Prompt for Document Number Generation Requirement Statement: The system shall prompt the Task Manager to generate a Document Number only when applicable task types are selected (e.g., “Supply,” “Return,” “Disposition”), reducing clutter for non-logistics task types (e.g., Training, IT, Policy).
REQ-5.9 - Title: Document Number History View Requirement Statement: For any task assigned a Document Number, the system shall allow users with view permissions to access a Document History View showing the original number, issuing official, timestamp, and any status changes or transaction references (e.g., DD1348, shipping label, RCN).
F.
CTTT – Task Creation and Tracking Requirements (Requirement Group 6.0: Sub-Task Tasking, Assignment, and Workload Deconfliction)
REQ-6.1 - Title: Assign Task to Individual or Group within WORMG_ID Requirement Statement: The system shall allow the Task Lead to assign individual task records to any authorized individual user or group entity associated with their assigned WORMG_ID, with role-based controls to prevent assignment outside their organizational scope.
REQ-6.2 - Title: Split Parent CTTT into Multiple Sub-Tasks Requirement Statement: The system shall allow the Task Lead to logically split the parent CTTT record into an unlimited number of Sub-Task taskers, each assigned a unique Sub-Task Number using a suffix linked to the parent task (e.g., M98822-CTTT-250527-0003-01, -02, etc.). All Sub-Task taskers shall maintain a reference link to the parent task record.
REQ-6.3 - Title: Assign Sub-Task Task Status Requirement Statement: Each Sub-Task shall have an independently assigned Task Status from the following predefined list:
•In Planning
•Assigned
•Cancelled
•Completed
•Closed Sub-Task task statuses may differ from the parent task status and shall be independently tracked and reportable.
REQ-6.4 - Title: Select Owner Type from LOV Requirement Statement: For each Sub-Task, the Task Lead shall select an Owner Type from a dropdown List of Values (LOV), including:
•Employee Resource
•Group Resource
•Supplier Contract
•Team Resource This value enables accurate reporting and contracting data integration (if applicable).
REQ-6.5 - Title: Assign Sub-Task Task to Individual by ELMS User ID Requirement Statement: When assigning a Sub-Task to an individual, the system shall
allow the Task Lead to search by ELMS User ID or name and automatically populate associated contact fields (e.g., email, phone, role, location).
REQ-6.6 - Title: Enter Sub-Task Task Subject Requirement Statement: Each Sub-Task shall have a unique subject label (max 100 characters) that distinguishes it from other subtasks and reflects the discrete nature of the assigned work.
REQ-6.7 - Title: Enter Sub-Task Description Requirement Statement: The Task Lead shall be required to enter a brief narrative description (max 1000 characters) to clarify the scope, expectations, or deliverables of each Sub-Task.
REQ-6.8 - Title: Set Scheduled Start Date via Calendar Selector Requirement Statement: The system shall allow the Task Lead to set a Scheduled Start Date for each Sub-Task task using a calendar pop-up interface with date validation against the parent task start date.
REQ-6.9 - Title: Set Forecast Completion Date via Calendar Selector Requirement Statement: The system shall allow the Task Lead to set a Forecast Completion Date using a calendar pop-up, with validations to ensure the end date is after the start date and within parent task parameters (unless override permission is granted).
REQ-6.10 - Title: Automatically Calculate Task Period Requirement Statement: The system shall automatically calculate and display the Task Duration in business days based on the Scheduled Start Date and Forecast Completion Date, providing visual confirmation to the Task Lead.
REQ-6.11 - Title: Alert for Task Scheduling Conflict / Overload Requirement Statement: The system shall perform a Schedule Deconfliction Check by assessing the total number of overlapping task assignments per user or group. If a task period exceeds recommended load thresholds (e.g., >3 concurrent Sub-Task assignments), the system shall issue a warning alert to the Task Lead with an option to proceed or reassign.
REQ-6.12 - Title: Link Sub-Task Task Completion to Parent Task Workflow Requirement Statement: The system shall automatically update the parent task record with a Sub-Task Task Completion Summary (e.g., 3 of 5 subtasks completed) and provide a visual progress tracker within the parent CTTT dashboard view.
G.
CTTT – Sub-Task Notes and History Requirements (Requirement Group 7.0: Task Executor Activity Capture, Documentation, and Sub-Tasking)
REQ-7.1 - Title: Create Unlimited Sub-Tasks from Assigned Task Requirement Statement: The system shall allow Task Executors to create an unlimited number of Sub-Tasks under any assigned Tier-1 task. Each Sub-Task shall be assigned a unique sequence number with a hierarchical reference linking it to the parent Tier-1 and original CTTT (e.g., M98822-CTTT-250527-0003-01-001).
REQ-7.2 - Title: Assign Sub-Task Start Date via Calendar Selector Requirement Statement: The system shall allow the Task Executor to assign a Start Date for each Sub-Task using a calendar pop-up tool, with system checks to ensure the date falls within the scheduled duration of the parent task unless override permissions are enabled.
REQ-7.3 - Title: Select Type of Sub-Task from Predefined LOV Requirement Statement: The system shall require the Task Executor to select a Type of Sub-Task from a configurable dropdown List of Values (LOV), including but not limited to:
•Investigation
•Manufacture
•Miscellaneous Task
•Purchase Order
•Recovery
•Request for Disposition
•Requisition Resource Move
•Salvage
•Selective Interchange
•Service This value shall support operational categorization and downstream workflow/routing rules.
REQ-7.4 - Title: Assign Sub-Task to User via ELMS User ID Requirement Statement: The Task Executor shall be able to assign a Sub-Task to any ELMS-authorized user by querying the ELMS User ID, which shall auto-populate user details (name, email, organizational affiliation) for task routing and communication.
REQ-7.5 - Title: Record Secondary Response Note Requirement Statement: The system shall provide a Secondary Response Note dialog box for Task Executors to document key insights, decisions, actions taken, or clarifying remarks related to Sub-Task execution. Notes shall support rich-text entry and be stored with a timestamp and user ID.
REQ-7.6 - Title: Select Sub-Task Status Requirement Statement: Each Sub-Task shall carry its own Status Field, editable by the assigned user or Task Executor, with the following valid values:
•In Planning
•Assigned
•Cancelled
•Completed
•Closed The status field shall update Sub-Task dashboards and roll up progress indicators at the parent task level.
REQ-7.7 - Title: Enable Attachment Upload Option Requirement Statement: The system shall present users with a binary Upload Attachments option (Yes/No). If “No” is selected, the file upload section shall be skipped. If “Yes,” upload fields will be presented for further entry.
REQ-7.8 - Title: Select Attachment Data Type from Dropdown LOV Requirement Statement: If file upload is enabled, the system shall require users to select the Attachment Data Type from a List of Values (LOV), including but not limited to:
•SL-3 (Stock List)
•LTI (Limited Technical Inspection)
•DD-1348 (Issue/Turn-in Document)
•DD-1149 (Transfer Document)
•GBL (Government Bill of Lading)
•Technical Drawing
•Photographic Evidence
•Maintenance Log The LOV shall be configurable to support additional document types.
REQ-7.9 - Title: Provide Description for Uploaded Attachment Requirement Statement: For each uploaded file, the system shall require a brief user-provided description (max 500 characters) to explain the content and relevance of the attachment. This information shall be searchable in the task document repository.
REQ-7.10 - Title: Close-Out Functionality for Sub-Tasks and Parent Tasks Requirement Statement: Upon marking a Sub-Task or Parent Task as “Closed,” the system shall automatically archive the following in a structured and retrievable format:
•All communications and Secondary Response Notes
•Sub-Task details and execution metadata
•User assignments and status changes
•All associated file attachments and document metadata This archive shall be viewable under a historical tab and exportable as part of the CTTT audit package.
H.
CTTT – Notifications, Routing Rules, and Alerting Functions (Requirement Group 8.0: System-Driven Communications and Escalation Management)
REQ-8.1 - Title: Notification of Task Creation Requirement Statement: The system shall send an automated email and ELMS dashboard notification to the Government Task Manager upon submission of a new task by a Task Initiator, including task metadata (title, description, initiator info, priority).
REQ-8.2 - Title: Notification of Task Assignment Requirement Statement: The system shall notify all assigned Individuals and Groups via email and system dashboard when a task, Tier-1 task, or sub-task has been assigned to them, including task title, due dates, and required actions.
REQ-8.3 - Title: Role-Based Routing Logic Requirement Statement: The system shall apply role-based routing rules to ensure tasks are routed automatically to the correct Task Manager, Action Office, or Program Owner based on metadata such as:
•Type of Request
•DoDAAC / WORMG_ID
•Task Category
•Equipment Type (if applicable) Routing rules shall be configurable and maintained by CTTT administrators.
REQ-8.4 - Title: Notification on Status Changes Requirement Statement: The system shall generate an automated notification to assigned users and stakeholders when any of the following status changes occur:
•Task Status
•Tier-1 Task Status
•Sub-Task Status
•Priority Change The notification shall include who made the change, when it occurred, and any associated comments.
REQ-8.5 - Title: Deadline-Based Alerts Requirement Statement: The system shall issue automated alert notifications when the following conditions are met:
•72 hours before scheduled due date (reminder)
•On due date (alert)
•Overdue status (escalation notification sent to Task Lead and PMO)
REQ-8.6 - Title: Escalation Notifications Requirement Statement: The system shall escalate overdue tasks based on their priority as follows:
•Critical/Urgent tasks escalate at 24 hours overdue
•High tasks escalate at 72 hours overdue
•Medium/Routine tasks escalate at 5 business days overdue Escalations shall be sent to the assigned user, Task Lead, and responsible Government Task Manager.
REQ-8.7 - Title: In-App Dashboard Alerts Requirement Statement: The system shall display all alerts in a user-specific dashboard under an "Action Required" panel, with filterable categories (e.g., Assigned to Me, Overdue, Due This Week, Awaiting My Review).
REQ-8.8 - Title: Custom Notification Preferences Requirement Statement: Users shall be able to configure notification preferences (e.g., email, in-app, daily digest, real-time alert) from a personal settings menu, while critical alerts (e.g., overdue, escalations) shall remain mandatory.
REQ-8.9 - Title: Routing Failover Logic Requirement Statement: If automated task routing fails (e.g., no responsible Task Manager found for routing rule), the system shall route the task to a designated CTTT Default Manager Queue and alert the PMO for reassignment within 1 business day.
REQ-8.10 - Title: Real-Time Activity Feed Requirement Statement: Each CTTT task shall include a real-time Activity Feed viewable by stakeholders showing:
•User actions
•Comments
•Sub-task changes
•Document uploads
•Notifications sent This feed shall serve as a system-of-record for communication traceability.
REQ-8.11 - Title: Digest Summary Report Requirement Statement: The system shall provide users with an optional daily or weekly digest report via email, summarizing:
•Assigned tasks
•Tasks nearing due dates
•Tasks recently completed
•Notifications received Digest content and frequency shall be user-configurable.
REQ-8.12 - Title: Alert on Excessive Concurrent Assignments Requirement Statement: If an individual is assigned more than a system-defined threshold of concurrent tasks (e.g., 5 open Tier-1 tasks), the system shall alert the assigning Task Lead and suggest workload review or reassignment.
I.
CTTT – Dashboard Requirements (Requirement Group 9.0: User Dashboard, Visualization, and Workload Awareness)
REQ-9.1 - Title: Role-Based Dashboard Customization Requirement Statement: The system shall provide role-based dashboards tailored to each user’s function, including:
•Task Initiator
•Task Executor
•Task Lead
•Government Task Manager
•ELMS PMO/Admin Each role-specific view shall include widgets, filters, metrics, and charts relevant to the user’s responsibilities and access rights.
REQ-9.2 - Title: My Tasks Widget Requirement Statement: The dashboard shall include a “My Tasks” widget displaying all tasks, Tier-1 taskers, and Sub-Tasks assigned to the user, sortable by:
•Priority
•Due Date
•Status
•Last Activity
•Parent CTTT Number
REQ-9.3 - Title: Assigned Team Tasks View Requirement Statement: Users with group assignment roles (e.g., Task Lead or WORMG_ID Owner) shall have access to a “Team Tasks” tab showing all active tasks for their team or WORMG_ID group, with filtering by individual assignee, task type, or due date.
REQ-9.4 - Title: Task Status Summary Panel Requirement Statement: The dashboard shall provide a status summary visualization showing total tasks across the following statuses:
•In Planning
•Assigned
•Working
•Awaiting Information
•Completed
•Closed
•Overdue This panel shall support drill-down into each category.
REQ-9.5 - Title: Calendar View of Tasks Requirement Statement: The dashboard shall offer a calendar view of all assigned or managed tasks (parent and Tier-1) that displays:
•Scheduled Start Dates
•Forecast Completion Dates
•Due Date Alerts Color-coded entries shall reflect task status or priority.
REQ-9.6 - Title: Visual Priority Indicator Requirement Statement: Tasks on the dashboard shall include a visual priority indicator (color-coded or icon-based) based on UMMIPS priority code (e.g., 01-F/AD I UND A) to highlight critical and urgent taskings for fast triage.
REQ-9.7 - Title: Filter and Search Capabilities Requirement Statement: The dashboard shall provide advanced filtering and search options based on:
•Task Number (any level)
•DoDAAC / WORMG_ID
•Task Owner / Assignee
•Type of Request
•Equipment NSN or TAMCN
•Priority
•Status Filters can be saved as user-defined views.
REQ-9.8 - Title: Notifications Panel Requirement Statement: The dashboard shall include a real-time notifications panel showing alerts, escalations, overdue tasks, task acceptance requests, and file upload notifications. Users can mark notifications as read or archive them.
REQ-9.9 - Title: Task Progress Charts Requirement Statement: The system shall support dashboard charts that visualize:
•% of Tier-1 Tasks Completed per Parent Task
•Tasks Closed vs Open by Time Period
•Sub-Task Completion Trends
•Assignment Load by Individual or Group Charts shall be exportable and drillable to underlying task records.
REQ-9.10 - Title: Overdue Task Tracker Requirement Statement: Each dashboard shall include an “Overdue Task Tracker” section
listing all tasks that have exceeded their Forecast Completion Date, sortable by days overdue, assigned user, or priority.
REQ-9.11 - Title: Export Dashboard Data Requirement Statement: Users shall be able to export dashboard data into common formats (e.g., Excel, PDF, CSV) for reporting, data calls, or analysis, with the option to apply current filters to the export set.
REQ-9.12 - Title: Quick Access to Recently Viewed Tasks Requirement Statement: The dashboard shall include a “Recently Viewed Tasks” section listing the last 10 task records (any level) accessed by the user, enabling fast navigation back to ongoing work.
REQ-9.13 - Title: Dashboard Refresh Interval Requirement Statement: The dashboard shall refresh automatically every 5 minutes and also support a manual refresh button to pull the latest task and status information in real-time.
REQ-9.14 - Title: Dashboard Configurability Requirement Statement: Users shall have the ability to configure their dashboard layout (e.g., drag-and-drop widgets, hide/show components, save personalized layouts) while retaining system-default dashboards for enterprise standards.
J.
General Requirements
REQ-10.1 - The system shall support the use of controlled List of Values (LOVs) for all dropdown fields defined in CTTT requirements (i.e., Task Type, Sub-Task Type, Owner Type, Priority, Attachment Data Type, etc.). During solution development, the MARCORLOGCOM Implementation Lead shall collaborate with the ELMS PMO development team to define, validate, and finalize each LOV to ensure alignment with enterprise standards, user roles, and business processes. All LOVs shall be system-configurable to support future updates and enterprise governance.
REQ-10.2 – Expanded Routing Rules. Following assignment of a Work Order Resource Manager Group Identification Number (WORMG_ID), the system shall apply additional task routing logic within the Material Management module. Specifically, ELMS shall route applicable tasks to the designated Inventory Manager based on the associated Program Name and Materiel Designator Code (MDC) in accordance with existing Material Management routing protocols. This ensures that logistics tasks requiring item-level disposition, coordination, or oversight are properly aligned with responsible inventory authorities, enhancing traceability, responsiveness, and accountability.

REQ-10.3 – Problem Descriptions. The system shall provide an expanded free-form text field labeled Problem Description, with a minimum character limit of 3,000, and support for longer entries to accommodate detailed task narratives such as Disposition Instructions for Turn-Ins. Additionally, the system shall allow users to upload disposition instructions as a file attachment in lieu of, or in addition to, the text field. Supported file types shall include PDF, DOCX, and TXT, and the uploaded document shall be linked directly to the task record for traceability, user reference, and audit compliance. This functionality shall mirror and expand upon the Problem Description format used in GCSS-MC induction records, while meeting the broader requirements of ELMS logistics workflows.

 
Note: the following Disposition Instruction example is provided for REQ 10.3 clarification and to demonstrate the type of task response and data upload requirement that are routinely executed. DISPOSITION INSTRUCTIONS FOR AAV P7 DIVESTMENT CROWS EQUIPPED VEHICLES – TO ALBANY
THE FOLLOWING TAMCN, NSN, SR & SN’s ARE APPLICABLE: TAMCN: E0846
NSN: 2350-01-458-7410
SR: 36330892
SN(s): 522492, 522609, 522689, 522756, 522943, 522995, 523007
QTY: 07
1.Units are to retain SL-3's and redistribute within the unit, the AAV community or send to DRMO.
2.It is authorized that CROWS configured AAV-P7s may be harvested for LRU items identified in the tables below prior to divestment. Unit is required to debrief the CROWS (1090-01-682-2770 NSN) from the vehicle.
3.The affected unit will collect up all LRU that make up the CROWS (1090-01-682-2770), retire the (1090-01-682- 2770 NSN) serial number, and then turn in LRU to the appropriate Repairable Issue Point (RIP) under turn-in without issue.
4.Units will then DRMO remaining portion of the CROWS as the rest of the AAV-P7 is sent for divestment.
5. Unit is to remove all EAAK from assets returning to LOGCOM. EAAK is to be disposed of through local means. If units possess unserviceable EAAK plates on assets being retained, they are to selectively interchange with serviceable panels pending DRMO. No AAV’s are to be returned to LOGCOM with EAAK installed on or contained in the vehicle.
6.For Communication equipment, Weaponry and Computer/Data storage devices:
*Unit is required to break parent/child relationships in GCSS-MC from the respective vehicle.
*Unit is required to submit separate SR's requesting Disposition from the respective WSMT Teams:
-Weapons - Contact 
-Communication Equipment – Contact 
-Computer/Digital Data Storage Devices - Contact 
* Unit is to leave any 7800i INTERCOM upgrade installed and return with AAV.
7.In addition to those items called out in the AAV FoV Disposal Plan (DP) for unit level removal, the following items are hereby directed to be removed from each vehicle prior to shipping and disposed of locally by the using unit:
- Taillight NSN 6620-00-669-5623 - Qty (2)
NOEM
NSN
PART NUMBER
ARMAMENT SUBSYSTEM: M153A5
1090-01-682-2770
60201886-13-C01-L01
Armament Subsystem, Remotely operated
1090-25-161-6440
60201888-01-C01-L01
Bracket Mounting (LSSA)
5340-25-161-7073
60205363-00-C01-L01
Right Side Support Assembly (RSSA)
1005-25-161-6922
60205362-00-C01-L01
THERMAL IMAGING MODULE (TIM)
5855-25-160-7363
8404363-2
Sight Servo Assembly
5860-25-161-6459
60202017-01-C01-L01
Cradle, Machine Gun (Soft Mount)
1005-25-162-0443
60235616-01-C01-L01
Visual Imaging Module (VIM)
5895-25-161-7071
60235971-00-C01-L01
Range Finder, Laser
1240-25-161-3161
60233586-00-C01-L01
Grip Assembly, Controller, Weapon (CG)
1290-25-160-3141
60205254-00
Control, Optoelectronic display (DCP)
5980-25-160-3143
68113473-02
Electronic unit, Fire control computer (MPU)
1220-25-160-5111
68113472-02
W2 & W3 Connector Cap Kits consist of:
NOEM
NSN
PART NUMBER
*CLAMP,LOOP,
5340-01-543-3594
S325SSG12
COVER,ELECTRICAL CONNECTOR
5935-01-282-7231
D38999/33W19R
*COVER,ELECTRICAL CONNECTOR
5935-01-282-7232
D38999/32W19R
Screw, Cap, Socket Head
5305-12-390-0050
ISO 7380-1-M4X12-A4-70
*Washer, Flat
ISO 7089-4-200 HV-A4
*Washer, Lock
AEW16X40M000WJ7A11
*Nut, Plain, Hexagon
5310-01-306-9820
Iso 4032-M4-A4-70
- Dome Light NSN 6220-00-337-7463 - Qty (5)
- Radio Stack lights NSN/NIIN 01-421-0093 (C), 01-444-1218
8.Vehicles are to be relatively clean and free of any oil, trash, or debris in the back. Absolutely no excess spare parts to be returned in the back of vehicle.
- Questions concerning the above are to be directed to the AAV Weapon System Support Manager
IMPORTANT: *DO NOT* return any of the aforementioned assets, SL-3 back to LOGCOM in the vehicle.
Vehicle is to be shipped with no more than ¼ tank of fuel contained in the fuel tanks.
* ADDITIONAL REMARKS:
Unit required to change condition code of assets to condition code F.
KSD’s (LTI, DD FORM 1348, 1149) are required to be loaded to this service request, per HQMC.
9. SHIP TO INSTRUCTIONS:
- Induct Material Redistribution inside of this Service Request in GCSS-MC, PRIOR TO PHYSICALLY SHIPPING to
DODAAC MMSA51, RIC MSA.
DODAAC: MMSA51, RIC: MSA
Distribution Management Office Wilkinson Way, BLDG 1221 Door 20 MF: MMSA51, 2D Force Storage BN Albany GA 31704-5000
TAC Code M2LL Applies

Mission Critical:
OMB Circular A-123 and DoD FIAR guidance
 
Benefits:
- Meets MARCORLOGCOM's business model
- Assists in 100% accountability of assets
- Complies with current audit controls 

Frequency: 
Daily

Users: 
All USMC Users
02171 Work Order Resource Management Grp ID Capability PA,MU,Warehouse,Materiel Management USMC New
Change Request: New Process

Description:
 
ELMS lacks the capability to dynamically manage user roles, responsibilities, assign tasks, and enforce data access based on organizational structure and mission function, as effectively demonstrated by the current Resource Group model in use at LOGCOM. This absence of a structured, role-based grouping mechanism—such as WORMG—limits the system's ability to enforce separation of duties, manage provisioning at scale, and ensure auditable user role assignment across multiple ELMS modules. Without a centralized resource grouping capability, unit-level administrators face inefficiencies in managing user access, increasing the likelihood of role drift, unauthorized data visibility, and inconsistent assignment of CTTT tasks. This impedes audit readiness, violates ICAM best practices, and introduces compliance risks under DoD cyber security and identity management mandates. This deficiency constitutes a Significant Deficiency in internal controls under OMB Circular A-123 and DoD FIAR guidance. It adversely affects the system’s ability to enforce identity, credential, and access management (ICAM) policies, impairs segregation of duties, and increases the risk of audit findings related to improper access. While not yet a Material Weakness, its enterprise-wide impact and alignment with key audit objectives elevate it to a priority remediation area for ELMS/DPAS modernization.
 
Recommended:
 
Resource Group Capability for ELMS
 
MARCORLOGCOM business processes require the following system requirements needed to implement a Work Order Resource Manager Group (WORMG) capability in ELMS. This capability will support automated routing and assignment of tasks to appropriate entities.
 
REQ-01 – Resource Group Definition: The system shall enable administrators to create and manage WORMG Identifiers (WORM_ID) that associates Users, user roles, access privileges to the organizational structure (e.g., Unit Identification Codes or Activity Address Code). This enables scalable and secure user access management across all ELMS modules based on organizational and functional responsibilities. Examples of existing WORMG groupings are:
 
1. AAC-M38005
2. AAC-M38005_MAINT
3. AAC-M38005_MAINT_CAL
4. AAC-M38005_MOVE
5. AAC-M38005_EKMS_CAL
6. AAC-M38005_WEAPONS_CAL
7. AAC-M38005_SUPPLY
8. AAC-M38005_S3
9. AAC-M38005_S4
10. AAC-M38005_WEAPONS
 
REQ-02 – Role-Based Access Control (RBAC) via WORMG: The system shall implement Role-Based Access Control (RBAC) through WORMG that determines the user’s ability to view or transact records in specific ELMS modules. This enforces security and segregation of duties while maintaining audit compliance. The system must support Roles are pre-configured and map to system functions. Users assigned a WORMG will inherit RBAC permissions automatically.
 
REQ-03 – Organizational Data Restrictions: The system shall support the assignment of WORMG to specific organizations, units, or sites within ELMS to control data visibility at the UIC/AAC level. This prevents unauthorized access to data from unrelated units or Commands. Users see only records belonging to their assigned unit(s). Cross-unit access must be explicitly configured by an authorized admin.
 
REQ-04 – WORMG Assignment Workflow: The system shall provide a workflow-based interface for assigning users to a WORMG, including submission, review, and approval stages. This provides accountability and oversight into user provisioning processes. The workflow should address all stages between the initiator, account approver, and system admin. All workflow actions are time-stamped and logged.
 
REQ-05 – Automated Access Request Processing (Auto-SAAR Integration): The system shall integrate with approved Identity Services to automate user provisioning based on verified identity attributes and mission role. This reduces administrative overhead and ensures secure, identity-verified access. Key features include integration to retrieve user identity and role attributes followed by ELMS automatically recognizing appropriate WORMG assignments during onboarding.
 
REQ-06 – WORMG Audit Trail: The system shall record all actions related to WORMG creation, modification, deletion, and user assignment into a centralized audit trail. This provides traceability and supports compliance with DoD audit standards. Logs must capture User ID, timestamp, action taken, and object affected. Logs are viewable and exportable for audit compliance.
 
REQ-07 – Periodic Access Review (User Certification): The system shall support periodic User Access Reviews (UARs) that generate WORMG assignment reports and allow account managers to re-certify or revoke user access. The review process should allow account managers to update assignments based on recorded justification.
 
REQ-08 – Approver Group Configuration: The system shall support configuration of Approver Groups within WORMG(s) to route approvals for transactions to designated individuals. This supports accountability and chain-of-command adherence for key actions. Account managers will configure Approver Groups by function and approval level. Approvals follow established business process rules.
 
REQ-09 – Training Completion Validation: The system shall validate that users have completed mandatory training prior to WORMG assignment. This is required to prevent untrained personnel from executing mission-critical tasks. This requirement will assure training completion is verified via training system integration or once the certificate is uploaded. Users are blocked from group assignment until training is validated.
 
REQ-10 – Module-Agnostic WORMG Utility: The WORMG capability shall function across all ELMS modules with consistent user-role behavior. This ensures consistency and eliminates redundant configuration across modules. The system will be accepted when the following criteria are met: WORMG definitions are centrally managed and universally applied. A user assigned to a group in one module behaves identically in another.

Mission Critical:
OMB Circular A-123 and DoD FIAR guidance
 
Benefits:
- Meets MARCORLOGCOM's business model
- Assists in 100% accountability of assets
- Complies with current audit controls 

Frequency: 
Daily

Users: 
All USMC Users
02170 Ability to Adjust Shelf Life & Service Life Warehouse AFERMS New
Change Request: Process Improvement

Description:
 
AFERMS Warehouse stock numbers 1377010528209 Cutter, Cartridge Actuated ACES II Cutter , 1377010528210 CUTTER, CARTRIDGE ACTUATED SURVIVAL KIT CUTTER, 1377013339143 CUTTER, CARTRIDGE ACTUATED C1-4.0,  users are unable to update Shelf life and service date per T.O. 11P12-15-7 that governs to the service life of the Reefing Line Cutter used in our ACES II Personnel Parachutes and ACES II Survival Set Kits, the service life for Part No's C1-1.15 & C1-4.0 have been
updated to a 180 Month Shelf Life and a 144 Month Service Life.
 
Recommended:
 

Users need to be able to update the DOE of 1377010528210 CUTTER, CARTRIDGE ACTUATED SURVIVAL KIT CUTTER, 1377013339143 CUTTER, CARTRIDGE ACTUATED C1-4.0, 1377010528209 CUTTER using the Inventory Update Manager actions and print correctly on forms.

 
 

Mission Critical:
T.O. 11P12-15-7 that governs the service life of the Reefing Line Cutters used in our ACES II Personnel Parachutes and ACES II Survival Seat Kits, the service life for Part No’s C1-1.15 & C1-4.0 have been updated to a 180 Month Shelf Life and a 144 Month Service Life.
 
Benefits:
 
 
Data Integrity and Kit Intercity
 

Frequency: 
Daily

Users: 

Impacts all AF AFERMS users, potentially all ELMS users.
02169 Restriction of warehouse personnel in select Owning DoDAAC During the receipting phase Warehouse USMC New
Change Request: Process Improvement

Description:
 
The ELMS Prepositioned Materiel Receipt (PMR) process has a Significant Deficiency in its receipt-handling workflow. While conducting testing in the production environment, a warehouse person was able to select an Owning DoDAAC other than what was recorded on the 527D (DW_). This resulted in inventory being established in the wrong ICP with follow-on corrective action requiring the generation of 947I (D9B) voucherable transactions to move on-hand balances to their correct ICP. This unrestricted user input can misdirect assets by creating due-in records under the wrong ICP account, compromising inventory accountability, audit readiness, and enterprise asset visibility. ELMS must programmatically restrict the assignment of Owning DoDAAC/RIC values during PMR processing to match the values provided in the DAAS 527D (DW_) or those derived through validated system logic based on the 856S (AS_)/870S (AE_) when auto-generating PMR transactions internally.
 
Recommended:
 

REQ-001: Automated DoDAAC/RIC Assignment. The ELMS system shall automatically populate the Owning DoDAAC and RIC fields during the PMR receipt process using authoritative transaction data from either the 527D (DW_) or, in its absence, validated logic from the 856S (AS_) and 870S (AE_) transactions. This will ensure consistency with externally derived ownership assignments and prevent user error. During testing, receipt transactions automatically reflect correct ICP ownership values without manual user input.

 
REQ-002: Disable Manual Override of Ownership Fields. The ELMS system shall disable any manual editing or override of the Owning DoDAAC or RIC fields by warehouse personnel during the material receiving process. Prevents erroneous or unauthorized reassignment of ownership, supporting audit integrity and compliance. Attempting to manually change Owning DoDAAC/RIC during the receipt workflow triggers a system restriction with an explanatory message.
 
REQ-003: Field Locking Upon System Population. Upon successful system population of the Owning DoDAAC and RIC, ELMS shall render these fields read-only for all user roles associated with warehouse operations.
 
REQ-004: Ownership Validation Logic. The ELMS system shall implement validation logic that confirms the ICP account assigned to a PMR matches the account derived from the 527D (DW_) or fallback logic using the Signal Code and transaction routing of the 856S (AS_). Prevents mismatches between receipt records and system ownership by ensuring alignment with originating source data. System flags and prevents transaction posting if ICP assignment cannot be validated.
 
REQ-005: Role-Based Exception Handling. If a valid 527D (DW_) is not available and automated ICP assignment fails, ELMS shall raise an exception requiring intervention by ICP personnel with appropriate role-based access. Ensures that only properly authorized users can address ownership exceptions, maintaining control over inventory data. ELMS shall display an actionable alert and routes exception tasks to the designated ICP queue or user group.
 

REQ-006: Transaction Audit Logging. The ELMS system shall record audit logs for all actions related to the assignment or modification of Owning DoDAAC and RIC fields, including user ID, timestamp, and action type.

 
 

Mission Critical:
 
Benefits:
 
 
- Meets MARCORLOGCOM's business model
- Assists in 100% accountability of assets
- Complies with current audit controls 

Frequency: 
Daily

Users: 
Process affects Materiel Manager, WH Managers and ICP
02168 Foreign Military Sales MU,Warehouse,Materiel Management,Registry (SA/LW) USMC New
Change Request: Process Improvement

Description:
 
The current design of the ELMS does not fully support the end-to-end business and audit requirements necessary for compliant execution of Foreign Military Sales (FMS) cases. Key gaps exist in the areas of standardized requisition integration, serialized asset tracking, inventory segregation, shipment documentation, and financial transaction recording. These deficiencies hinder the Marine Corps’ ability to demonstrate transaction-level traceability, chain-of-custody, and cost recovery for FMS case materiel as required by DSCA guidance, DoD FMR) and USMC Financial Improvement and Audit Readiness (FIAR) controls. In particular, the lack of system automation to generate or ingest certain DLMS EDI transactions (e.g., 511R, 945A, 856S) and the absence of a case-level audit dashboard prevent effective oversight of asset movements and related financial postings. This condition increases the risk of improper FMS billing, misstatement of inventory balances, loss of asset accountability, and material noncompliance with DoD auditability standards. This SCR falls under the classification of a Significant Deficiency in internal controls, with the objective of enabling full life cycle traceability, audit trail retention, and compliance with FMS and FIAR standards through enhancement of ELMS FMS integration and reporting capabilities.
 
Recommended:
 
The following outlines the 21 FMS SCR requirements supporting enhancements to the ELMS system. Each requirement includes a uniquely identified statement, affected modules, and references to authoritative guidance from DLMS or DoD manuals.
 
1. The system shall enable creation of FMS case records, impacting the ELMS Core/All module(s), to support compliance with DLM 4000.25, aligns with DoD FMR Vol 15, and MILSTRIP procedures for FMS.
2. The system shall allow linkage of FMS metadata to assets, impacting the ELMS Core/All  module(s), to support compliance with DLM 4000.25-1, Appendix AP1.16 - FMS Case Designators.
3. The system shall support entry and validation of LOA conditions, impacting the ELMS ICP Material Management and M&U module(s), to support compliance with DLM 4000.25-1, Chapter 2 - MILSTRIP Requisitioning Policies.
4. The system shall enable inventory reservation by FMS case, impacting the ELMS Inventory Control module(s), to support compliance with DLM 4000.25-1, Chapter 3 - Supply Status.
5. The system shall generate transfer documentation (e.g., DD1149), impacting the ELMS IC module(s), to support compliance with DoD Manual 4000.25-M, MILSTRIP formats.
6. The system shall support FMS-specific asset ownership, impacting the ELMS IC module(s), to support compliance with DLM 4000.25-2, Logistics Data.
7. The system shall generate/transmit DLMS 511R, impacting the ELMS Inventory Control module(s), to support compliance with DLM 4000.25-1, Appendix C1.1.5 - Requisition (511R).
8. The system shall generate DLMS 856s shipment status, impacting the ELMS Warehouse Management module(s), to support compliance with DLM 4000.25-1, Appendix C1.2.1 - Shipment Status (856S).
9. The system shall generate DLMS 945a shipment confirmation, impacting the ELMS Warehouse Management module(s), to support compliance with DLM 4000.25-1, Appendix C1.2.4 - Warehouse Confirmation (945A).
10. The system shall support DLMS inbound message processing, impacting the ELMS DLMS Gateway Integration module(s), to support compliance with DLM 4000.25-1, Chapter 4 - Transaction Processing.
11. The system shall integrate MRO with warehouse pick logic, impacting the ELMS Warehouse Management module(s), to support compliance with DLM 4000.25-2, Appendix AP2.5 - MRO Processing.
12. The system shall capture TCN/BOL/TAC/transportation mode, impacting the ELMS Warehouse Management module(s), to support compliance with DTR 4500.9-R, Part II – Cargo Movement.
13. The system shall generate DD1348-1a, impacting the ELMS Warehouse Management module(s), to support compliance with DLM 4000.25-2, Appendix AP2.6 - Transportation Data Submission.
14. The system shall interface with DAI for trust fund obligations, impacting the ELMS Financial Interface module(s), to support compliance with DoD FMR Vol 15, Chapter 4 - FMS Trust Fund Accounting.
15. The system shall reconcile LOA line-item costs, impacting the ELMS Financial Interface module(s), to support compliance with DLM 4000.25-1, Appendix AP1.18 - Price Challenges and Reconciliation.
16. The system shall implement SIM enforcement for FMS, impacting the ELMS Property Accounting module(s), to support compliance with DLM 4000.25-1, Chapter 6 - Serialized Item Tracking.
17. The system shall track all FMS transactions in audit logs, impacting the ELMS All Modules module(s), to support compliance with NIST SP 800-53 AU family – Audit and Accountability.
18. The system shall provide FMS dashboard/reporting, impacting the ELMS Analytics module(s), to support compliance with Not in DLMS; aligns with DoDI 5000.76 and audit readiness policy.
19. The system shall enable FMS audit package export, impacting the ELMS Reporting/Archiving module(s), to support compliance with DLM 4000.25-1, Chapter 5 – Shipment and Financial Documentation.
20. The system shall restrict access to FMS records, impacting the ELMS Access Management module(s), to support compliance with NIST SP 800-53 AC family – Access Control.
21. The system shall enable role-based segregation of FMS roles, impacting the ELMS Role Management module(s), to support compliance with NIST SP 800-53 AC-5 – Separation of Duties.
***End of Requirements***
 
The attached FMS process flow provides an end-to-end lifecycle for handling foreign sales using ELMS and DAI in compliance with DLMS and DoD FMR. Implementing this integrated approach enables traceable, accountable, and auditable FMS support—streamlining execution, reducing errors, and ensuring compliance with security cooperation policy.
 

Mission Critical:
 
Benefits:
- Meets MARCORLOGCOM's business model
- Assists in 100% accountability of assets
- Complies with current audit controls 

Frequency: 
ADHOC

Users: 
Process affects Materiel Manager, WH Managers and ICP
02167 Member Profile Duty Status Add Warehouse AF New
Change Request: Process Improvement

Description:
 
Customer management/member profile when adding a new profile only allows you to add duty status if you use one of three Pay grade types; ACAD - Cadet, PREP - Prep, and Staff - Prem - Party. Duty status is used for all services, Marines, Army, Navy, Air Force and Coast Guard. If you use the Import function, you can upload the duty status if you know the two digit codes, but then the upload instruction do not have the duty status codes in the instructions. But the services need the enlisted and officer ranks opened up to this duty status.
 
Recommended:
 

1st - Load the following display descriptions to the duty status field, Traditional Guardsman, Traditional Reservist, Technician (GS/WG/WS), Active Guardsman/Reservist (AGR) and State/Local (SCA).Would like this done as soon as possible as we are just starting to load all our team members and we understand we can do this under mass upload

2nd - Put the codes on the data format tab of the Import sheet, just like the Pay grades are spelled out how to load. This would be nice to have completed before so we know what code goes with which description.

3rd - Activate the enlisted and officer fields to open up Duty status field, can be done at a later date as we can adjust the field until corrected

 
Mission Critical:
The structure of the uniform services' rank system is primarily governed by Title 10 of the United States Code, which outlines the roles, missions, and organization of the U.S. Armed Forces. This includes the Army, Navy, Air Force, Marine Corps, and Space Force. The legal basis for the Coast Guard's structure, including its operation as a military service and a branch of the armed forces, is primarily found in Title 14 of the United States Code.
 
Benefits:
 
 
This will allow the services to track within their separate branches how many reservist, guardsmen, active or technicians. Allow for forecasting based off the status and allow for better funding/auditing capabilities.
 
 
 
Frequency: 
Weekly

 

Users: 

According to who may be using ELMS, but this would/could affect daily operations.
02166 Update BLADE Feed with Additional Required Data PA AF New
Change Request: Process Improvement

Description:
 
The Advana/BLADE data feed currently lacks the necessary fields to generate an accurate due-in/due-out report. The required fields are listed in the attached Excel file.
 
Recommended:
 

Modify the data feed to incorporate the newly identified data elements. The objective is to create a report within Advana/BLADE that mirrors the pending due-out/due-in report native to the ELMS application. This enhanced report in Advana/BLADE will enable users to view all assets due in and due out at the enterprise level. In addition this data will be utilized for other data analytics eg ESCAPE.

 
Mission Critical:
Air Force Leadership has directed that all data analytics be performed within Advana/BLADE. This request is in line with the vision detailed in the attached decision memorandum.
 
Benefits:
 
 
Enables users to analyze enterprise data in the context of asset transfers.
 
 
 
Frequency: 
Hourly

 

Users: 

All Advana/BLADE users of ELMS Data
02165 ICAM Implementation within ELMS PA,MU,Warehouse,Materiel Management,FSM,Registry (SA/LW) Leidos New
Change Request: Policy / Regulatory

Description:
As the Department of Defense (DoD) moves toward enterprise-wide identity and access management, it is increasingly important for systems like ELMS (formerly DPAS) to align with these efforts to ensure consistency and audit readiness. Currently, multiple DoD systems independently manage personnel identity assignments, leading to a fragmented approach across the department. While ELMS has its own effective account tracking mechanisms, broader alignment with authoritative identity services supports a more unified and verifiable accountability structure. A consolidated identity framework would help standardize practices across all services and components.
 
Recommended:
Integrate ELMS with the Identity, Credential and Access Management (ICAM) to support a DoD-wide authoritative approach to access management. This integration would allow ELMS to reference trusted identity data directly from ICAM. Leveraging ICAM ensures that personnel data and role verification are consistent across systems. It also streamlines reporting and improves coordination with other systems adopting the same authoritative source. This solution aligns with DoD’s strategic goals for digital modernization and interoperability.
 
Mission Critical:
DoD policies such as DoDI 5000.76 and DoDI 8320.07 emphasize the use of authoritative data sources and the need for accurate, standardized accountability of government property. ICAM is the designated enterprise service for identity and access management and provides a common framework for personnel verification. Integrating with ICAM enhances ELMS’s ability to support these policies while aligning with the DoD’s broader data and cybersecurity strategies. https://dodcio.defense.gov/Portals/0/Documents/Cyber/DoD_Enterprise_ICAM_Reference_Design.pdf
 
Benefits:
1) This integration strengthens ELMS’s ability to support enterprise audit readiness by ensuring accounts and roles are validated against a DoD approved source. 2) It provides a systematic process for ELMS's Account Mgmt. services that is currently a combination of manual and automated tools. 3) It provides greater accountability to manage source records and reduces the redundancy in personnel management across systems.
 
Frequency: 
 
Users: 
All ELMS users and account managers
02164 Implement ADC 1466 Report Missing PMR Receiving Discrepancy PA,MU,Warehouse,Materiel Management Leidos New
Change Request: Policy / Regulatory

Description:
DEDSO implemented a change to the DLMS 527R (TH) to enable the receiving entity to report within the receipt acknowledgement transaction an issue they experienced in performing the receipt / ADC 1466.  1. ELMS needs to display the descrepancy cd and description to the entity that receives the materiel receipt acknowledgment.  2. WIthin Receiving, ELMS needs to allow the user performing the receipt to enter a decrepancy reason cd which will be included in the 527R (TH).
 
Recommended:
1. Modify Receiving to enable the input of a discrepancy reason they want to report to the issuance party via the 527R. 2. Modify the inbounding of a DLMS 527R to extract and displays the discrepancy cd and description to the owner of the materiel that shipped the materiel to the gaining organization.  3. Generate and transmit an information DLMS 842 A/W to report the issue when no PMR was received.
 
Mission Critical:
Ensure DLMS compliance (ADC 1466)
 
Benefits:
Provide for reporting of receiving issues to the to the product manager.
1.Receipt Acknowledgment Discrepancy Code (Y) - No PMR. Receipt processed with documentation. Informational Supply Discrepancy Report (if this is the only discrepancy) required.
2.Receipt Acknowledgment Discrepancy Code (Z) - No PMR. Receipt processed without documentation. Informational Supply Discrepancy Report (if this is the only discrepancy) required.
 
Frequency: 
 
Users: 
While receipts are processed all day long, it is not known how many of those receipts may have a descepancy that should be reported.
02163 F35 Interim Solution for accounting of SPARES Materiel Management Leidos New
Change Request: New System Process

Description:
Currently the JPO does not have financial accountability of its inventory. The proposed interim solution is for the contractors to provide 3 files (Catalog, Asset and Physical Inventory Results) in MS Excel format with ELMS providing a method to import the files.
 
Recommended:
To support creating a financial accountability record, ELMS needs to provide an import capability that a user can use to maintain inventory balances with in the Materiel Mgmt. application. The 3 imports are as follows:
A. Catalog Stock Nbr Import
B. Materiel / Asset Import
C. Date Of Last Inventory Process

Upon import, the system will validate and process the data.  Errors will be output a spreadsheet for review, correction and re-import. Records that are successfully processed will produce accounting transactions with the results reflected in the ELMS accounting reports.

 
Mission Critical:
This is an overlay upload entered into ELMS to account for F35 repair spares  / parts and associated cost.
 
Benefits:
F35 inventory in the hands of a contractor are visible to DoD.
 
Frequency: Monthly
 
Users: 
02162 Warehouse Category Addition Warehouse NSWC New
Change Request: Process Improvement

Description:
Warehouses that contain only Operating Material and Supplies are required to create a negative inventory report for General and Sensitive Equipment.
 
Recommended:
Additional Warehouse Category to annotate that it is an OMS warehouse to show auditors that the warehouse does not have general equipment and sensitive items.  Suggested Name = "OMS - Consumable Warehouse"
 
Mission Critical:
 
Benefits:
Exempt the associated warehouse that has this Warehouse Category from generating negative inventories.
 
Frequency: Monthly
 
Users: 
All Users
02161 Depot Request for Induction Asset (511R_A0) Project Code 3AB Warehouse,Materiel Management USMC New
Change Request: Process Improvement

Description:
While conducting testing, MARCORLOGCOM encountered a problem where ELMS did not allow our Depot Remote Storage Activity (RSA) to call for inventory scheduled for induction, from the Inventory Control Point (ICP) using a (DLMS 511R/A0_) as prescribe in Approved DLMS Change (ADC) 1176.  Within the (DLMS 511R/A0_) a project code of “3AB” must be entered identifying the transaction as being part of a depot required induction.
 
Recommended:
 

1.0 This process starts with one of the Depots, Remote Storage Activities (RSAs), using the Warehouse Module (WM), under the ICP Owning RIC of “MPT”,  ELMS shall provide the mechanism for the RSA Depot warehouse to request for an asset for induction into depot repair.  This will be accomplished using a (DLMS 511R/A0_), with a signal code of “M”, and a Project Code of “3AB”.  The Owning RIC will be specified as “MPT”.  This is in accordance with Approved DLMS Change (ADC) 1176.

 
1.1 ELMS shall route the (511R/A0_) to the Material Management (MM)/ICP module of the specified “Owning RIC”, Inventory Control Point (ICP), Inventory Manager for release or cancellation consideration.
 
2.0 ELMS shall provide the Inventory Manager (IM), within the Material Management (MM)/ICP module, the ability to view all available asset for the specified National Stock Number (NSN) and Condition Code.  The asset viewed will be limited to the available RSA warehouses holding asset under the specified Owning RIC.
 
2.1 ELMS shall allow the Inventory Manager to reply with an (870S/AE_ Cancelation) or proceed to the Material Redistribution module, within the Material Management (MM)/ ICP module.  
 
2.2 If the Inventory Manager locates a NSN with the requested Condition Code, ELMS shall allow the Inventory Manager to create an MRO using the Material Redistribution function.
 
2.3 ELMS shall generate an (940R/A2_) Material Release Order (MRO) to be sent to the losing warehouse DoDAAC.  Note:  It is important to perpetuate the Project Code “3AB”
 
2.4 ELMS shall send the (527D/DW_) Pre-position Material Receipt (PMR)) transactions to the Depot, Remote Storage Activities (RSAs) that originally sent the induction (511R/A0) with Project Code “3AB”.
 
3.0 Using ELMS, the losing Warehouse DoDAAC will process the inbound induction MRO using the Warehouse Module (WM). The warehouse person will (pick, pack, and release) the asset requested for induction.
 
3.1 ELMS shall generate the (870S/AE_ “BA”) and the (856S/AS_) shipping status notifying the Depot, Remote Storage Activities (RSAs) that the asset is on it way. Project Code “3AB” should remain on all documents. The (856S/AS_) will be used as the trigger to reduce the available on hand balance moving the asset in the system to intransit.    
 
3.2 ELMS shall generate the (945A/AR0) and send it back to the ICP, in the Material Management (MM)/ICP module, reporting the asset is now intransit.
 
4.0 ELMS shall provide the Depot, Remote Storage Activities (RSAs) with a capability to receipt for the induction asset document.
 
4.1 ELMS shall upon receipt, and quality control verification produce a receipt (527R/D6_).
 
4.2 ELMS shall gain the asset to the Depot, Remote Storage Activities (RSAs) warehouse DoDAAC.
 
4.3 ELMS shall post the (527R/D6_) to the historical transactions activity log allowing for associated Key Supporting Documents (KSD) to be added later.
 
4.4 ELMS shall add the completed receipt’s (527R/D6_) quantity to the “on hand available “in Inventory Manager’s Material Management (MM)/ICP view and completing out the document.
Mission Critical:
Approved DLMS Change (ADC) 1176
 
Benefits:
 
Meets MARCORLOGCOM's business model
Assists in 100% Accountability of assets
Complies with current audit controls
 
Frequency: Daily
 
Users: 

All USMC WH Managers
02160 KSA Obtainment Enterprise Level Material Management Module PA,Warehouse,Materiel Management USMC New
Change Request: Process Improvement

Description:
ELMS currently does not provide the Material Manager / Inventory Manager with the ability to view and download Key Supporting Documents (KSD) associated to a specified NSN and or serial number present, Document Number, or ICN within any of the USMC identified Logistic Programs (LPs) within the Warehouse Module and the Property Accountability (PA) module.  This capability is currently missing from within Material Manager (ICP) module.  Where applicable, automate KSD retrieval requests to support analytical and audit tasking. Transactional audit trail retrieval and sequencing (e.g. Material Transaction history), by applied date is required, to include the ability to select a given transaction from the displayed listing and drill down to obtain any attached KSDs. This capability is required to support audit inquiries, and the day-to-day operational capabilities required for MARCORLOGCOM’s inventory manager to perform their tasking.   Transactional audit trail retrieval must include all transactions applied to any given Inventory Control Number (ICN) historically, to include all KSDs like (receipts, material movements, physical Inventories, Limited Technical Inspections, MROs, Maintenance, etc.).
 
Recommended:
 

1.0 ELMS shall provide the Inventory Manager, within the Material Management module, the capability to search historical and active records by a specific National Stock Number (NSN) and or Serial Number combination, Document Number or Inventory Control Number (ICN).

 
1.1 Within ELMS, the system shall provide the Inventory Manager with a choice to perform the search through:
 
        a.  All Logistic Programs (LPs) LPs within any of the USMC identified within the Warehouse Module and the Property Accountability (PA) modules or
 
b.  Only with historical and active records pertaining to the warehouse DoDAACs associated with the ICP.  
 
This capability is currently missing from within Material Manager (ICP) module.
 
1.2 ELMS shall display all requested results from the specified search through and online view.
 
1.3 ELMS shall, within the set of data being displayed from requirement 1.2 provide a mechanism to display and or download Key Supporting Documents (KSD).
 
like (receipts, material movements, physical Inventories, Limited Technical Inspections, MROs, Maintenance, etc.).  
 
 
Mission Critical:
 
 
Benefits:
 
Meets MARCORLOGCOM's business model
Assists in 100% Accountability of assets
Complies with current audit controls
 
 
Frequency: Daily

 

Users: 

All USMC WH Managers
02159 Denial Transaction (DLMS 945AA6_) Narrative Warehouse,Materiel Management USMC New
Change Request: Process Improvement
Description:
During the creation of a denial transaction (DLMS 945A/A6_), by the Warehouse Module (WM), no reason code or explanation is given to why the denial was produced.  This does not provide the Inventory Manager, working in the Material Management (MM) module enough information as to conduct follow-on action such as back-ordering, filling the requisition from an alternate RSA withing the ICP arena, or canceling the requisition.  It also does not appear that there is a means to search for a denial transactions associated to a specific document number.
 
Recommended:
1.0 ELMS, shall provide an ability for a warehouse person, working the Warehouse Module (WM), to enter a narrative to why a document received a denial during the 940R fulfillment and issue process.
 
1.1 ELMS shall associate the denial narrative directly to the document which it pertains to.
 
1.2 ELMS shall make the document number and the denial narrative available to be search for in the Warehouse Module (WM) and the Material Management (MM) module.
 
 2.0 Once the (DLMS 945A/A6_) has been produced by the Warehouse Module (WM) and sent to the Material Management (MM) module with the denial narrative, ELMS shall provide the Inventory Manage with three option to handle the inbound denial.
 
 a.  Back Order the customer requisition advancing the suffix code to the next available sequence.  In addition, ELMS shall transmit an (870S/AE_) back to the originator of the purchase order.  See attached document, "ME Sourcing Handbook 4.10.24.docx", page 30-33 for the approved USMC status codes authorized for use.
 
 b.  Cancel the customer requisition, ELMS shall transmit an (870S/AE_ ) back to the originator of the purchase order. See attached document, See attached document, "ME Sourcing Handbook 4.10.24.docx", page 30-33 for the approved USMC status codes authorized for use.
 
 c.  ELMS shall provide the Inventory Manager with the ability to attempt to release from another ICP location.  This will be done through the customer requisition mode in the Material Management (MM) module.
 
2.1 ELMS shall provide the Inventory Manager with the ability to select the appropriate backorder or cancellation status using the information provided in the attached document labeled, "ME Sourcing Handbook 4.10.24.docx", page 30-33 for the approved USMC status codes authorized for use.
 
Mission Critical:
 
 
Benefits:
Meets MARCORLOGCOM's business model
Assists in 100% accountability of assets
Complies with current audit controls
 
Frequency: Daily
 
Users:
Affects USMC Materiel Managers, WH Managers and ICP
02158 MCPIC Speed to Count Inventory Warehouse USMC New
Change Request: Process Improvement

Description:
MARCORLOGCOM has a requirement to continue what is known as the MCPIC speed-to-count inventory process.  This is a key, “MUST HAVE” capability that was previously missed in the WG3 end-to-end evaluation. The process being addressed has been documented in the attached business process map.  This process differs from the Consolidate Support Program (CSP) containerization MCPIC support interface.  This process used key robotic functionality to optimize the successful execution of an inventory in a significantly reduced time frame.  This process has been a key success point in ensuring we stay audit compliant.
 
Recommended:
 
To ensure all elements of the inventory process is documented and expectation clearly articulated, the following requirements are submitted.  We know that ELMS is currently coded with a robust inventory process that was previously designed to support how the Stock Control System (SCS) required transactional execution.  We ask that all steps and requirements be evaluated within ELMS to ensure stakeholder expectations are met.
 
1.0 During the execution of an inventory, ELMS using the Warehouse Management (WM) module shall provide a mechanism for the warehouse person to select between a MCPIC managed inventory and a manually schedule execution of a location driven cycle count.  
 
Note: A MCPIC managed inventory is one that use automation capability to receive and transfer data automatically.  The physical inventory is conducted using robotics.
 
1.1 After a “MCPIC managed inventory” is selected, ELMS shall conduct a verification to ensure a location cycle count for that same NSN and site has not already been scheduled.
 
1.2 If a “MCPIC managed inventory” already exists, ELMS shall provide a notification and direct the user to the already scheduled location cycle count to begin execution.  Move to 2.3 in the diagram
 
2.0 ELMS shall allow the warehouse person to generate an inventory cycle count.  
 
2.0.1  ELMS shall auto generate a unique cycle count.  
 
2.1 ELMS shall provide a mechanism to the warehouse person to select the type of MCPIC inventory, (Container, NSN, or Location).
Note:  Marine Corps Force Storage Command primary conducts inventory by (site, NSN, and location).
 
2.2 ELMS shall provide a mechanism to the warehouse person to identify if the inventory is part of a plan cyclic inventory or unscheduled inventory (also known as a spot inventory).
 
2.3 ELMS shall freeze all transactional movement of the NSNs that has been identified by the location selected.
 
2.4 ELMS using the agreed upon XML data exchange format, shall generate the required file for transmission to MCPIC.

2.5 ELMS shall transmit, via an API, the XML file staged for transmission.
 
2.5.1 ELMS shall establish a means to verify the transmission was received in its entirety by MCPIC.  
Note:  Steps 2.6 – 2.8 is executed by MCPIC
 
2.9 ELMS shall code the system to accept a reply from MCPIC, via an API where the agreed upon XML formatted is met, that represents the completed results of a cycle inventory count.
 
2.10 ELMS Shall verify all incoming results from a MCPIC inventory for a specified cycle count.  If the balance from the inventory count matches what ELMS has a record for (serial number), then update ELMS with the date inventoried. As part of verification, ELMS will not accept a MCPIC inventory for a date outside the parameter specified in the request to inventory.
 
3.0 ELMS shall provide a mechanism for the warehouse manager to display the results of the, “MCPIC managed inventory”.  
3.0.1 If the results of the inventory indicate an item has been move to a different location, ELMS will conduct a location move to match the MCPIC reported location.
Note:  It is, however, the overall responsibility of the Accountable Officer to conduct causative research when there is an imbalance between what is being reported in ELMS and what was reported by MCPIC.
3.1 ELMS shall provide the Accountable Officer with means to accept the inventory results producing the required DLMS 947I (Inventory adjustment transactions D9A/D8A) when applicable.
Note:  The Accountable Officer must complete the required Financial Liability Investigation of Property Loss (FLIPL) process as prescribe by MARCORLOGCOM policy prior to submitting any adjustment.  This is an administrative item outside of ELMS.
3.2 ELMS shall produce a Money Value Gain and Loss (MVGL) notification statement.  Based on the threshold, the Accountable Property Officer (APO) may be allowed to sign vice the Accountable Officer.
3.2.1 ELMS shall provide the Inventory Certifying Officer with the capability to acknowledge that all MVGLs and FLIPLs have been completed prior to certifying the inventory.  
3.3 After the Inventory Certifying Officer has, within ELMS completed the certification, ELMS shall process all directed adjustments within the system.
3.4 – 4.0  ELMS, coordinating with MCPIC shall develop an automatic way of reconciling location records to ensure synchronization is occurring and maintained.
 
Mission Critical:
 
 
Benefits:
 
Meets MARCORLOGCOM's business model
Assists in 100% Accountability of assets
Complies with current audit controls
 
 
Frequency: Daily

 

Users: 

All USMC WH Managers
02157 Physical Inventory at the Enterprise Level Warehouse NECC New
Change Request: Process Improvement

Description:
We are requesting the addition of functionality within the Inventory process to enable users to conduct inventories by Reportable Commodities at the Enterprise level. This enhancement would allow users to schedule inventories for an entire commodity type across a specified Region or Site, thereby improving inventory management efficiency and ensuring timely accountability for assets across broader organizational scopes.
 
Recommended:
 
During the Inventory process, users with the appropriate Region/Site access should be able to select an optional Region/Site on the same interface where they can choose specific Reportable Commodities for inventory. Additionally, an Enterprise Rollup selection feature could be included, enabling users to select an entire Region/Site for inventory at once, streamlining the process and enhancing inventory management capabilities.
 
Mission Critical:
NECCINST 5200.45
 
Benefits:
 
The addition of this capability would empower users to conduct inventories across multiple warehouses or an entire Region/Site simultaneously, significantly enhancing the efficiency and speed of the inventory process.
 
 
Frequency: Daily

 

Users: 

All users who utilize multiple warehouses and the Physical Inventory function.
02156 Adding Attachments to Multiple Records Warehouse NECC New
Change Request: Process Improvement

Description:
We are requesting the implementation of functionality within DPAS Warehouse that allows users to add a single attachment to multiple records simultaneously. Currently, attachments must be added individually to each record, which is highly time-consuming—particularly in scenarios such as uploading identical birth documents to a large number of serialized assets. Enabling batch attachment functionality would greatly enhance efficiency and reduce administrative workload.
 
Recommended:
 
Requesting an enhancement to the current functionality that would allow users to apply the same attachment to multiple records within the Selected Inventory tab under the Inventory Update Manager/User function. This improvement would streamline the process of associating common documentation—such as birth documents—with multiple inventory records, thereby increasing efficiency and reducing administrative burden within asset management workflows.
 
Mission Critical:
In accordance with NECC instruction 5200.45, all supporting documentation must be retained in a centralized repository (DPAS).
 
Benefits:
 
Having this capability will reduce the man hours associated with adding Key Support Documentation to all assets within the NECC Logistics Program, streamline the process and enhance efficiency when managing multiple records that require the same documentation.
 
 
Frequency: Daily

 

Users: 

This functionality would be utilized by the majority of NECC DPAS users who perform receiving, transfer, and issuance operations for all assets required to be recorded in DPAS.
02155 Adding Manage SKO to Inventory Update Manager Warehouse NECC New
Change Request: Process Improvement

Description:
We are requesting enhanced functionality within DPAS to allow for the replacement of SKO components or the modification of their condition codes in a more timely and efficient manner. At present, users are limited to two options: either route the SKO through the QA/QC process or fully disassemble the SKO, update condition codes or replace components, and then reassemble it. This process is time-consuming and introduces unnecessary operational delays.
 
Recommended:
 
Integrating the existing Manage SKO functionality, currently utilized within the QA/QC process, into the Inventory Update Manager would streamline workflows and reduce processing time for users when performing component swaps or updating condition codes.
 
Mission Critical:
In accordance with NECC instruction 5200.45, all SKO assemblies need to be updated regularly to maintain inventory accuracy and material readiness status
 
Benefits:
 
Implementing this capability will significantly reduce the man-hours required to replace SKO components or update their condition codes, thereby increasing overall efficiency and minimizing resource expenditure.
 
 
Frequency: Daily

 

Users: 

This functionality would be utilized by the majority of NECC DPAS users who perform receiving, transfer, and issuance operations for all assets required to be recorded in DPAS.
02154 Allocation Mgmt - Add Location field NECC New
Change Request: Process Improvement

Description:
At present, the Allocation Management Search Criteria functionality allows users to search for various types of allocations associated with specific assets. However, users have expressed the need for enhanced search capabilities, specifically the inclusion of a Location field. This addition would enable users to filter and identify items that are allocated within a designated location, thereby improving the efficiency and accuracy of allocation searches.
 
Recommended:
 
Add a Location field to the Search Criteria within the Allocation Management functionality to allow users to filter results based on specific allocation locations.
 
Mission Critical:
NECCINST 5200.45
 
Benefits:
 
Adding this search field will help in searching for allocations within a specific location.
 
 
Frequency: Daily

 

Users: 

This functionality would be utilized by the majority of NECC DPAS users who perform receiving, transfer, and issuance operations for all assets required to be recorded in DPAS.

 

Home  |  Security Notice    Official Defense Logistics Agency Logo    Disclaimer  |  Accessibility
 
Defense Logistics Agency (DLA)
Logistics Catalog and Data Solutions (LCDS)