Welcome, Guest. Please login or register.
Did you miss your activation email?
April 19, 2019, 08:24:30 PM
Home Help Login Register
News:

CAP Talk  |  General Discussion  |  Membership  |  Topic: assistant duty not tracked on eservices?
0 Members and 1 Guest are viewing this topic.
Pages: 1 [2] 3  All Send this topic Print
Author Topic: assistant duty not tracked on eservices?  (Read 6315 times)
Private Investigator
Salty & Seasoned Contributor

Posts: 2,158

« Reply #20 on: May 12, 2013, 09:59:41 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
Report to moderator   Logged
Tim Medeiros
Salty & Seasoned Contributor

Posts: 709
Unit: AZ-001

« Reply #21 on: May 13, 2013, 06:44:40 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.
Report to moderator   Logged
TIMOTHY R. MEDEIROS, Lt Col, CAP
Member, National IT Functional User Group
1577/2811
Майор Хаткевич
200,000th Post Author
Salty & Seasoned Contributor

Posts: 6,062
Unit: GLR-IL-049

« Reply #22 on: May 13, 2013, 10:02:44 PM »

I'd call that a bug/unfinished code.
Report to moderator   Logged
Tim Medeiros
Salty & Seasoned Contributor

Posts: 709
Unit: AZ-001

« Reply #23 on: May 13, 2013, 10:04:51 PM »

I'd call that a bug/unfinished code.
Depends on what the intention was.
Report to moderator   Logged
TIMOTHY R. MEDEIROS, Lt Col, CAP
Member, National IT Functional User Group
1577/2811
Майор Хаткевич
200,000th Post Author
Salty & Seasoned Contributor

Posts: 6,062
Unit: GLR-IL-049

« Reply #24 on: May 13, 2013, 10:10:13 PM »

Certainly not an initiative process ...
Report to moderator   Logged
Tim Medeiros
Salty & Seasoned Contributor

Posts: 709
Unit: AZ-001

« Reply #25 on: May 13, 2013, 10:36:01 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.
Report to moderator   Logged
TIMOTHY R. MEDEIROS, Lt Col, CAP
Member, National IT Functional User Group
1577/2811
Майор Хаткевич
200,000th Post Author
Salty & Seasoned Contributor

Posts: 6,062
Unit: GLR-IL-049

« Reply #26 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.
Report to moderator   Logged
Tim Medeiros
Salty & Seasoned Contributor

Posts: 709
Unit: AZ-001

« Reply #27 on: May 13, 2013, 11:00:19 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.
Report to moderator   Logged
TIMOTHY R. MEDEIROS, Lt Col, CAP
Member, National IT Functional User Group
1577/2811
Майор Хаткевич
200,000th Post Author
Salty & Seasoned Contributor

Posts: 6,062
Unit: GLR-IL-049

« Reply #28 on: May 13, 2013, 11:18:42 PM »

Right, the records don't get burned however.
Report to moderator   Logged
spacecommand
Salty & Seasoned Contributor

Posts: 545

« Reply #29 on: May 14, 2013, 06:58:51 AM »

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". 
Report to moderator   Logged
Storm Chaser
Salty & Seasoned Contributor

Posts: 2,680

« Reply #30 on: May 14, 2013, 03:56:53 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.
Report to moderator   Logged
a2capt
300,000th Post Author
Salty & Seasoned Contributor

Posts: 5,089
Unit: pǝʇɹǝʌuı

« Reply #31 on: May 14, 2013, 04:27:12 PM »

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)
Report to moderator   Logged
Tim Medeiros
Salty & Seasoned Contributor

Posts: 709
Unit: AZ-001

« Reply #32 on: May 14, 2013, 04:28:29 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.
Report to moderator   Logged
TIMOTHY R. MEDEIROS, Lt Col, CAP
Member, National IT Functional User Group
1577/2811
Storm Chaser
Salty & Seasoned Contributor

Posts: 2,680

« Reply #33 on: May 14, 2013, 04:38:56 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.
Report to moderator   Logged
Tim Medeiros
Salty & Seasoned Contributor

Posts: 709
Unit: AZ-001

« Reply #34 on: May 14, 2013, 04:59:56 PM »

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.
Report to moderator   Logged
TIMOTHY R. MEDEIROS, Lt Col, CAP
Member, National IT Functional User Group
1577/2811
Storm Chaser
Salty & Seasoned Contributor

Posts: 2,680

« Reply #35 on: May 14, 2013, 05:27:00 PM »

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.
Report to moderator   Logged
a2capt
300,000th Post Author
Salty & Seasoned Contributor

Posts: 5,089
Unit: pǝʇɹǝʌuı

« Reply #36 on: May 14, 2013, 05:30:34 PM »

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.
Report to moderator   Logged
Storm Chaser
Salty & Seasoned Contributor

Posts: 2,680

« Reply #37 on: October 01, 2013, 01:22:06 PM »

Does anyone know if this issue was resolved?
Report to moderator   Logged
SunDog
Seasoned Member

Posts: 478

« Reply #38 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. 



Report to moderator   Logged
SarDragon
Global Moderator

Posts: 10,626
Unit: NAVAIRPAC

« Reply #39 on: October 02, 2013, 04:29:40 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.
Report to moderator   Logged
Dave Bowles
Maj, CAP
AT1, USN Retired
Mitchell Award (unnumbered)
C/WO, CAP, Ret
Pages: 1 [2] 3  All Send this topic Print 
CAP Talk  |  General Discussion  |  Membership  |  Topic: assistant duty not tracked on eservices?
 


Powered by MySQL Powered by PHP SMF 2.0.14 | SMF © 2017, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.099 seconds with 26 queries.