IN REPLY 

REFER TO 

DEFENSE LOGISTICS AGENCY 

HEADQUARTERS 

8725 JOHN J. KINGMAN ROAD 

FORT BELVOIR, VIRGINIA 22060-6221 

MEMORANDUM FOR RECORD 

July 16, 2013 

SUBJECT: Defense Logistics Management Standards (DLMS) Joint Finance and Supply Process 

Review Committee (PRC) Meeting of June 20, 2013 

Purpose: DLA Logistics Management Standards Office hosted a Joint Supply and 

Finance PRC meeting at a conference facility located at 2000 Corporate Ridge, McLean, 

Virginia. Defense Connect Online (DCO) provided real-time viewing of presentations for those 

participants not attending in person. The focus of the meeting was review of Proposed DLMS 

Change (PDC) 1043 identifying DLMS revisions for adoption of Standard Line of Accounting 

(SLOA). Specific discussion topics included areas requiring further analysis for capturing 

SLOA data in DLMS transactional exchange, development of a Fund Code Web Application that 

expands the current fund code table to include selected SLOA data elements, and concerns 

surrounding impact of SLOA on establishment of fund codes. A listing of attendees, including 

over 125 participants, and all meeting related materials and briefings are available on the Finance 

and Supply PRC Web pages linked to the meeting agenda at http://www.dla.mil/j6/ dlmso/Programs/Committees/Finance/fmanceprc.asp or http ://www.dla.mil/j6/dlmso/Programs/Committees/Supply/supplyPRC.asp. 

Brief Summary of Discussion: Mr. Hammond (Finance PRC Chair) and Ms. Hilert, 

(Supply PRC Co-Chair) facilitated meeting discussions. 

1. Welcome and Opening Comments: Mr. Hammond, Ms. Hilert, and Mr. Donald Pipp, 

Director ofDLA Logistics Management Standards Office, extended their sincere appreciation 

to all participating in the meeting. Mr. Hammond provided the group information regarding the 

role of the DLA Logistics Management Standards Office, its' role as the Executive Agent for 

logistics information exchange, the DLMS change process and DLMS training opportunities. He 

also played an informational video explaining the role ofthe DLA Logistics Management 

Standards Office. Training information may be found at: 

www.dla.mil/j-6/dlmso/eApplications/Training/training.asp. 

2. PDC 1043, Revisions for DoD Standard Line of Accounting (SLOA)/Accounting 

Classification, dated March 5, 2013: 

a. DLMS Support of Standard Financial Information Structure (SFIS)ISLOAOverview 

Federal Recycling Program 0 Printed on Recycled Paper 

Attachment 

Page I 
Attachment

Page 2

(1) SFIS is a component of the Business Enterprise Architecture (BEA). Systems are 

subject to assessment through Investment Review Boards for compliance with BEA SFIS 

requirements. BEA 10.0 incorporates sixty-eight SFIS elements. SLOA comprises twenty-six 

current and new SFIS data elements. Component SLOA implementation plans were due to 

Office of the Deputy Chief Management Officer (ODCMO) and the Office of the Under 

Secretary of Defense (Comptroller), Business Integration Office (OUSD(C)(BIO)) on January 

14, 2013. To support financial audit readiness, the target implementation date for SLOA is 

September 30, 2014.

(2) Many logistics business events and DLMS transactions have the potential for a 

financial implication. DLMS business processes and transactions currently rely on referential 

table lookup from the Fund Code to Fund Account Conversion Table. This table indicates if a 

transaction is non-Interfund billing or it identifies the line of accounting data associated with a 

transaction for Interfund billing. 

(3) DLMS transactions will need to be modified via the PDC/Approved DLMS Change 

(ADC) process to support exchange of SLOA data elements as discrete data. To accommodate

legacy systems using 80 record position MILS transactions that will be operational beyond 2014

that cannot send or receive additional SLOA data, changes are being made to the current Fund 

Code to Fund Account Conversion Table to add some SFIS/SLOA data as discrete data 

elements. This table will be renamed as the SFIS Fund Code to Fund Account Conversion 

Table. SLOA data not accommodated by the SFIS Fund Code to Fund Account Conversion 

Table will only be available in DLMS variable-length transactions.

(4) PDC 1043 was staffed as the first in a series of anticipated change proposals to 

accommodate SLOA. Additional change proposals will be needed as process owners determine 

the best course of action for processes/support systems where the customer’s requirement is 

initiated outside the Service-sponsored system. Because the requirement is initiated outside the 

Service-sponsored system, SLOA data is not currently available for inclusion in the DLMS 

transaction.

b. PDC 1043 – DLMS Transactional Exchange. Mr. Hammond and Ms Hilert led a 

