ADMINISTRATIVE MESSAGE ROUTINE R 281524Z MAR 01 MIN ZYB PSN 245849J32 FM CNO WASHINGTON DC//N1// TO NAVADMIN UNCLAS //N01080// NAVADMIN 068/01 MSGID/GENADMIN/N1// PART TWO OF TWO. PART ONE DTG IS 281523ZMAR01 SUBJ/ITEMPO PROGRAM FREQUENTLY ASKED QUESTIONS// REF/A/DOC/CNO WASHINGTON DC/031208ZOCT2000// AMPN/REF A IS NAVADMIN 255/00// RMKS/1. IN RESPONSE TO QUESTIONS AND CONCERNS FROM VARIOUS ACTIVITIES, THIS NAVADMIN IS PROMULGATED TO HIGHLIGHT PERTINENT INFORMATION REGARDING FREQUENTLY ASKED QUESTIONS AND IDENTIFIED COMMON PROBLEMS IN THE ITEMPO REPORTING PROCESS. DUE TO THE DETAILED NATURE OF SOME ISSUES PRESENTED HEREIN, THIS NAVADMIN IS INTENDED TO BE USED IN CONJUNCTION WITH THE BELOW LISTED SOURCES OF ITEMPO INFORMATION. IN INSTANCES WHERE GUIDANCE CONTAINED IN THE BELOW DOCUMENTS CONFLICTS WITH THIS NAVADMIN, THIS NAVADMIN SHALL TAKE PRECEDENCE. 2. RESOURCES AND WEBSITES: DOCUMENT WEB ADDRESS NAVADMIN 255/00 (REF A) WWW.BUPERS.NAVY.MIL OR WWW.PERSNET.NAVY.MIL (CLICK ON "ITEMPO" OR "MESSAGES" BUTTON) DMRSMAN WWW.EPMAC.NOLA.NAVY.MIL (CLICK ON "DOWNLOADS" AND SCROLL DOWN TO THE DMRSMAN) DRAFT ITEMPO USER'S MANUAL (REF C) WWW.BUPERS.NAVY.MIL OR WWW.PERSNET.NAVY.MIL (CLICK ON "ITEMPO) FAQ'S WWW.BUPERS.NAVY.MIL OR WWW.PERSNET.NAVY.MIL (CLICK ON "ITEMPO") NAVY ITEMPO BRIEFS (POWERPOINT PRESENTATIONS) WWW.BUPERS.NAVY.MIL OR WWW.PERSNET.NAVY.MIL (CLICK ON "ITEMPO") 3. POINTS OF CONTACT: POLICY MANAGEMENT: POLICY PROGRAM MANAGER N130C (703) 614-5565 (DSN 224-5565) E-MAIL: N130C@BUPERS.NAVY.MIL POLICY PROGRAM SUPPORT TEAM N13T4 (703) 695-3316 (DSN 225-3316) E-MAIL: N13T4@BUPERS.NAVY.MIL N130C2 (703) 695-3057 (DSN (DSN 225-3057) E-MAIL: N130C2@BUPERS.NAVY.MIL REQUIREMENTS MANAGEMENT: ACTIVE DUTY FUNCTIONAL MANAGER P33 (901) 874-3465 (DSN 882-3465) E-MAIL: P33@PERSNET.NAVY.MIL RESERVE FUNCTIONAL MANAGER CNRF-12 (504)678-6132 (DSN 678-6132) E-MAIL: CNRF12@CNRF.NOLA.NAVY.MIL ITEMPO HELP DESK (MON-FRI 0530-2400 CST) (901)874-4717 (DSN 882-4717) E-MAIL: HELPDESK@PERSNET.NAVY.MIL 4. ITEMPO FREQUENTLY ASKED QUESTIONS (FAQ'S) AND LESSONS LEARNED: ITEMPO FAQ'S ARE AVAILABLE ONLINE AT THE BUPERS/NPC WEB SITE. THEY WERE DEVELOPED BASED ON FEEDBACK FROM THE FLEET AND ARE INTENDED TO BE A TOOL COMMANDS CAN USE TO IMPROVE THEIR ITEMPO REPORTING AND AVOID ERRORS. IN ADDITION TO REVIEWING THE FAQ'S, COMMANDS ARE ENCOURAGED TO CLOSELY REVIEW THEIR OUTGOING DMRS MESSAGES FOR ACCURACY PRIOR TO RELEASE. THIS MAY ALSO HELP REDUCE ITEMPO REPORTING ERRORS/PROBLEMS FOR COMMANDS. FEEDBACK FROM A NUMBER OF DEPLOYED COMMANDS INDICATES ACCESS TO THE FAQ'S ON THE WEB IS OFTEN DIFFICULT. THESE UNITS HAVE RECOMMENDED THAT ITEMPO FAQ'S ALSO BE PUBLISHED BY MESSAGE TO ENSURE RECEPTION BY SUCH COMMANDS. ACCORDINGLY, THE ENSUING SECTION OF THIS PARAGRAPH INCLUDES THE NEWEST ITEMPO FAQ'S: QUESTION 1: I HAVE ITEMPO EVENTS OCCURRING ALMOST EVERYDAY, AND I SUBMIT ITEMPO DMRS INPUT MESSAGE(S) UPON OCCURRENCE PER SECTION 4.1 OF THE ITEMPO USER'S MANUAL (ITEMPOMAN). HOWEVER, IN REVIEWING MY FEEDBACK AND MONTHLY STATUS REPORTS, I'VE NOTICED THAT I OFTEN GET NUMEROUS ERRORS THAT DON'T SEEM TO MAKE SENSE AND/OR SOME OF MY MESSAGES AREN'T RECEIVED. WHAT IS CAUSING THESE PROBLEMS, WHAT CORRECTIVE ACTIONS ARE BEING TAKEN, AND HOW DO I GET AROUND THESE PROBLEMS TODAY? ANSWER 1: A. THE ANSWER TO "WHAT IS CAUSING THESE PROBLEMS" IS TWOFOLD: 1) IN SOME CASES, AN OUTGOING MESSAGE IS NOT RECEIVED BY THE ITEMPO SYSTEM. WHEN THE NEXT MESSAGE IS RECEIVED AND PROCESSED BY THE ITEMPO SYSTEM, IF ANY OF THE TRANSACTIONS ARE FOLLOW-UPS TO TRANSACTIONS NOT POSTED (BECAUSE THEY WERE INCLUDED IN THE MISSING MESSAGE), THOSE FOLLOW-UP TRANSACTIONS MAY ERROR OUT OR MAY APPLY INCORRECT DATES TO EXISTING EVENTS. IF THE FIRST MESSAGE IS THEN RECEIVED, IT MAY CONTAIN ERRORS DUE TO BEING PROCESSED OUT OF SEQUENCE. PER STANDARD NAVY PROCEDURES, IF A MESSAGE IS NOT RECEIVED, THE ORIGINATING COMMAND SHOULD SUBMIT A TRACER TO DETERMINE THE REASON FOR THE LACK OF RECEIPT. WHILE MANY COMMANDS APPEAR TO TAKE THE STANCE OF "IT'S EASIER JUST TO RETRANSMIT THE DATA" AND THAT MAY BE TRUE, IT'S ALSO IMPORTANT TO ENSURE YOUR ITEMPO DMRS MESSAGES ARE BEING PROPERLY ROUTED. AS AN EXAMPLE, AN OVERSEAS COMMAND WAS NOT RECEIVING ITEMPO MESSAGE ACKNOWLEDGEMENTS VIA THEIR FEEDBACK OR MONTHLY STATUS REPORTS. AFTER INITIATING TRACER ACTIONS, IT WAS DETERMINED THAT THE PROBLEM WAS WITH ROUTING INSTRUCTIONS AT THE THEATRE'S COMMUNICATIONS CENTER. DO NOT DISMISS TRACER ACTIONS IN RESOLVING COMMUNICATIONS PROBLEMS. 2) IN OTHER CASES, AN OUTGOING MESSAGE IS RECEIVED BY THE ITEMPO SYSTEM AND THE SYSTEM SUCCESSFULLY PROCESSES THE TRANSACTIONS. THEN, DAYS OR EVEN WEEKS LATER, THE ITEMPO SYSTEM RECEIVES A DUPLICATE OF THE FIRST MESSAGE CONTAINING THE SAME TRANSACTIONS. THIS DUPLICATION MAY BE THE CAUSE OF THE UNIT ITSELF RESENDING ITS MESSAGE, THINKING THE ORIGINAL HAD NOT BEEN RECEIVED, OR MAY BE THE RESULT OF A RETRANSMISSION BY A COMMUNICATIONS CENTER IN THE ROUTING PATH OF THE MESSAGE (FOR EXAMPLE, THE COMMUNICATIONS CENTER TRUNCATES THE MESSAGE AND THEN RETRANSMITS A CORRECTED COPY). IN EITHER INSTANCE, MOST OF THE RETRANSMITTED TRANSACTIONS WILL ERROR OUT, DEPENDING ON THE LENGTH OF TIME BETWEEN THE FIRST MESSAGE AND THE DUPLICATE. B. WHAT CORRECTIVE ACTIONS ARE BEING TAKEN AND HOW DOES A UNIT WORK AROUND THESE PROBLEMS TODAY? 1) FUNCTIONAL MANAGERS AND SYSTEM DESIGNERS ARE RECONSIDERING A CAPABILITY TO ASSIGN SEQUENCE NUMBERS TO ITEMPO DMRS MESSAGES. THIS WILL HELP WITH BOTH CASES ABOVE. AMONG THE SOLUTIONS BEING CONSIDERED: IN THE CASE OF A MISSING MESSAGE, AN ITEMPO MESSAGE RECEIVED WITH AN OUT-OF-SEQUENCE NUMBER WOULD BE HELD AND A MESSAGE SENT BACK TO THE ORIGINATOR, REQUESTING RETRANSMISSION OF THE MISSING SEQUENCE NUMBER. IN THE CASE OF A DUPLICATE MESSAGE, IF THE MESSAGE CONTAINS A DUPLICATE OF THE SEQUENCE NUMBER, THE MESSAGE WOULD BE ERRORED OUT BEFORE THE TRANSACTIONS ARE PROCESSED. WE WILL KEEP YOU UPDATED ON THE PROGRESS OF ASSIGNING SEQUENCE NUMBERS TO THE MESSAGES. 2) AS NOTED IN PARA 5C ABOVE, A WEB-BASED DATA INPUT METHODOLOGY, ORIGINALLY SCHEDULED FOR IMPLEMENTATION IN JULY 2001 (ITEMPO PHASE 2) HAS BEEN ACCELERATED AND WILL BEGIN TESTING SOON. ONCE AVAILABLE THROUGHOUT THE FLEET, THIS METHODOLOGY WILL TAKE THE PLACE OF DMRS MESSAGES FOR THOSE UNITS WITH WEB CONNECTIVITY. DMRS WILL REMAIN A VIABLE ITEMPO DATA INPUT VEHICLE FOR THE FORESEEABLE FUTURE DUE TO NOT ALL UNITS HAVING WEB CAPABILITY. HOWEVER, ONCE THE WEB-BASED INPUT VEHICLE IS AVAILABLE, UNITS SHOULD ALWAYS USE THE WEB VEHICLE WHEN AVAILABLE. ONLINE EDITS, DROP-DOWN MENUS, UIC ROSTERS, ETC., AVAILABLE WITH THE WEB-BASED DATA INPUT VEHICLE WILL ELIMINATE MANY OF THE CURRENT ERRORS THAT OCCUR, AND THE WEB-BASED INPUT WILL ELIMINATE THE ERRORS CAUSED BY MISSING MESSAGES OR DUPLICATE MESSAGES. 3) THERE IS A MINOR SOFTWARE ERROR REGARDING THE FEEDBACK REPORTING OF THE PMAR (ABSENT-ON-RETURN) TRANSACTION. RECALL THAT THIS TRANSACTION IS TO BE USED TO REPORT WHEN A MEMBER DOES NOT RETURN WITH A UNIT ENDING A DEPLOYMENT EVENT. TWO EXAMPLES: A. CDR SMITH, ASSIGNED TO USS UNDERWAY, IS SENT TAD FROM THE SHIP'S HOMEPORT OF NORFOLK TO PARTICIPATE IN A SELECTION BOARD IN MILLINGTON, TN. THE SHIP PROPERLY SUBMITS A PMDB EVENT ICO CDR SMITH. WHEN THE SHIP GETS UNDERWAY, THE SHIP PROPERLY SUBMITS ITS PUDB TAC TO BEGIN ITEMPO DEPLOYMENT. THE PUDB TAC AUTOMATICALLY GENERATES PMDB TACS FOR EVERY MEMBER OF USS UNDERWAY'S CREW. THE SHIP THEN PROPERLY SUBMITS ITS PMAS TAC ICO CDR SMITH, SINCE SHE IS IN MILLINGTON, ALREADY ON AN ITEMPO DEPLOYMENT EVENT AND SHOULD NOT GET CREDIT FOR THE SHIP'S DEPLOYMENT. THE PMAS TAC NEGATES THE SYSTEM-GENERATED PMDB TAC. WHEN THE SHIP RETURNS TO PORT, CDR SMITH IS STILL TAD TO MILLINGTON. THE SHIP PROPERLY SUBMITS ITS PUDE TAC TO END ITEMPO DEPLOYMENT. THE PUDE TAC AUTOMATICALLY GENERATED PMDE TACS FOR EVERY MEMBER OF USS UNDERWAY'S CREW. THE SHIP THEN PROPERLY SUBMITS ITS PMAR TAC ICO CDR SMITH, WHO IS STILL ON AN ACTIVE ITEMPO DEPLOYMENT EVENT IN MILLINGTON AND DIDN'T RETURN TO HOMEPORT WITH THE UNIT. THE PMAR TAC NEGATES THE SYSTEM-GENERATED PMDE TAC. WITHOUT THE PMAR TAC, THE SYSTEM WOULD PROCESS THE PMDE TAC, AND SINCE CDR SMITH IS ON AN ACTIVE ITEMPO EVENT, THE SYSTEM WOULD ERRONEOUSLY AND PREMATURELY END CDR SMITH'S ACTIVE ITEMPO DEPLOYMENT EVENT. THE PMAR WAS DESIGNED TO PREVENT THIS ERROR FROM SHOWING ON YOUR DAILY FEEDBACK REPORT. IN THIS CASE, THERE IS NO SOFTWARE ERROR, AS THE PMDE TAC IS PROCESSED AND ATTEMPTS TO PREMATURELY END CDR SMITH'S ACTIVE ITEMPO EVENT, BUT THEN THE PMAR IS PROCESSED, NEGATES THE SYSTEM-GENERATED PMDE TAC, AND THE EVENT IS PROPERLY REINSTATED. B. YN3 JONES, ASSIGNED TO USS UNDERWAY, IS LEFT BEHIND IN THE SHIP'S HOMEPORT WHEN THE SHIP GETS UNDERWAY. THE SHIP PROPERLY SUBMITS ITS PUDB TAC TO BEGIN ITEMPO DEPLOYMENT. THE PUDB TAC AUTOMATICALLY GENERATES PMDB TACS FOR EVERY MEMBER OF USS UNDERWAY'S CREW. THE SHIP THEN PROPERLY SUBMITS ITS PMAS TAC ICO YN3 JONES, SINCE YN3 JONES WAS LEFT BEHIND AND SHOULD NOT GET CREDIT FOR DEPLOYMENT. THE PMAS TAC NEGATES THE SYSTEM-GENERATED PMDB TAC. WHEN THE SHIP RETURNS TO PORT, YN3 JONES RETURNS TO THE SHIP. THE SHIP PROPERLY SUBMITS ITS PUDE TAC TO END ITEMPO DEPLOYMENT. THE PUDE TAC AUTOMATICALLY GENERATED PMDE TACS FOR EVERY MEMBER OF USS UNDERWAY'S CREW. THE SHIP THEN PROPERLY SUBMITS ITS PMAR TAC ICO YN3 JONES, WHO DID NOT RETURN TO HOMEPORT WITH THE UNIT. THE PMAR TAC NEGATES THE SYSTEM-GENERATED PMDE TAC. WITHOUT THE PMAR TAC, THE SYSTEM WOULD PROCESS THE PMDE TAC, AND SINCE NO ACTIVE ITEMPO EVENT IS IN PLACE FOR YN3 JONES, THE SYSTEM WOULD ERROR OUT THE PMDE TAC. THE PMAR WAS DESIGNED TO PREVENT THIS ERROR FROM SHOWING ON YOUR DAILY FEEDBACK REPORT. THE SOFTWARE ERROR IN THIS CASE: THE SYSTEM-GENERATED PMDE TAC IS BEING PROCESSED BEFORE THE PMAR, AND SINCE YN3 JONES HAS NO ACTIVE ITEMPO EVENT IN THE ITEMPO DATABASE, THE PMDE ERRORS OUT OF THE SYSTEM (NO ACTIVE EVENT ON FILE). THEN THE PMAR TAC HITS THE SYSTEM, THE PMDE HAS ALREADY ERRORED OUT, LEAVING THE PMAR TAC TO ERROR AS WELL. THE ERRORS ASSOCIATED WITH THE PMDE AND PMAR REFLECT ON YOUR DAILY FEEDBACK REPORT, WHEN IN FACT, NO ERRORS SHOULD BE ON THE FEEDBACK REPORT. THIS SOFTWARE ERROR IS BEING REVIEWED AND WILL BE CORRECTED AS SOON AS POSSIBLE. DESPITE THESE ERRORS SHOWING ON YOUR DAILY FEEDBACK REPORTS, THE ACTUAL STATUS OF INDIVIDUALS SHOULD BE CORRECTLY REFLECTED IN YOUR MONTHLY STATUS REPORTS. AS ALWAYS, WE STRONGLY RECOMMEND VERIFICATION OF EVERY MONTHLY STATUS REPORT TO ENSURE WHAT YOU REPORT IS CORRECTLY REFLECTED IN THE ITEMPO SYSTEM. 4) WE ARE IN THE PROCESS OF REVISING OUR FEEDBACK AND ERROR REPORTS TO PROVIDE A MORE CLEAR AND CONCISE ERROR MESSAGE. THIS WILL ASSIST UNITS IN VERIFYING THEIR REPORTS AND THE ITEMPO STATUS OF EVERY SAILOR ASSIGNED TO THE UNIT. 5) WE ARE TEMPORARILY INCREASING THE FREQUENCY OF THE MONTHLY STATUS REPORT TO WEEKLY. WE STRONGLY RECOMMEND THAT UNITS USE THESE TOOLS (THE DAILY FEEDBACK/ERROR REPORTS AND MONTHLY STATUS REPORTS) TO VERIFY THE DATA CONTAINED ON THE REPORT AGAINST THEIR LOCAL RECORDS (THE DATA YOU SUBMITTED) TO VERIFY THE ITEMPO STATUS OF EACH INDIVIDUAL. QUESTION 2: WHAT TYPE OF DISCIPLINARY EVENTS REQUIRE ITEMPO REPORTING? ANSWER 2: WHEN A SAILOR IS SENT TO THE BRIG OR CONFINED IN ANY WAY AND IS UNABLE TO SPEND THEIR OFF-DUTY TIME IN THEIR OFF-DUTY RESIDENCE OR IN THE HOMEPORT OF THEIR VESSEL, THE CONFINEMENT IS CONSIDERED AN ITEMPO NON-DEPLOYED EVENT (NOTE: REPORTING ITEMPO NON-DEPLOYMENT EVENTS IS SUSPENDED PER PARA 4 ABOVE). A SAILOR IN A CURRENT UA STATUS SHOULD NOT BE REPORTED, AS THE REASON FOR ABSENCE HAS NOT BEEN DETERMINED. ONCE THE REASON FOR ABSENCE HAS BEEN ADJUDICATED, NECESSARY CORRECTIONS TO THE SAILOR'S ITEMPO STATUS SHOULD BE MADE. FOR EXAMPLE, IF A UNIT IS DEPLOYED AND A SAILOR GOES UA; DURING THE TIME OF THE UA, THE UNIT DOES NOT MAKE ANY ADJUSTMENT TO THE SAILOR'S STATUS. IF THE SAILOR'S UA TIME IS EXCUSED AND THE SAILOR WAS IN THE AREA OF THE DEPLOYED THEATRE, NO CHANGE TO THE SAILOR'S STATUS IS REQUIRED. IF THE SAILOR'S UA TIME IS CHARGED AS LEAVE AND THE SAILOR HAD LEFT THE AREA OF THE DEPLOYED THEATRE OR RETURNED TO HOMEPORT, THEN THE SAILOR'S ITEMPO STATUS MUST BE STOPPED AT THE BEGINNING OF THE LEAVE AND RESTARTED WHEN THE SAILOR RETURNED TO THE DEPLOYED AREA. IF THE SAILOR'S UA TIME WAS ADJUDICATED AS UNAUTHORIZED ABSENCE AND IS COUNTED AS LOST TIME, THE SAILOR'S ITEMPO STATUS MUST BE STOPPED AT THE BEGINNING OF THE UNAUTHORIZED ABSENCE AND RESTARTED WHEN THE SAILOR RETURNED FROM UNAUTHORIZED ABSENCE. QUESTION 3: A SCENARIO: LCDR SMITH WAS SENT TAD FROM SHORE DUTY IN PEARL HARBOR (UIC: 91919), HER PERMANENT DUTY STATION, TO BUPERS MILLINGTON TN FROM 18 NOV 00 TO 24 NOV 00 TO ATTEND A CONFERENCE. THE CONFERENCE WAS EXTENDED AND LCDR SMITH ACTUALLY RETURNED TO HAWAII ON 28 NOV. HER UNIT IN PEARL HARBOR SUBMITTED ITEMPO INFORMATION FOR LCDR SMITH FOR THE MILLINGTON TAD PERIOD AS FOLLOWS: ON 19 NOV 00: PMDB,585021535,SMITH,001118,001124,91919,D ON 29 NOV 00: PMDE,585021535,SMITH,001124,91919/ (NOTE THE ERRONEOUS ENDING DATE). LCDR SMITH WAS ALSO SENT TAD TO OPNAV WASHINGTON FROM 3 DEC 00 TO 18 DEC 00, AND HER UNIT SUBMITTED HER ITEMPO INFORMATION AS FOLLOWS: ON 4 DEC 00: PMDB,585021535,SMITH,001203,001218,91919,D /ON 19 DEC 00: PMDE,585021535,SMITH,001218,91919/ UPON HER RETURN FROM WASHINGTON ON 19 DEC, LCDR SMITH NOTED THE ERROR OF HER ITEMPO DEPLOYMENT TIME TO MILLINGTON. HOW DOES HER UNIT CORRECT THE MILLINGTON TAD PERIOD, AS A SUBSEQUENT TAD PERIOD HAS OCCURRED? ANSWER 3: PER SECTION 4.3 OF THE REF C, A MEMBER-LEVEL CANCEL BEGIN (PMXB) EVENT SHOULD BE SUBMITTED TO CANCEL THE ENTIRE MILLINGTON TRANSACTION. THEN, ON THE FOLLOWING ITEMPO MESSAGE, A PMDO TRANSACTION SHOULD BE SUBMITTED TO COVER THE ENTIRE PERIOD OF THE MILLINGTON TAD. HER UNIT SHOULD SUBMIT ITEMPO TRANSACTIONS AS FOLLOWS: ON 20 DEC 00: PMXB,585021535,SMITH,001118,91919/ ON 21 DEC 00: PMDO,585021535,SMITH,001118,001128,91919,D/ NOTE: A REMINDER: THIS IS THE BEST WAY TO CORRECT PRIOR (OLD) EVENTS. USE THE PMXB TO DELETE THE ERRONEOUS OLD EVENT AND SUBMIT A PMDO EVENT TO REPORT THE EVENT CORRECTLY. IN THIS CASE, THESE TWO EVENTS CANNOT BE SUBMITTED ON THE SAME MESSAGE, BECAUSE PMDO TACS ARE PROCESSED IN THE ITEMPO SYSTEM BEFORE PMXB TACS. QUESTION 4: WE UNDERSTAND THE IDEA OF SUBMITTING A PMAS TAC IN CONJUNCTION WITH A PUDB TAC TO NEGATE THE SYSTEM-GENERATED PMDB EVENT FOR SAILORS WHO DID NOT DEPLOY WITH A UNIT. WE ALSO UNDERSTAND THE IDEA OF SUBMITTING A PMAR TAC IN CONJUNCTION WITH A PUDE TAC TO NEGATE THE SYSTEM-GENERATED PMDE EVENT FOR SAILORS WHO DID NOT RETURN FROM DEPLOYMENT WITH A UNIT. HOWEVER, IN THOSE INSTANCES WHERE WE USE A PUDO TAC TO REPORT A UNIT DEPLOYED/NON-DEPLOYED EVENT THAT WAS ERRONEOUSLY OMITTED, HOW DO WE CANCEL THAT THE MEMBER-LEVEL TRANSACTIONS TO REPORT SAILORS WHO WERE ABSENT-ON-SAILING/RETURN? ANSWER 4: THE PUDO EVENT YOU SUBMIT WILL GENERATE PMDO EVENTS FOR EVERY MEMBER OF THE CREW PERMANENTLY ASSIGNED TO THE UNIT DURING THAT INCLUSIVE PERIOD. YOU WILL USE THE PMXB (MEMBER-LEVEL CANCEL ITEMPO EVENT) TAC TO CANCEL THE PMDO EVENT FOR THOSE SAILORS WHO WERE ABSENT-ON-SAILING/RETURN. WITHIN THE PMXB TAC, ENSURE YOU CORRECTLY REFLECT THE START DATE OF THE ORIGINAL PUDO EVENT SO THAT THE APPROPRIATE ITEMPO RECORD IS IDENTIFIED FOR CANCELLATION. NOTE: AS STATED ABOVE, PMDO TACS ARE PROCESSED IN THE ITEMPO SYSTEM BEFORE PMXB TACS. THEREFORE, IN THIS CASE, YOU MAY SUBMIT BOTH OF THESE TACS ON THE SAME MESSAGE, BECAUSE YOU WANT THE PMDO TAC TO BE PROCESSED FIRST (THE PMDO'S ARE SYSTEM GENERATED FROM THE PUDE TAC (UNIT'S EVENT) THAT YOU SUBMITTED), AND THEN THE PMXB PROCESSED SECOND, TO NEGATE THE SYSTEM-GENERATED PMDO TAC. IN THE CASE OF AN INDIVIDUAL WHO MAY HAVE BEEN WITH THE UNIT TAD FROM HIS/HER PDS, YOU SHOULD SUBMIT A PMDO TAC TO RETROACTIVELY CREDIT THAT SAILOR WITH THE ITEMPO EVENT. QUESTION 5: JUST HOW EXACTLY DOES THE PUDO EVENT WORK? IF SAILORS HAVE COME AND GONE FROM THE UIC SINCE THE EVENT OCCURRED, HOW DOES THE ITEMPO SYSTEM APPLY THE SYSTEM-GENERATED PMDO EVENTS, AND DO I HAVE TO MANUALLY SUBMIT PMDO EVENTS FOR ANY OF THE SAILORS IN THE UNIT? ANSWER 5: IN ORDER TO ANSWER, LET'S CREATE A COMPLETE SCENARIO AND DISCUSS WHAT THE SYSTEM WILL DO. ASSUME WE HAVE THE FOLLOWING DUTY INFORMATION FOR SAILORS THAT WERE OR ARE ASSIGNED TO USS UNDERWAY, UIC 12345: RECEIVE DEPARTURE CURRENT SSN AT UIC 12345 FROM UIC 12345 STATUS AS OF 2002-12-15 SSN1 2002-03-01 2002-12-01 ACTIVE SSN2 2001-02-19 2001-04-11 ACTIVE SSN3 2001-04-13 2001-06-02 ACTIVE SSN4 2001-01-04 2001-02-12 ACTIVE SSN5 2001-04-23 2001-05-30 ACTIVE SSN6 2001-07-20 2001-07-25 ACTIVE SSN7 2001-12-20 2002-07-01 ACTIVE SSN8 2001-01-01 2002-09-01 NOT ON ACTIVE DUTY SSN9 2001-07-08 NONE (STILL ABOARD) ACTIVE IF A PUDO IS SUBMITTED FOR UIC 12345 ON 2002-12-15 WITH A START DATE OF 2001-02-10 AND A STOP DATE OF 2002-01-01, THEN THE FOLLOWING PMDO'S WOULD BE CREATED BY THE ITEMPO SYSTEM: SSN PMDO START PMDO STOP SSN2 2001-02-19 2001-04-11 SSN3 2001-04-13 2001-06-02 SSN4 2001-02-10 2001-02-12 SSN5 2001-04-23 2001-05-30 SSN6 2001-07-20 2001-07-25 SSN7 2001-12-20 2002-01-01 SSN9 2001-07-08 2002-01-01 NOTES: SSN1: PMDO DOES NOT GET GENERATED SINCE HE REPORTED ABOARD UIC 12345 AFTER THE PERIOD SPECIFIC IN THE PUDO. SSN8: PMDO DOES NOT GET GENERATED SINCE HIS CURRENT STATUS IS NOT ACTIVE; THE MEMBER WAS DISCHARGED FROM THE NAVY ON 2002-09-01. AS YOU CAN SEE, THE ITEMPO SYSTEM WILL SEARCH OUT THOSE INDIVIDUALS WHO WERE ASSIGNED TO THE UNIT DURING THE PERIOD NOTED, EVEN IF THEY HAVE ALREADY DETACHED FROM THE UNIT, AND CREATE THE INDIVIDUAL MEMBER-LEVEL EVENT FOR THE PERIOD SPECIFIED. YOU DO NOT HAVE TO SUBMIT INDIVIDUAL PMDO TRANSACTIONS FOR SAILORS WHO REPORTED ABOARD AFTER THE PUDO START DATE OR WHO DETACHED BEFORE THE PUDO END DATE (OR BOTH); THE SYSTEM AUTOMATICALLY CREATES THE EVENTS TAKING REPORTING AND DETACHING DATES INTO ACCOUNT. QUESTION 6: I AM THE ADMIN OFFICER OF A LARGE SHORE COMMAND. WE ARE RESPONSIBLE FOR SUBMITTING ITEMPO TRANSACTIONS FOR MULTIPLE UICS. WE HAVE SUBMITTED PAOT TRANSACTIONS PER SECTION 4.4 OF REF C TO ENABLE CIVILIANS WORKING IN THE ADMIN OFFICE TO ACCESS OUR ONLINE UIC MAILBOX. HOWEVER, WE OFTEN FIND WE EITHER CANNOT GET THE ITEMPO SYSTEM TO GIVE OUR CIVILIANS ACCESS, OR WE DO GET THEM ACCESS, BUT AFTER A PERIOD OF TIME, THEIR ACCESS DISAPPEARS FOR ONE OR ALL OF OUR UICS. WHY? ANSWER 6: WE HAVE IDENTIFIED A COUPLE OF SOFTWARE PROBLEMS WITH THE PAOT TRANSACTIONS. A. PAOT TRANSACTIONS ARE NOT BEING INCLUDED AS VERIFIED ON THE DAILY FEEDBACK/ERROR REPORTS. WE ARE WORKING TO CORRECT THIS ERROR. B. BECAUSE CIVILIANS AND MILITARY MEMBERS FROM OTHER SERVICES (NON-NAVY) ARE NOT PART OF THE MASTER NAVY MILITARY OR ITEMPO DATABASES, THEIR ACCESS TO THE ITEMPO SYSTEM MUST BE KEPT IN A SEPARATE AUTHENTICATION DATABASE. WHEN A PAOT TRANSACTION IS FIRST SUBMITTED FOR ANY CIVILIAN OR OTHER SERVICE MILITARY, THE UIC OF THE COMMAND SUBMITTING THE REQUEST (IN THE SUBJECT LINE OF THE ITEMPO MESSAGE) IS PUT INTO THE ITEMPO AUTHORIZATION DATABASE AS THAT CIVILIAN'S/OTHER SERVICE MILITARY MEMBER'S ONBOARD UIC, AND THE INDIVIDUAL IS GIVEN ACCESS TO THE UIC REQUESTED VIA THE PAOT TAC, AS THIS ITEMPO SAMPLE SHOWS: PAOT,123456789,JONES JOHN P,650815,52738,A/ ANY SUBSEQUENT REQUESTS FOR THE SAME INDIVIDUAL TO HAVE ACCESS TO ADDITIONAL UIC'S MUST BE SUBMITTED BY THE SAME UNIT/UIC, WHICH IS THE CIVILIAN'S ON BOARD UIC IN OUR AUTHENTICATION DATABASE. WHEN SUBMITTED BY THE SAME UIC, ANY ADDITIONAL UIC'S BEING REQUESTED FOR ACCESS WILL BE ADDED TO THE CIVILIAN'S RECORD. HOWEVER, IF A SUBSEQUENT REQUEST IS SUBMITTED BY A COMMAND WITH A DIFFERENT UIC REFLECTED IN THE SUBJECT LINE, THEN THE CIVILIAN'S/OR OTHER SERVICE MILITARY MEMBER'S ONBOARD UIC IS CHANGED IN THE AUTHENTICATION DATABASE, AND THAT REMOVES ALL OF HIS/HER PREVIOUS ACCESS. THIS PROCESS MIMICS THE TRANSFER OF A NAVY MILITARY MEMBER FROM ONE COMMAND TO ANOTHER; SUCH A TRANSFER ELIMINATES ANY PREVIOUS ACCESS THE MEMBER HAD AT HIS/HER PREVIOUS DUTY STATION. C. INITIALLY, WE ARE LIMITING ALL CIVILIANS AND MILITARY PERSONNEL FROM OTHER SERVICES (I.E., NON-NAVY) TO AN ACCESS PERIOD OF 12 MONTHS. AFTER 12 MONTHS HAVE EXPIRED, THE ACCESS WILL BE RESCINDED, REQUIRING RESUBMISSION (RESUBMISSIONS MAY BE FORWARDED IN ADVANCE OF THE EXPIRATION OF THE INDIVIDUAL'S ACCESS). THIS IS TAKEN AS A SYSTEM SECURITY MEASURE TO ENSURE ONLY THOSE CIVILIANS AND OTHER SERVICE MILITARY WITH A NEED TO KNOW WILL MAINTAIN ACCESS TO THE SYSTEM. IF/WHEN THE MASTER NAVY CIVILIAN PERSONNEL DATABASE IS INCORPORATED INTO THE ITEMPO AUTHENTICATION SYSTEM, THIS 12-MONTH RESTRICTION WILL NO LONGER BE NECESSARY WRT TO NAVY CIVILIANS. THE RESTRICTION WILL CONTINUE TO APPLY TO MILITARY MEMBERS OF OTHER SERVICES AND FEDERAL GOVERNMENT CIVILIANS WHO ARE NOT NAVY EMPLOYEES. QUESTION 7: A SAILOR ORDERED TO MY COMMAND (A PROSPECTIVE GAIN) IS NOW SHOWING ON MY MONTHLY STATUS REPORT, WITH AN OPEN ITEMPO DEPLOYMENT EVENT THAT BEGAN ON 15 NOV 00. WE FOUND THE SAILOR'S ORDERS, AND THE SAILOR WAS DUE TO DETACH FROM HIS CURRENT COMMAND IN DEC 00, WAS GOING ENROUTE TO A NUMBER OF DIFFERENT SCHOOLS, AND THEN REPORTING TO US IN JUL 01. WHY IS THE SAILOR ON MY MONTHLY STATUS REPORT AND WHAT SHOULD I DO? ANSWER 7: WE HAVE SEEN THIS HAPPEN A NUMBER OF TIMES SINCE ITEMPO TRACKING BEGAN ON 1 OCT 00. IT APPEARS THE SAILOR'S LAST COMMAND DID DETACH THE SAILOR SOMETIME IN DEC 00, BECAUSE THE ONLY WAY THE SAILOR WOULD APPEAR ON YOUR MONTHLY STATUS REPORT IS IF THE SAILOR, IN THE NAVY'S MASTER FILES, HAS DETACHED HIS LAST PERMANENT DUTY STATION (PDS). ONCE THAT OCCURS, THE ITEMPO SYSTEM (LIKE AN EDVR/ODCR) WILL REFLECT THE MEMBER ON THE GAINING COMMAND'S MONTHLY STATUS REPORT. IF THE SAILOR WAS ON AN ACTIVE ITEMPO DEPLOYMENT EVENT THAT BEGAN 15 NOV 00, THEN OBVIOUSLY THE EVENT ENDED PRIOR TO THE MEMBER'S TRANSFER IN DEC 00 FROM HIS LAST PDS. SO, IF THE MEMBER'S ITEMPO DEPLOYMENT EVENT CONTINUES TO REMAIN OPEN, EITHER THE LAST PDS DID NOT SUBMIT AN ITEMPO STOP EVENT, OR THE ITEMPO STOP EVENT THEY SUBMITTED ERRORED OUT FOR SOME REASON. IN EITHER CASE, THE GAINING COMMAND MUST LIAISON WITH THE LAST PDS TO ENSURE THE MEMBER'S OPEN ITEMPO EVENT IS PROPERLY ENDED. FUNCTIONAL MANAGERS AND SYSTEM DESIGNERS ARE CONSIDERING A MODIFICATION TO THE ITEMPO SYSTEM THAT MIGHT, AS IS THE CASE WITH THE EDVR/ODCR, SHOW THE MEMBER ON BOTH THE LOSING AND GAINING COMMAND'S MONTHLY STATUS REPORT FOR A SOME SPECIFIED PERIOD OF TIME. 5. RELEASED BY VADM NORB RYAN, JR., N1.// BT