Appendix B to Part 114 - Transaction and Editing Procedures For Submission Tapes  

1. All transactions flowing into the RCCPDS from the Reserve components apply to gains and losses (including transfers, reenlistments and extensions). Report the appropriate Reserve Component Category Designator (RCCD) and Reserve Component Training-Retirement Category Designator (RCTRCD) for all transactions, as follows:

a. For accessions, use codes for gaining categories listed in record field 92.a.

b. For transfers, use codes for categories to which transferred listed in record field 92.d.

c. For losses, use codes for categories from which loss occurred listed in record field 92.b.

2. The following conditions show examples of acceptable transaction practices:

a. When a Service member is transferred from the IRR to the Standby Reserve, submit a transfer transaction i.e. TN.

b. If a Service member transfers from one State to another, and continues as a Selected Reservist of the same Reserve component, submit no transaction.

c. If a Service member is transferred from the IRR and/or ING (or Standby and/or Retired) to the Selected Reserve, submit a transfer transaction. Do not submit a corresponding loss transaction for the decrease in IRR strength.

d. A loss to the Reserve component shall only be reported if a change from Reserve component appropriations to Active component appropriations occurs. That does not apply to Reserve component members performing duty for 180 days, or less, in support of an Active component mission that is being funded through Active component appropriations. Reserve component members shall be reported in RCCPDS in their current Reserve Component Category while performing that duty.

3. The occurrence of multiple transactions during a single reporting period is unusual. However, those must be reported against the same record in the same update cycle. The following conditions shall apply:

a. Include only valid gains, losses, transfers, reenlistments, and extensions.

b. Do not report record corrections resulting from erroneous gains, losses, reenlistments, or extensions. For example, if an erroneous “loss” is processed and then a corresponding “gain” is initiated during the same reporting cycle, do not report those transactions.

c. Ensure that the transaction effective dates of the various transactions are different.

All data submitted to the RCCPDS must be edited by the Reserve components for validity, reliability, and consistency before submission to ensure that the Reserve component strengths match the official strengths produced from the RCCPDS. At the Department of Defense, all master files and transaction inputs are edited before file update to ensure the accuracy of files and resulting reports. Use the following edit procedures to screen all input:

a. Duplicate SSN in a Reserve Component's Submission. When a duplicate SSN is found, accept the first occurrence and reject subsequent occurrences.

b. Duplicate SSNs Between Reserve Component Files. That procedure checks for duplication among Reserve components. It is applied after files are updated and does not result in rejects. As agreed to by the Reserve components, the DMDC shall provide each Reserve component periodic output from the RCCPDS to assist in reconciling errors. That maximally reduces the incidence of duplication, and encourages cooperation among the Reserve components.

a. Gains and Transfers. Check all gain and transfer transactions for Service member's status on last month's master file (previous month's submission).

(1) A gain from outside the Reserve component is valid only if the Service member's record did not exist on the Reserve component's last month's master file. If the Service member's record already exists on last month's master file, the transaction shall reject and not be counted.

(2) A transfer from inside the Reserve component (i.e. from IRR to Selected Reserve) is valid if the Service member's record existed on the Reserve component's last month's master file. If that condition is not satisfied, the transaction shall reject and not be counted.

b. Losses. All current loss transactions are also reviewed with respect to a Service member's status on last month's master file. A loss to the Reserve component is valid, only if the Service member's record previously existed. If not, the loss transaction shall reject and not be counted.

c. Gain and/or Loss. Where simultaneous gain and loss, and reenlistment and/or extension, transactions occur against the same record (SSN) during one reporting period, count each transaction.

d. Reenlistment and/or Extension. A reenlistment and/or extension transaction is acceptable to the RCCPDS if the record identifies the Service member as a Reservist and that record is in the Reserve component's master file of the previous month. When those conditions cannot be validated, the transaction shall reject and not be counted.

3. Master File and/or Transactions. Standard validity checks are made on all master file and transaction inputs to ensure that they conform to the code structure in Section 3 of this Instruction. For example, if a “GA” transaction were submitted, it would reject because its second character is “ALPHA” and the procedure requires a “NUMERIC” second character. Validity errors in a record shall cause rejection of the entire record, only under the following circumstances:

a. When the Reserve component code equals “9”.

b. When the SSN does not fit within the numeric boundaries established by the Social Security Administration.

a. During the month's reporting cycle, each gain, loss, reenlistment, extension, or transfer transaction shall have a corresponding impact on the master file for the same period. The following relationships exist:

(1) When a gain transaction is submitted, report a master file record on that Service member during the same cycle.

(2) When a loss transaction is reported, eliminate the master file record showing the Service member as a Reservist.

(3) When a reenlistment and/or extension transaction is submitted, the corresponding master file for the same period must reflect the individual as being in a Reserve component.

(4) When a transfer transaction occurs, the corresponding master file for the same period must reflect the individual as being in the new Reserve component category.

b. All transactions that cannot satisfy the above relationship to the current master file shall reject and will not be counted.