discussion of PDC 1043 dealing with DLMS transactional exchange and focused on, open

questions raised in staffing notes, and additional functional requirements.

(1) Applicability. PDC 1043 was staffed to enable transactional exchange of SLOA data 

via DLMS for supply logistics transactions with financial implications and supply logistics 

billing transactions. Other domains must similarly implement SLOA in coordination with 

ODCMO and OUSD(C)(BIO).

(2) PDC 1043 Staffing Notes Identifying Issues for further Analysis

(a) 842C/I Stock Screening Request. In this process, the owning Service requests 

a special inspection by DLA Distribution Depots. The requested work is associated with a MIPR 

provided by the materiel owner. PDC 1043 sought verification of whether SLOA data is needed 

for this business process. No Component responses were received. 
Attachment

Page 3

Resolution: The current understanding is that SLOA data will be captured during creation of the 

MIPR and need not be included in the stock screening request. No further action will be taken at 

this time. If required in the future, SLOA-related data requirements will be identified by 

separate DLMS change documentation. 

(b) Cost Objects. SLOA does not prescribe specific transaction requirements. 

Cost objects associated with financial accounting have meaning only to the buyer. Acquiring 

cost objects for many logistics processes/support services where the customer’s requirement is 

initiated outside the Service-sponsored system will be problematic. OUSD(C)/ODCMO 

responded that the cost objects are used as a compensating control where the requisition cannot 

be identified. USMC responded they do not need to transact cost object data. 

Resolution: Carry cost objects in designated DLMS transactions as optional data elements.

(c) Obsolete FA201 Qualifier Code l1. Code I1, Abbreviated Department of 

Defense (DOD) Budget and Accounting Classification Code (BACC), is already carried in the 

FA2 segment of some DLMS implementation conventions. PDC 1043 questioned whether this 

code is relevant now that SLOA has been defined and no legacy transition purpose has been 

identified. USMC indicated they have no need. No need was identified during the meeting.

Resolution: Proceed with removal; this is not a SLOA data element.

(d) FA201 Qualifier Code 18, Funds Appropriation. During staffing for ADC 

435 dealing with SFIS, DLA indicated a need to retain FA201 Qualifier Code 18 in the DLMS 

527R to support current processes. This qualifier is used by Defense Medical Logistics Standard 

Support (DMLSS) Army Medical Materiel Agreement (AMMA) to assist in communicating

purchase card receipt data and in certain current processes supporting DLA Disposition Services. 

DLA was asked to assess the potential of converting to use of SFIS data and whether these 

processes should be considered under business process reengineering for SLOA. No response 

was provided. 

Resolution: Retain and update the DLMS note to indicate interim usage pending future 

transition to SLOA data.

(e) Sub-Class Code. Sub-class codes are assigned in certain cases for grouping 

designated disbursement and/or receipt transactions below the level of appropriation or fund 

account represented by the main account for an appropriation, fund, or receipt account. 

Clarification was sought, because it appears the requirement may potentially be satisfied by the 

business event type code (BETC) for logistics transactions. Both sub-class code and BETC 

(discussed later) are used by Central Accounts Offices for Treasury reporting. 

OUSD(C)/ODCMO responded that sub-class is to identify different types of funds set aside as a 

breakout from the main account. Two types are Treasury standard values and non-standard 

values. Most DOD values are standard values that will be accommodated by the BETC.

However, Treasury did not allow this element to be eliminated since there is the potential for 

Treasury to assign values in the future. Currently, it is anticipated that the field would be null 

when BETC is fully implemented. Until BETC is fully implemented, there is one current 

scenario for disbursements or adjustments for obligations that would have been properly made 

to a cancelled appropriation that would cite sub-class 46. These may be disbursed from an 

unexpired appropriation with the same purpose up to a cumulative limit of one percent of the 
Attachment

Page 4

unexpired appropriation. To gain an appreciation of the prevalence, Mr. Hammond reviewed 

DLA backorders over five years old, since DLA is the predominate supplier. He found that this 

may only be applicable to approximately 100 requisitions each year. It is unclear if these are 

currently being accommodated by non-Interfund billing. Another possible scenario for the 

current sub-class code is borrowing in support of working capital funds, which cannot be 

comingled with other funds.

Resolution: Defer adoption of the sub-class code in DLMS transactions. Additional research 

and coordination will be required to confirm logistics requirements and determine business rules 

for use of sub-class. Upon completion of this effort, requirements will be re-staffed as an 

addendum to PDC 1043.

(f) Business Event Type Code (BETC). BETC indicates the type of financial 

activity, such as payments, collections, borrowings, etc., being reported in the Governmentwide Accounting and Reporting (GWA) system. BETC in effect replaces the Treasury's 

