assistant duty not tracked on eservices?

Started by Майор Хаткевич, May 09, 2013, 03:48:09 PM

0 Members and 1 Guest are viewing this topic.

Private Investigator

Quote from: SarDragon on May 11, 2013, 09:16:52 PM
I looked at my record, and there are two instances where I moved up from Assistant to Primary that do not show the Assistant time. Not a CC problem.

My Assistant time as Prof Dev and Admin both show up as well as my primary time. So not a technical problem. Likely "Greeter" does not rate assistant time once you promote to "Primary Greeter".   >:D

Tim Medeiros

Quote from: Spaceman3750 on May 09, 2013, 06:17:14 PM
If they switch you directly from assistant to primary, it doesn't get tracked. You have to delete the assignment then re-add as primary for it to show in the history. You can backdate the assistant assignment then delete it to fix the issue.

I had this issue once as well.
This is the answer to everyones issues.

If you're switching from primary to assistant or vice versa you/DP/CC will want to remove the position entirely and readd it with the right flag (primary or assistant).  If you skipped the remove position step the date will NOT update.
TIMOTHY R. MEDEIROS, Lt Col, CAP
Chair, National IT Functional User Group
1577/2811

Майор Хаткевич


Tim Medeiros

TIMOTHY R. MEDEIROS, Lt Col, CAP
Chair, National IT Functional User Group
1577/2811

Майор Хаткевич

Certainly not an initiative process ...

Tim Medeiros

Quote from: usafaux2004 on May 13, 2013, 10:10:13 PM
Certainly not an initiative process ...
initiative process?  I'm going to assume you meant intuitive, which I'll agree with.  I'm just saying, we don't have what requirements the developers were given.  We also don't have what the intended process was.  Without that we cannot actually say whether or not it is a bug or simply users using a system in such a way that was not planned to happen.
TIMOTHY R. MEDEIROS, Lt Col, CAP
Chair, National IT Functional User Group
1577/2811

Майор Хаткевич

[darn] smartphone...

If then purpose is to track previous duties, and changing the yes/ no resets the counter, I'd say the previous job needs to automatically port into past duties. I don't think companies terminate assistant managers when they get promoted to general manager to do the switch.

Tim Medeiros

Quote from: usafaux2004 on May 13, 2013, 10:39:20 PM
[darn] smartphone...

If then purpose is to track previous duties, and changing the yes/ no resets the counter, I'd say the previous job needs to automatically port into past duties. I don't think companies terminate assistant managers when they get promoted to general manager to do the switch.
No they don't but their job as assistant manager IS terminated and a new one as general manager is begun.
TIMOTHY R. MEDEIROS, Lt Col, CAP
Chair, National IT Functional User Group
1577/2811

Майор Хаткевич

Right, the records don't get burned however.

spacecommand

Quote from: Private Investigator on May 12, 2013, 09:54:52 PM
Quote from: Storm Chaser on May 11, 2013, 05:16:16 PM
Quote from: Private Investigator on May 11, 2013, 05:00:41 PM
I am thinking it is a Unit CC issue and not a technical one.

Can you please explain?

Did the Unit/CC put your assignment into eservices? My present Squadron Commander tells everyone they are assigned Assistant Comm Officer, PAO (primary) Supply Officer, etc, etc. When we had an SUI turns out 50% people never were assigned according to eservices.


In my case, Yes I was assigned into the job, in reading the other posts, the issue is not with proper assignment to a position by the CC, it is with when you change directly from Assistant: " YES" to Assistant: "NO"  the record doesn't reflect the Assistant: "YES" dates, it just records that dates  as "Assistant: NO" even though you started off as Assistant "YES". 

Storm Chaser

Quote from: Private Investigator on May 12, 2013, 09:54:52 PM
Quote from: Storm Chaser on May 11, 2013, 05:16:16 PM
Quote from: Private Investigator on May 11, 2013, 05:00:41 PM
I am thinking it is a Unit CC issue and not a technical one.

Can you please explain?

Did the Unit/CC put your assignment into eservices? My present Squadron Commander tells everyone they are assigned Assistant Comm Officer, PAO (primary) Supply Officer, etc, etc. When we had an SUI turns out 50% people never were assigned according to eservices.

