Images de page
PDF
ePub

APPENDIX B TO PART 114—TRANSACTION AND EDITING PROCEDURES FOR SUBMISSION TAPES

A. Transaction Concept

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.

B. Edit Concept

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:

1. Master Files

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 Compoment Files. That procedure checks for duplication among Reserve Component.S. 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.

2. TranSactions

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. Gaim 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. Reemlistment and/or Eartension. 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.

4. Master File and/or Transaction File Relationship

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.

[graphic]

APPENDIX C TO PART 114—CODING INSTRUCTIONS-TRANSACTION FILE DD—RA (M) 1148

[ocr errors]
[ocr errors]
[ocr errors]
[ocr errors]

For immediate (in 24 hours) reenlistment and/or extensions in the Reserve components.

Definition—A reenlistment occurs when an individual imme-
diately reenlists (in 24 hours) on expiration of his or her Serv-
ice contract, or agreement, or reenlists before the expiration
of his or her Service contract, or agreement, in the same Re-
serve component. An extension occurs when an individual
voluntarily extends his or her service contract, or agreement
in writing beyond its normal expiration date. A break in Serv-
ice of over 24 hours but less than 91 days, is to be counted
as a PS gain (reenlistment) and should be reported with a
gain code of “GO.”

M1=Immediate reenlistment.

M2=Extension of current enlistment contract or agreement.

For intracomponent transfers between Reserve categories .........

TA=Selected Reserve (other than AGR) to AGR
TB=Selected Reserve (other than AGR) to IRR
TC=Selected Reserve (other than AGR) to ING
TD=Selected Reserve (other than AGR) to Standby
TE=Selected Reserve (other than AGR) to Retired (V2)
TF=AGR to Selected (other than AGR)
TG=AGR to IRR

TJ-AGR to Standby

TK=AGR to Retired (V2)

TL=IRR to AGR
TM=IRR to Selected (other than AGR)
TN=IRR to Standby

TP=IRR to Retired (V2)

TQ=|NG to AGR
TR=ING to Selected (other than AGR)
TU=Standby to AGR
TV=Standby to Selected (other than AGR)
TW=Standby to IRR

TY=Standby to Retired (V2)

TZ=Retired to AGR
T1=Retired to Selected (other than AGR)
T2=Retired to IRR

T3=Retired to Standby
P0=Retired transferred to retired status other than V2
P1=Selected Reserve transferred to retired status other than V2
P2=AGR transferred to retired status other than V2
P3=|RR transferred to retired status other than V2
P4=Standby transferred to retired status other than V2
For intercomponent transfer within the same Service
N1=Guard Selected to Selected Reserve in same service
N2=Guard Selected to Reserve IRR

c. Reenlistments and/or Extensions.

d. Transfers .............................

TH=AGR to ING

[ocr errors][ocr errors][ocr errors][merged small][merged small][merged small][merged small][merged small]
[graphic][merged small][subsumed]
« PrécédentContinuer »