transaction codes. The staffing note sought clarification of how BETC would apply to logistics 

transactions or if it applied to only the financial Central Account Offices for Treasury reporting. 

OUSD(C)/ODCMO responded BETC will rarely be included in the SLOA before the point of 

disbursement. One scenario is for disbursements or adjustments for obligations that would have 

been properly made to a cancelled appropriation. These may be disbursed from an unexpired 

appropriation up to a cumulative limit of one percent of the unexpired appropriation. Another 

possible scenario, is borrowing in support of working capital funds that cannot be comingled 

with other funds.

Resolution: Defer adoption of the BETC in DLMS transactions. Additional research and 

coordination will be required to confirm logistics requirements and determine business rules for 

use of BETC. Upon completion of this effort, requirements will be re-staffed as an addendum 

to PDC 1043.

Actions:

• Mike Shannon of ODCMO will identify relevant BETCs. Suspense: August 29, 2013

(g) Department Transfer Code. The department transfer code identifies the 

federal agency of obligation authority to the DOD or one of its components. For the transfer of 

obligation authority, the transfer agency retains responsibility for the fund account and the 

recipient agency charges against the fund account of the transfer agency. The SFIS Fund Code 

to Fund Account Conversion Table is being updated to add department transfer code, and DLMS 

transactions have been updated to carry the department transfer code. However, it is not 

apparent that this data element is necessary for logistics transactions. OUSD(C)/ODCMO 

responded the Treasury Account Symbol (TAS) needs to identify which Federal Agency is the 

owner of the funds to allow proper segregation of funds. For example, Foreign Military Sales 

(FMS) appropriations are transferred to DOD from the Executive Office of the President, so

DOD must identify Department Transfer value “011”.

Resolution: Add Department Transfer Code to the SFIS Fund Code to Fund Account 

Conversion Table and pass in DLMS transactions as applicable.
Attachment

Page 5

(h) Reimbursable Flag. The reimbursable flag indicator is used to identify those 

expenditures incurred for a designated Treasury Appropriation Fund Symbol (TAFS) account 

that are considered reimbursable to the account. PDC 1043 requested clarification regarding 

whether an Interfund bill is only reimbursable, such that the reimbursable flag may not be

required in DLMS. OUSD(C)/ODCMO responded that the element relates to how the 

appropriations are defined, not whether the action is reimbursable. Appropriations are 

designated as R (Reimbursable) or D (Direct). Appropriations can include both R and D. The 

reimbursable flag clarifies which is applicable to a business event with financial implications. 

The requisitioner would record an obligation as either direct or reimbursable. When ordering 

from others, the determination would be based upon the intent of the requisition (e.g. for self-use 

or use on behalf of another). This would have application, for example, for working capital 

funds.

Resolution: Carry reimbursable flag in DLMS. Consider for inclusion in the SFIS Fund Code 

to Fund Account Conversion Table as in a subsequent development phase.

Action:

• Components advise the Finance PRC Chair if it is feasible to add reimbursable flag to the 

SFIS Fund Code to Fund Account Conversion Table as a future enhancement. Suspense:

August 29, 2013.

(i) Security Cooperation (SC) Customer Code. The SC customer code identifies 

the customer country/international organization, or account for security assistance. The SC 

Customer Code is embedded as the 2nd and 3rd positions of the document number for DLMS 

security assistance transactions. The SFIS matrix business rule allowing 3 alpha-numeric codes

conflicts with current guidance for using two character codes consistent with the listed Defense 

Security Cooperation Agency (DSCA) values, which are the authoritative source. ODCMO was 

asked to confirm proper syntax and business rule for this element and related SFIS element 

Country Code (T12). OUSD(C)/ODCMO responded that SC customer code includes noncountries. SC customer code syntax is a maximum of three characters. While all current values 

are two characters, DSCA is allowing for future growth. Ms. Hilert noted that, because it is part 

of the document number and used to construct the military assistance program address code 

(MAPAC), expansion of the SC customer code to three characters has significant impacts for 

MILSTRIP and MAPAC processes. Such a change would essentially break the logistics process 

for security assistance requisitioning and shipment. At a minimum, expanding the field length to 

three characters requires a PDC to communicate the business rules and procedure changes and 

define a proposed implementation strategy. Meanwhile, DSCA has indicated that they are 

currently exploring changes to internal processes that assign SC customer codes to specific 

appropriations, which adds significantly to the number of SC customer codes needed.

Resolution: Logistics processes under the DLMS will retain a two character maximum length. 
Attachment

Page 6

Actions:

• DSCA revalidate this requirement in light of the logistics impact. If to be pursued, 