Now on my present Wing Staff assignment, I am IAOD from a SQ,  the Wing/CS accidently put me in eservices as Unit Staff. He cancelled it and put me in my current assignment as Wing Staff. On eservices it shows I was Unit Staff for one day. Saavy?

Yes, the assignment was made by the commander. This is a real issue with eServices. I was originally assigned as an assistant in eServices (I can verify that, as I have an old print out) and recently appointed as primary. The primary position with the new date shows in eServices, but the old assistant position that should show under past duty position does not.

a2capt

Because it's treating anything to an existing record as a change to that record, which is intuitively correct from many angles.

What should be happening, to be accurate with the workflow, is a change in that field should mean "make a new record, and close the old one effective today" (or whatever date is entered)

Tim Medeiros

Quote from: usafaux2004 on May 13, 2013, 11:18:42 PM
Right, the records don't get burned however.
Under the procedures I mentioned above, records are not burned, so not seeing the issue.  If the system is used as designed then there are no issues.
TIMOTHY R. MEDEIROS, Lt Col, CAP
Chair, National IT Functional User Group
1577/2811

Storm Chaser

Quote from: Tim Medeiros on May 14, 2013, 04:28:29 PM
Quote from: usafaux2004 on May 13, 2013, 11:18:42 PM
Right, the records don't get burned however.
Under the procedures I mentioned above, records are not burned, so not seeing the issue.  If the system is used as designed then there are no issues.

As a software test engineer and UI designer, I can tell you it is a poor design and not intuitive at all. If the correct workflow is to remove a position and then add the new one, then the system shouldn't allow a commander to change the assistant flag by itself. As a minimum, a warning should be displayed. If I was testing this system, I would write it up as a defect.

Tim Medeiros

Not disputing that things could have been done differently, just stating that 1) it's technically working as designed as far as I can tell, 2) we don't have the requirements that the developers were given so we cannot actually say if it is a bug or users finding a way around the intended operation of the system, which I'm sure you know happens quite frequently.
TIMOTHY R. MEDEIROS, Lt Col, CAP
Chair, National IT Functional User Group
1577/2811

Storm Chaser

Perhaps it's not a software defect (bug), but a design or requirement defect. Maybe the system is as designed. Either way, there's an unintended behavior that it's easily caused by what many would consider "normal" operations. I think it should be changed or corrected.

a2capt

It's like IMU. It does "exactly" what the paper flow does. Only, the paper method usually doesn't result in the user wanting to take a bat to the thing. ;)

The aircrew is here, in front of me, I want to use the airplane for someone else, but I can't because the debrief has not been entered. In the real world, you hand them the keys and they go.

Storm Chaser

Does anyone know if this issue was resolved?

SunDog

Yeah, whether bug, requirements shortcoming, or design flaw, the behaviour doesn't meet the business need. Brute force a correction in the data for a called-out occurrence, leave it gacked for the rest??? Bad Ju-ju. . .good thing the paper exists, except that leaves hard-copy as the authoritative data source. Sure that was planned for and designed into the system. . .maybe not?

NHQ can base actions on the electrons, and the field can counter with the paper. Spend happy hours sorting it out. Thank goodness this is a rare, unusual, and very isolated flaw in an otherwise well designed, implemented, and maintained system. 




SarDragon

Quote from: SunDog on October 02, 2013, 04:13:50 AM
Yeah, whether bug, requirements shortcoming, or design flaw, the behaviour doesn't meet the business need. Brute force a correction in the data for a called-out occurrence, leave it gacked for the rest??? Bad Ju-ju. . .good thing the paper exists, except that leaves hard-copy as the authoritative data source. Sure that was planned for and designed into the system. . .maybe not?

NHQ can base actions on the electrons, and the field can counter with the paper. Spend happy hours sorting it out. Thank goodness this is a rare, unusual, and very isolated flaw in an otherwise well designed, implemented, and maintained system.

Really? Did I miss some sarcasm?

This is a problem for about half of my unit, being neither rare, unusual, nor isolated. We're doing a little catch-up in the PD area, trying to get specialty tracks correctly documented, and not having the correct data available in eServices is making that job more difficult. I'm sure my unit isn't the only one, by far, with this issue.
Dave Bowles
Maj, CAP
AT1, USN Retired
50 Year Member
Mitchell Award (unnumbered)
C/WO, CAP, Ret