determine how to accommodate in MILSTRIP and MAPAC processes. DSCA submit a 

PDC as required. Suspense: August 29, 2013

(j) Security Cooperation (SC) Implementing Agency. This is a single character 

alpha code that identifies the U.S. Military Department or Agency that has negotiated or 

facilitated a foreign military sales (FMS) case on behalf of the U.S. Government. It has its roots 

in the DLMS Service and Agency (S/A) codes. The BEA element cites values from Security 

Assistance Management Manual (SAMM) (available from the E-SAMM Web at 

http://www.dsca.osd.mil/samm/) that do not align with some logistics S/A codes. For example,

the E-SAMM code for DLA (R) does not align with the S/A code for DLA FMS (T) and it 

conflicts with an S/A code for Navy. Some other SC implementing agency codes (C, F, M, Q, 

U, Z) conflict with codes assigned for requisitioning purposes in the S/A code list; however, 

these are currently non-requisitioning implementing agencies. 

Resolution: DLM 4000.25-1 MILSTRIP Appendix 2.2 S/A codes are the authoritative source 

for supply transactions (e.g., requisitioning). DSCA research whether SAMM codes can be deconflicted.

Actions:

• DSCA research de-conflicting of SAMM SC Implementing Agency codes with

MILSTRIP Appendix 2.2 S/A codes; advise Finance and Supply PRC Chairs.

• DSCA verify if they can derive DLA from S/A Code T or if the Defense Automatic 

Addressing System (DAAS) needs to map between S/A Code T and Implementing 

Agency Code R during transaction processing to populate SLOA discrete data element in 

the financial segment of the transaction. Suspense: August 29, 2013

(k) Security Cooperation Case Designator. Security cooperation case designator 

code is used to reflect an FMS contractual sales agreement (Letter of Offer and Acceptance) 

between the U.S. and an eligible foreign country. This element is embedded as the last three 

positions of the supplementary address in Security Assistance related transactions. It was 

already to be carried as a discrete data element by DLMS enhancement under the name FMS 

Case Number. Subsequent to the Joint Finance/Supply PRC meeting, it was identified that the 

SLOA element has a maximum length of four positions. This field length cannot be 

accommodated within the MILSTRIP supplementary address field, which must be retained for 

legacy MILSTRIP users (including the FMS countries transmitting and receiving legacy 

MILSTRIP transactions). DSCA has been advised of this issue and will review impact and reassess the requirement.

Resolution: The DLMS data element will be updated to align with the SLOA data element 

name recorded in the BEA. DAAS will derive from the last three positions of supplementary 

address for legacy conversion.
Attachment

Page 7

Actions:

• DSCA revalidate the maximum field length requirement of four characters, in light of the 

legacy logistics impact. If to be pursued, determine how to accommodate in legacy 

MILSTRIP processes. DSCA submit a PDC if four characters are a valid requirement. 

Suspense: August 29, 2013

(l) Sub-Allocation Holder. Sub-allocation holder identifies an organization to 

which funds have been sub-allocated. The legacy terminology was “limit/subhead”.

Limit/Subhead is referentially provided via the current Fund Code to Fund Account Conversion 

Table. It will be included in the SFIS Fund Code to Fund Account Conversion Table to ensure 

continuity of operations, even though values may duplicate those ultimately assigned to suballocation holder. This is necessary because potential assignment of additional sub-allocation 

holder values to a main account may cause the number of fund codes to exceed the maximum 

available from the two position fund code. Currently only the legacy limit/subhead values make 

up sub-allocation holder. Future coordination will be needed to determine if limit/subhead can 

be mapped to sub-allocation holder. A work group will be needed to layout an approach to 

design code assignments to gradually replace the legacy codes. OUSD(C)/ODCMO noted that 

there are issues with standardizing the values.

Resolution: Limit/Subhead will be retained on the SFIS Fund Code to Fund Account 

Conversion Table. Sub-allocation holder will be included in DLMS. DAAS will not map 

between the SLOA and legacy data elements. OUSD(C)/ODCMO will notify the Finance PRC 

Chair upon forming a working group for sub-allocation holder.

(m) Project Identifier. In SLOA, a project identifier represents a planned 

undertaking of work to be performed or product to be produced having a finite beginning and 

end. In the DLMS, the three position project code is a separate data element. The SLOA project 

identifier may be different or it may repeat the project code value identified for logistics 

purposes making it is necessary to carry both codes in DLMS. OUSD(C)/ODCMO noted no 

issues with this approach.

Resolution: Retain existing project code in the LQ01 = 78, and include SLOA project identifier

in FA201 (or REF01 as applicable). DAAS will not map between the data elements.

(n) Activity Identifier. PDC 1043 sought clarification regarding the maximum 

length for activity identifier. There is a conflict in the SFIS matrix regarding the maximum 

number of characters for the length characteristic (16) and the maximum number of characters in 

a business rule (15). OUSD(C)/ODCMO responded that the correct maximum length is 16.

Resolution: Update DLMS documentation to reflect maximum length 16. OUSD(C)/ODCMO 

update the BEA as needed.
Attachment

Page 8

(o) Cost Element Code. PDC 1043 sought clarification on the maximum length 

for cost element code. There is a conflict in the SFIS matrix regarding the maximum number of 

characters for the length characteristic (16) and the maximum number of characters in a business 

rule (15). OUSD(C)/ODCMO responded that the correct maximum length is 16.

Resolution: Update DLMS documentation to reflect maximum 16. OUSD(C)/ODCMO update 

the BEA as needed.

(p) Work Order Number. Under SLOA, work order number identifies an 

individual unit of work, batch, or lot of a distinct product or service. Under DLMS, the work 

order number and the job order number may be carried for specific user communities as separate 

data elements in various transactions. The SLOA work order number may be different or may 

repeat one of the values already identified for logistics purposes.

Resolution: Retain the existing DLMS work order number and job order number in the REF/N9

segments. Include the SLOA work order number in FA201 (or REF01 as applicable) for 

optional use. DAAS will not map between the data elements.

(3) Additional Functional Requirements. There is no efficient, cost-effective solution 

identified for the many logistics processes/support services where the customer’s requirement is 

initiated outside the Service-sponsored supply system. Because of this, the SLOA data is not 

available for inclusion in the DLMS transaction. It is envisioned that separate PDCs will be 

provided for each of these as they are evaluated and the process owner determines the 

appropriate course of action. This may require a coordinated approach with all trading partners 

to include consideration of potential new system development/interfaces. DLA Logistics 

Management Standards Office is aware of some DLA processes where this may apply and has 

recommended DLA J33 research solutions. Ms. Hilert suggested that the Funds Verification 

module for Web ordering systems might be explored as an approach for the seller to obtain 

missing SLOA data for some of these processes. PDC 1068 for Funds Verification has been 

staffed; this process change enables offline requisitions to be systemically coordinated with a 

Service system to verify funds availability, record the obligation, capture the due-in and enable

some edits. It may be possible to gain some missing SLOA data through future enhancements to 

this process. Components will need to examine their processes for additional functional 

requirements. Some additional functional requirements are shown below.

(a) Post-Post Operations. A “post-post” issue involves accepting and updating 

records after the event (or issue) has occurred. One form of the post-post process includes the 

Directed Materiel Release Order (MRO) that may be entered by authorized personnel to direct 

release of materiel from a storage site without prior ICP processing of the requisition. The 

customer initiating the requirement has no systemic interface with the system preparing the 

transaction in order to provide SLOA data content. When this process is used, the first 

transaction available is the DLMS 511R for the DLA Directed MRO (Requisition) (equivalent to 

DLA legacy C0A/C01) or DLA Directed MRO (Referral Order) (equivalent to DLA legacy 

CQA/CQ1). In other scenarios, the issue transaction is the first available DLMS transaction.

Action:

• Mr. Jim Weiner, DLA Distribution Standard System analyst, and Ms. Hilert will review 
Attachment

Page 9

DLA’s post-post processes to identify best method of integrating SLOA requirements. 

Suspense: August 29, 2013

(b) Tailored Vendor Relationship (TVRs) and Industrial Prime Vendor (IPV). 

These are programs where there is a direct relationship between the customer and the vendor. 

Customers communicate the materiel requirement directly with the vendor outside normal supply 

system requisitioning channels and may have no mechanism to provide SLOA data, even if it 

were readily available. In one Army scenario, the requisition would have a DLA contractor 

DoDAAC, but the bill-to party may be the Service DoDAAC. USMC asked if there was any 

awareness of USMC applicability.

Action:

• Ms. Hilert will investigate if TVR/IPV applies to USMC. Suspense: August 29, 2013

(c) DLA Disposition Services. When customers use DLA Disposition Services for 

e-tools (e.g. Electronic Turn-in Document (ETID), Reutilization Transfer Donation (RTD)) or 

processing their turn-in using a hand-written DD-1348-1A Issue Release/Receipt Document 

(IRRD), initial DLMS transaction exchange is bypassed and SLOA data elements are not 

available. This is only significant when the turn-in is eligible for credit from the proceeds of the 

sale or charges associated with reimbursable actions for hazardous waste/materiel disposal.

(d) Web-Based Requisitioning. The customer initiating the requirement has no 

systemic interface with the system preparing the transaction to provide SLOA data content. A 

combination of customer profile enhancements and system interface with the Service 

finance/supply system may need to be considered.

(e) Supply Shipment Documentation. MILSTRIP procedures require DOD 

shipments be accompanied by an Issue Release/Receipt Document (IRRD) (DD Form 1348-1A 

or DD Form 1348-2). This document displays the legacy transaction format by record position,

including the fund code. There are currently no provisions for display of SLOA data elements. 

Additionally, there are specific rules associated with hazardous waste/materiel turn-in for 

including the bill-to DoDAAC and with the funds citation for reimbursement of scrap proceeds 

on the IRRD. USMC recommended responsible organizations examine their use of other forms,

such as SF 1080 and DD 1149, for incorporating SLOA data.

(f) WEB Requisitioning (WEBREQ). WEBREQ is a DLA Transaction Services 

Web product that provides customers a means to input materiel requisitions, cancellations, 

follow-ups, modifications, and Materiel Obligation Validation (MOV) documents either 

interactively or input via an ASCII file. If WEBREQ is not subsumed by DOD EMALL, it 

would be an additional functional requirement for it to incorporate SLOA and audit readiness 

requirements. There is also a potential for impact on the DLA Transaction Services Automatic 

Message Exchange System (DESEX), a telephone and Web-based system used for routing 

transactions and providing customer support.
Attachment

Page 10

Action:

• DLA Transaction Services will investigate future plans for WEBREQ and DESEX and 

potential impacts for inclusion of SLOA data elements and performance of funds 

verification checks/posting of obligations. Suspense: August 29, 2013

(4) 810L Header FA2 Changes. The 810L is unique in that it contains an FA2 segment 

in both the header and detail sections to provide summary as well as detailed billing information. 

PDC 1043 opened up the FA2 segment in the detail section in order to facilitate discrete SLOA 

elements of the buyer. However, changes are also needed to the existing FA2 in the header 

section for SLOA data applicable to the seller for the summary bill. Additionally, changes are 

needed to two qualifiers in the FA2 header to correct DLMS notes to indicate that only one 

occurrence of the loop is allowed.

Action:

• DLA Logistics Management Standards Office will incorporate necessary updates for 

publication of ADC 1043.

(5) Agency Accounting Identifier (AAI) – Potential Alternatives

(a) Agency Accounting Identifier (AAI) identifies the accounting system 

responsible for recording the accounting event (i.e. AAA/ADSN/FSN). As a possible alternative 

to support near-term implementation, a concept was proffered to possibly derive AAI 

referentially from the DoDAAD based on current business rules that demonstrate some viability 

of the data already being resident in the DoDAAD.

(b) In the ensuing discussion it was noted that AAI may not be synonymous with 

DoDAAD use of AAA/FSN/ADSN, which may not be the accounting system responsible for 

recording the event.

(c) Another alternative was identified for exploration, which is to include the AAI 

as a data element in the SFIS Fund Code to Fund Account Conversion Table. This would require 

that the AAI be unique for each fund code. 

Actions:

• Fund Code Monitors evaluate if there would be enough fund codes available to include 

AAI in the SFIS Fund Code to Fund Account Conversion Table. Suspense: August 29, 

2013
Attachment

Page 11

b. PDC 1043 Fund Code Issues and Web Fund Code Application. Mr. Hammond 

discussed fund code issues, as well as the SFIS Web Fund Code Application being developed by 

DLA Transaction Services. This Web application is planned to support some SLOA data 

referentially as discrete data. DAAS will populate available data elements from the SFIS Fund 

Account to Fund Conversion Table into DLMS transactions with missing content and for 

conversion of legacy-formatted transactions to the DLMS format. Missing or invalid fund codes 

are problematic. Assignment of distinct fund codes for multi-year accounts is potentially 

problematic due to fund code limitations. To lay the foundation for Interfund billing and fund 

code procedures, Mr. Hammond first presented DLMS Finance Training (DLMS Introductory 

Training Module 4F). The Web application and limitations are discussed below.

(1) Goals. Goals of the Web Fund Code application are to

• facilitate legacy and future processes;

• support Treasury Account Symbol (TAS) and SFIS/SLOA by adding some 

key data elements to SFIS to Fund Account Conversion Table;

• enhance edits to improve financial processes and support audit readiness;

• facilitate real time update of fund codes by Fund Code Monitors;

• allow for staging fund codes for future effective dates;

• replace email distribution of fund code updates with system-to-system 

synchronization.

(2) Financial Data Elements. Currently, financial data is represented on the Fund Code 

to Fund Account Conversion Table as a concatenated appropriation string consisting of

department regular code, FY chargeable indicator, main account, and limit/subhead. The 

concatenated appropriation will be maintained as a discrete element; however, the above 

segments that comprise the appropriation will be added as discrete data elements. In addition,

some SFIS/SLOA elements will be added, including: department transfer code, beginning period 

of availability, ending period of availability, sub account, sub-class, and availability type.

(3) Other Data Elements. Other existing data being retained on the SFIS Fund Code to 

Fund Account Conversion Table includes: fund code, service code, signal code, effective date, 

and agency narrative. A new “legacy multi-year indicator” was added as a data element to 

indicate that the beginning and ending periods of availability for multi-year appropriations are 

not available from the SFIS Fund Code to Fund Account Conversion Table. This will assist in 

the transition and in the event that some fund codes cannot be transitioned at all. There are 

additional system data elements to support Fund Code Monitor Web access and internal controls. 

(4) PDC 1043 Edits. PDC 1043 requires DLMS users to continue to submit fund code 

and signal code along with discrete SLOA data elements per transaction mapping. This will

enable DAAS to map SLOA data from the SFIS Fund Code to Fund Account Conversion Table 

to DLMS to populate DLMS transactions when not provided by the originator. For data 

integrity, DLMS transactions will be rejected when there is inconsistency between SLOA data in 

the DLMS transaction and SLOA data identified by the fund code. In cases where there is a 

missing or invalid fund code in the transaction, DAAS will not be able to perform editing or 

mapping. There are some Intra-Service level edits performed by DAAS to reject some 
Attachment

Page 12

transactions with missing or invalid fund codes. These edits are not being changed by PDC 

1043. The current MILSTRIP edit (Table C3.T2) states, "No edit is required unless signal code is 

C or L. Reject if signal code is C or L and fund code does not identify a valid bill-to activity as 

prescribed by MILSBILLS."

(5) Potential Future DAAS Edits. Potential future edits may be considered for rejecting

• transactions with missing/invalid fund codes;

• bills with expired Availability Type C;

• bills with deleted fund code (these stay on the table for 5 years for 

information purposes unless reused).

(6) PDC 1009 Signal Code C and L Transition Plan. PDC 1009 provides guidance for 

use of Signal Code C/L for transition from legacy to DLMS by all trading partners. 

Requisitioning systems are directed to populate the bill-to/credit-to DoDAAC and this value will 

be perpetuated through the life cycle of the requisition. If populated, DLA Transaction Services 

will validate that the value in the transaction is the same as the value in the Fund Code to Billed 

DoDAAC Conversion Table to ensure that no errors are introduced by the transition to initiating 

system population of this value. Inconsistent use will trigger rejection using Status Code CX. 

Systems processing transactions containing Signal Code C/L will use the discrete value 

contained in the DLMS transaction, but will default to the Fund Code to Billed DoDAAC 

Conversion Table to identify the bill-to/credit-to DoDAAC if not populated within the 

transaction upon receipt. The intent is to eliminate use of the Fund Code to Billed DoDAAC 

Conversion Table upon full transition to DLMS. This may be accomplished at the Service level 

once a Service fully transitions to DLMS.

(7) Fund Code Table Synchronization. There is a disconnect between Fund Code to 

Fund Account Conversion Table (MILSBILLS Appendix 1.1) and Fund Code to Billed Office 

DoDAAC Table (MILSBILLS Appendix 1.2 ) used for third party billing (Signal Code C/L). A 

proposed edit would require for DOD Signal Code C/L that the fund code must be on both the 

SFIS Fund Code to Fund Account Conversion Table and the Fund Code to Billed Office 

DoDAAC Table. Default fund codes would be removed from the SFIS Fund Code to Fund 

Account Conversion Table for Signal Code C/L. Non-Interfund billing fund codes would be 

included on both tables.

Action:

• FPRC and Fund Code Monitors provide comments on the feasibility of incorporating 

table synchronization between the SFIS Fund Code to Fund Account Conversion Table 

and the Fund Code to Billed Office DoDAAC Table for the Web Fund Code Application. 

Suspense: August 29, 2013

(8) Implementation Concept of Operations (CONOPS). For the initial population of 

SFIS Fund Code to Fund Account Conversion Table data, DLA Transaction Services will 
Attachment

Page 13

convert existing data. Then, Service Fund Code Monitors will supply additional data for bulk 

upload by DLA Transaction Services. Components would begin FY 2014 with new fund codes 

for any period of availability that includes FY 2014. All requisitions going forward would 

properly reflect the beginning and ending periods of availability for the TAS that the seller is 

required to have for Interfund billing. Existing legacy multi-year appropriations will be flagged 

on the SFIS Fund Code to Fund Account Conversion Table using the legacy multi-year indicator 

to show that the beginning and ending periods of availability is not available from the table for 

these fund codes. By the end of FY 2014, the vast majority of items previously requisitioned 

with legacy multi-year fund codes would have been delivered and billed. Only backordered 

items with multi-year fund codes are of concern; backorders for single-year and no-year 

appropriations are not a concern. Some backordered item options might include

• buyer modify backorder requisition to replace fund code;

• seller bill via non-Interfund;

• Components advising OUSD(C) and ODCMO that some transactions may 

still require buyer side adjustments at Treasury to correct periods of 

availability.

Action:

• FPRC and Fund Code Monitors provide comments on the feasibility of options identified 

for backordered items with multi-year fund codes. Suspense: August 29, 2013

(9) Fund Code Limitations. Fund code is two characters, thus limiting the number of 

possible fund codes to 1296 per Service/Agency and signal code combination. This number 

includes use of numeric 0, 1 and alpha I, O. Once used, a fund code must remain on the SFIS 

Fund Code to Fund Account Conversion Table for five years past the ending period of 

availability in order for bills to process. Thereafter, current year funds must be used to pay the 

bills. Adding beginning and ending periods of availability for multi-year appropriations, which is 

proposed, is potentially problematic. Single year and no-year appropriations will not be 

impacted. There is potential for overwhelming demand for new fund codes for multi-year 

appropriations. Component processes for third party billing and extensive use of limit/subhead 

increase the demand for fund codes. Components were asked to examine possible changes to

Component processes and use of DLMS to address the demand for future fund codes. As a 

consideration, DLMS might be used to perpetuate and return data for buyer accounting purposes

that is not needed by the seller for Interfund billing. 
Attachment

Page 14

Actions:

• Components comment on their ability to add fund codes for each multi-year 

appropriation to fully implement the Implementation Concept of Operations. Suspense: 

August 29, 2013

• Identify alternative solutions and provide recommend COA, if the proposal is not 

feasible. Suspense; August 29, 2013

(10) Web Fund Code Access Controls. Fund Code Monitor will be appointed by 

Components through letters of appointment. Access roles for Component Fund Code Monitors 

will control access according to their assigned S/A codes. Fund Code Monitors will be required 

to submit System Access Requests to DLA Transaction Services, which will be validated against 

the appointment letter prior to granting access.

(11) Fund Code Output Options. A logistics report will still be available, but will be 

expanded to show SLOA data elements. Two options for report layouts were presented at the 

PRC, which are shown in the Web Fund Code Issues presentation slides 17 and 18. One option 

includes the concatenated appropriation along with the discrete elements, while the other leaves 

out the concatenated appropriation. Components were asked to provide feedback regarding a 

preference for one report layout or the other. There are also plans for a Web Service to provide 

Component application systems near real-time access to the database, and a downloadable file 

format, which will have access restrictions. DAMES emails will be continued until no longer 

needed. Web Services is the preferred output option.

Action:

• Components provide feedback on preferred logistics report layout. Suspense: August 

29, 2013

(12) Web Fund Code Application Current Status. DLA Transaction Services is 

completing application development and will submit the application to the DLA Internet Council 

for approval. In the event that the DLA Internet Council does not complete review and approval 

prior to September 30, 2013, the database will still be available and DLA Transaction Services 

will be able to accept and make fund code changes pending application approval. 

(13) Web Fund Code Application Demonstration. Due to time constraints, only an 

abbreviated demonstration of the application was provided. Another training session/

demonstration will be provided to Fund Code Monitors and interested parties in the near term.

Actions:

• Mr. Hammond will schedule and announce the training/demonstration. Suspense:

August 29, 2013
3. Deferred Topics. Due to time constraints, the following topics were not presented: federal 

agency modernization, DLMS 81 OL training, and discussion of significant ongoing initiatives, 

which include PDC 1 03 5 Increased Frequency of Interfund Billing, intra-governmental financial 

eliminations, a proposed Financial Management Regulation change, Treasury direct disbursing, 

and Invoice Processing Platform/Collaborative Agency Working Group. These may be 

addressed by future PRC meetings. Briefing slides for these topics (if available) are linked to the 

agenda. 

4. Next Meeting: Future Finance and Supply PRC meetings will be scheduled as needed. 

ROBERT HAMMOND 

Chair, DOD Finance PRC 

Approved:~ ...... J~_,... DONALD~ 

Director, 

DLA Logistics Management 

Standards Office 

ELLEN HILERT 

Co-Chair DOD Supply PRC 

~41114-tA-- HEIDI DA VEREDE 

Co-Chair DOD Supply PRC 

Attachment 

Page 15