Errors with Pay Periods

General support regarding TimeTrex, such as
configuring policies/taxes or processing payroll.
Locked
lstoumbos
Posts: 80
Joined: Wed Jan 10, 2007 7:41 am

Errors with Pay Periods

Post by lstoumbos »

TT 1.5.1
PHP 5.1.2
MySQL 5.0.24a
Linux 2.6

Code: Select all

DEBUG [153]:    <b>[Function]()</b>: URI: /interface/punch/EditPunch.php<br>
DEBUG [155]:    <b>[Function]()</b>: Production: 1<br>
DEBUG [486]:    <b>Authentication::Check()</b>: Session Name: SessionID<br>
DEBUG [492]:    <b>Authentication::Check()</b>: Session ID: c1123a3284cfa58595f20ecaf78c7968<br>
DEBUG [301]:    <b>Validator::stripNonAlphaNumeric()</b>: Alpha Numeric String:c1123a3284cfa58595f20ecaf78c7968<br>
DEBUG [78]:     <b>Authentication::getIdle()</b>: Idle Seconds Allowed: 14400<br>
DEBUG [301]:    <b>Validator::stripNonAlphaNumeric()</b>: Alpha Numeric String:c1123a3284cfa58595f20ecaf78c7968<br>
DEBUG [62]:     <b>[Function]()</b>: User Authenticated: admin Created Date: 1173105010<br>
DEBUG [1817]:   <b>UserFactory::isInformationComplete()</b>: User Information is Complete: <br>
DEBUG [92]:     <b>TTDate::setTimeZone()</b>: Setting TimeZone: America/Detroit<br>
DEBUG [108]:    <b>TTDate::setDateFormat()</b>: Setting Default Date Format: d-M-y<br>
DEBUG [122]:    <b>TTDate::setTimeFormat()</b>: Setting Default Time Format: g:i A<br>
DEBUG [136]:    <b>TTDate::setTimeUnitFormat()</b>: Setting Default Time Unit Format: 10<br>
DEBUG [1817]:   <b>UserFactory::isInformationComplete()</b>: User Information is Complete: <br>
DEBUG [954]:    <b>UserPreferenceFactory::isPreferencesComplete()</b>: User Preferences IS Complete: <br>
DEBUG [104]:    <b>[Function]()</b>: Station ID Cookie found! 3083fcb10b229ce14b776f54870470fd<br>
DEBUG [277]:    <b>TTDate::parseDateTime()</b>: String: 05-Mar-07 9:00 AM Date Format: d-M-y<br>
DEBUG [370]:    <b>TTDate::parseDateTime()</b>: NO Custom Parse Format detected!<br>
DEBUG [373]:    <b>TTDate::parseDateTime()</b>: Parsing Date: 05-Mar-07 9:00 AM<br>
DEBUG [387]:    <b>TTDate::parseDateTime()</b>: Parsed Date: 05-Mar-07 9:00 AM<br>
DEBUG [277]:    <b>TTDate::parseDateTime()</b>: String: 05-Mar-07 Date Format: d-M-y<br>
DEBUG [370]:    <b>TTDate::parseDateTime()</b>: NO Custom Parse Format detected!<br>
DEBUG [373]:    <b>TTDate::parseDateTime()</b>: Parsing Date: 05-Mar-07<br>
DEBUG [387]:    <b>TTDate::parseDateTime()</b>: Parsed Date: 05-Mar-07 12:00 AM<br>
DEBUG [102]:    <b>[Function]()</b>: Submit!<br>
DEBUG [720]:    <b>Factory::StartTransaction()</b>: StartTransaction(): Transaction Count: 0 Trans Off: 0<br>
DEBUG [112]:    <b>[Function]()</b>: Repeating Punch For: 0 Days<br>
DEBUG [118]:    <b>[Function]()</b>: Punch Repeat: 0<br>
DEBUG [124]:    <b>[Function]()</b>: Punch Full Time Stamp: 05-Mar-07 9:00 AM<br>
DEBUG [125]:    <b>PunchControlFactory::findUserDate()</b>:  Pay Period Schedule Continuous Time: 43200<br>
DEBUG [243]:    <b>PunchListFactory::getFirstPunchByUserIDAndEpoch()</b>:  bPay Period Schedule Continuous Time: 43200<br>
DEBUG [156]:    <b>PunchControlFactory::findUserDate()</b>: Skipping Find...<br>
DEBUG [157]:    <b>PunchControlFactory::findUserDate()</b>:  Pay Period Schedule Record Count: 1<br>
DEBUG [209]:    <b>UserDateFactory::findOrInsertUserDate()</b>:  More then 1 user date row was detected!!: 2<br>
DEBUG [212]:    <b>UserDateFactory::findOrInsertUserDate()</b>:  Cant find or insert User Date ID. User ID: 23 Date: 1173103200<br>
DEBUG [164]:    <b>PunchControlFactory::setUserDate()</b>:  User Date ID: <br>
DEBUG [169]:    <b>PunchControlFactory::setUserDate()</b>:  No User Date ID found<br>
DEBUG [737]:    <b>Factory::isValid()</b>: Calling Validate()<br>
DEBUG [813]:    <b>PunchControlFactory::Validate()</b>: Validating...<br>
DEBUG [814]:    <b>PunchControlFactory::Validate()</b>: User Date Id: <br>
DEBUG [405]:    <b>Validator::Error()</b>: Validation Error: Label: pay_period Msg: Pay Period is Currently Locked, or Date/Time is incorrect<br>
DEBUG [384] Array: <b>Validator::isValid()</b>: Errors
<pre>
array(1) {
  ["pay_period"]=>
  array(1) {
    [0]=>
    string(57) "Pay Period is Currently Locked, or Date/Time is incorrect"
  }
}
</pre><br>
DEBUG [235]:    <b>[Function]()</b>:  cFail Transaction: <br>
DEBUG [725]:    <b>Factory::FailTransaction()</b>: FailTransaction(): Transaction Count: 1 Trans Off: 1<br>
DEBUG [473]:    <b>[Function]()</b>: pc_data[date_stamp]: 05-Mar-07 12:00 AM<br>
DEBUG [384] Array: <b>Validator::isValid()</b>: Errors
<pre>
array(1) {
  ["pay_period"]=>
  array(1) {
    [0]=>
    string(57) "Pay Period is Currently Locked, or Date/Time is incorrect"
  }
}
</pre><br>
DEBUG [374]:    <b>Validator::isValid()</b>: Num Errors: 1<br>
DEBUG [374]:    <b>Validator::isValid()</b>: Num Errors: 1<br>
DEBUG [374]:    <b>Validator::isValid()</b>: Num Errors: 1<br>
DEBUG [374]:    <b>Validator::isValid()</b>: Num Errors: 1<br>
DEBUG [374]:    <b>Validator::isValid()</b>: Num Errors: 1<br>
DEBUG [374]:    <b>Validator::isValid()</b>: Num Errors: 1<br>
Not sure what is going but I am getting validation errors.
I have a user and she can't get edit her schedule and another can't add a user.
lstoumbos
Posts: 80
Joined: Wed Jan 10, 2007 7:41 am

Pay period problem

Post by lstoumbos »

Ok heres what happened. Me and another user both entered a punch in at the same time. It appeared to create to time stamps

Code: Select all

DEBUG [209]:    <b>UserDateFactory::findOrInsertUserDate()</b>:  More then 1 user date row was detected!!: 2<br> 
What I did is removed both of them and then tried again to enter the information and that worked. My suggestion is that in the future if there is more than one matching punch in or punch out that all but 1 be removed to avoid this error.

Thanks.
lstoumbos
Posts: 80
Joined: Wed Jan 10, 2007 7:41 am

Post by lstoumbos »

Sorry to write again, but I have found a bug. It appears when you don't set the default policy for a new hire and leave it blank, TT will not enter the user in a policy group and then when you wish to change their policy group you get an error saying that the server is currently undergoing maintenance.

This might be something you want to look into.

Thank you,
Luke
shaunw
Posts: 7839
Joined: Tue Sep 19, 2006 2:22 pm

Post by shaunw »

I'm unable to replicate this issue on our end. Can you please provide more details, perhaps a copy of your PHP/TimeTrex logs when the error occurs?

If you can try replicating the issue on our online demonstration that would be excellent to.
lstoumbos
Posts: 80
Joined: Wed Jan 10, 2007 7:41 am

Post by lstoumbos »

What seems to happen is when I create a new employee and don't have the default policy group assigned it leaves it blank. That makes sense but what doesn't is when I actually try to then assign a policy group to the employee. It seems almost like it knows that one isn't assigned, but then tries to assign it and fails. In the database you don't see where the user has been assigned. Here is the logs I have been getting.

Code: Select all

DEBUG [153]:	<b>[Function]()</b>: URI: /interface/users/EditUser.php<br>
DEBUG [155]:	<b>[Function]()</b>: Production: 1<br>
DEBUG [486]:	<b>Authentication::Check()</b>: Session Name: SessionID<br>
DEBUG [492]:	<b>Authentication::Check()</b>: Session ID: 0d0a72769673876eb042ff72263a4cc7<br>
DEBUG [301]:	<b>Validator::stripNonAlphaNumeric()</b>: Alpha Numeric String:0d0a72769673876eb042ff72263a4cc7<br>
DEBUG [78]:	<b>Authentication::getIdle()</b>: Idle Seconds Allowed: 14400<br>
DEBUG [301]:	<b>Validator::stripNonAlphaNumeric()</b>: Alpha Numeric String:0d0a72769673876eb042ff72263a4cc7<br>
DEBUG [62]:	<b>[Function]()</b>: User Authenticated: courtneyb Created Date: 1172846406<br>
DEBUG [1817]:	<b>UserFactory::isInformationComplete()</b>: User Information is Complete: <br>
DEBUG [92]:	<b>TTDate::setTimeZone()</b>: Setting TimeZone: America/Detroit<br>
DEBUG [108]:	<b>TTDate::setDateFormat()</b>: Setting Default Date Format: d-M-y<br>
DEBUG [122]:	<b>TTDate::setTimeFormat()</b>: Setting Default Time Format: g:i A<br>
DEBUG [136]:	<b>TTDate::setTimeUnitFormat()</b>: Setting Default Time Unit Format: 10<br>
DEBUG [1817]:	<b>UserFactory::isInformationComplete()</b>: User Information is Complete: <br>
DEBUG [954]:	<b>UserPreferenceFactory::isPreferencesComplete()</b>: User Preferences IS Complete: <br>
DEBUG [104]:	<b>[Function]()</b>: Station ID Cookie found! afaffc3b4b3fbba10755ee373f323de8<br>
DEBUG [199]:	<b>[Function]()</b>: UnRead Messages: 0<br>
DEBUG [227]:	<b>[Function]()</b>: Exception Flag to Display: yellow<br>
DEBUG [277]:	<b>TTDate::parseDateTime()</b>: String: 05-Feb-07 Date Format: d-M-y<br>
DEBUG [370]:	<b>TTDate::parseDateTime()</b>: NO Custom Parse Format detected!<br>
DEBUG [373]:	<b>TTDate::parseDateTime()</b>: Parsing Date: 05-Feb-07<br>
DEBUG [387]:	<b>TTDate::parseDateTime()</b>: Parsed Date: 05-Feb-07 12:00 AM<br>
DEBUG [67]:	<b>[Function]()</b>: NOT Running strtotime on Termination date<br>
DEBUG [428]:	<b>HierarchyListFactory::getHierarchyChildrenByCompanyIdAndUserIdAndObjectTypeID()</b>:  Hierarchy Control ID: 1<br>
DEBUG [54]:	<b>FastTree::__construct()</b>:  Contruct... <br>
DEBUG [60]:	<b>FastTree::__construct()</b>:  Setting Table to: hierarchy_tree<br>
DEBUG [77]:	<b>FastTree::setTree()</b>:  Setting Tree ID to: 1<br>
DEBUG [116]:	<b>FastTree::getNode()</b>:  Object ID: 0<br>
DEBUG [98]:	<b>FastTree::_setupTree()</b>:  NOT Initiating Tree with Root object: <br>
DEBUG [77]:	<b>FastTree::setTree()</b>:  Setting Tree ID to: 1<br>
DEBUG [116]:	<b>FastTree::getNode()</b>:  Object ID: 0<br>
DEBUG [98]:	<b>FastTree::_setupTree()</b>:  NOT Initiating Tree with Root object: <br>
DEBUG [179]:	<b>FastTree::getParentId()</b>:  Object ID: 10<br>
DEBUG [116]:	<b>FastTree::getNode()</b>:  Object ID: 10<br>
DEBUG [327]:	<b>FastTree::getAllChildren()</b>:  Object ID: 64 Recurse: <br>
DEBUG [116]:	<b>FastTree::getNode()</b>:  Object ID: 64<br>
DEBUG [345]:	<b>FastTree::getAllChildren()</b>:  Left ID: 638 Level: 1<br>
DEBUG [172] Array: <b>HierarchyListFactory::getCurrentLevelIdArrayByHierarchyControlIdAndUserId()</b>:  Nodes at the same level <pre>
array(4) {
  [0]=>
  int(102)
  [1]=>
  int(34)
  [2]=>
  int(10)
  [3]=>
  int(50)
}
</pre><br>
DEBUG [186]:	<b>HierarchyListFactory::getCurrentLevelIdArrayByHierarchyControlIdAndUserId()</b>:  Node isnt shared:  102<br>
DEBUG [186]:	<b>HierarchyListFactory::getCurrentLevelIdArrayByHierarchyControlIdAndUserId()</b>:  Node isnt shared:  34<br>
DEBUG [186]:	<b>HierarchyListFactory::getCurrentLevelIdArrayByHierarchyControlIdAndUserId()</b>:  Node isnt shared:  10<br>
DEBUG [186]:	<b>HierarchyListFactory::getCurrentLevelIdArrayByHierarchyControlIdAndUserId()</b>:  Node isnt shared:  50<br>
DEBUG [59] Array: <b>HierarchyListFactory::getChildLevelIdArrayByHierarchyControlIdAndUserId()</b>:  Nodes at the same level <pre>
array(1) {
  [0]=>
  int(10)
}
</pre><br>
DEBUG [69]:	<b>HierarchyListFactory::getChildLevelIdArrayByHierarchyControlIdAndUserId()</b>:  Getting Children of ID: 10<br>
DEBUG [327]:	<b>FastTree::getAllChildren()</b>:  Object ID: 10 Recurse: <br>
DEBUG [116]:	<b>FastTree::getNode()</b>:  Object ID: 10<br>
DEBUG [345]:	<b>FastTree::getAllChildren()</b>:  Left ID: 736 Level: 2<br>
DEBUG [84]:	<b>[Function]()</b>: Submit!<br>
DEBUG [277]:	<b>UserFactory::setCompany()</b>: Company ID: 1<br>
DEBUG [94]:	<b>Validator::inArrayKey()</b>: Key: 10<br>
DEBUG [131]:	<b>Validator::isRegEx()</b>: Value: rachelf RegEx: /^[a-z0-9-_\.@]{1,250}$/i<br>
DEBUG [144]:	<b>Validator::isLength()</b>: Value: rachelf Length: 7 Min: 4 Max: 250<br>
DEBUG [406] Array: <b>UserFactory::isUniqueUserName()</b>: Unique User Name: rachelf <pre>
string(3) "106"
</pre><br>
DEBUG [745]:	<b>TTDate::getTimeStamp()</b>: Epoch: 434174400 Date: <br>
DEBUG [256]:	<b>Validator::isDate()</b>: Raw Date: 434174400 Converted Value: 434174400<br>
DEBUG [256]:	<b>Validator::isDate()</b>: Raw Date: 1170651600 Converted Value: 1170651600<br>
DEBUG [106]:	<b>Validator::isNumeric()</b>: Value:106<br>
DEBUG [786] Array: <b>UserFactory::isUniqueEmployeeNumber()</b>: Unique Job Item: 106 <pre>
string(3) "106"
</pre><br>
DEBUG [886]:	<b>UserFactory::setDefaultBranch()</b>: Branch ID: 4<br>
DEBUG [915]:	<b>UserFactory::setDefaultDepartment()</b>: Department ID: 1<br>
DEBUG [331]:	<b>UserFactory::setGroup()</b>: Group ID: 7<br>
DEBUG [737]:	<b>Factory::isValid()</b>: Calling Validate()<br>
DEBUG [720]:	<b>Factory::StartTransaction()</b>: StartTransaction(): Transaction Count: 0 Trans Off: 0<br>
DEBUG [766]:	<b>Factory::Save()</b>: Calling preSave()<br>
DEBUG [737]:	<b>Factory::isValid()</b>: Calling Validate()<br>
DEBUG [809]:	<b>Factory::Save()</b>:  Updating...<br>
DEBUG [634]:	<b>Factory::getUpdateQuery()</b>: Update<br>
DEBUG [256]:	<b>Validator::isDate()</b>: Raw Date: 1172847073 Converted Value: 1172847073<br>
DEBUG [665]:	<b>Factory::getUpdateQuery()</b>: Data changed, set updated date: <br>
DEBUG [106]:	<b>Validator::isNumeric()</b>: Value:106<br>
DEBUG [94]:	<b>Validator::inArrayKey()</b>: Key: 20<br>
DEBUG [144]:	<b>Validator::isLength()</b>: Value: users Length: 5 Min: 2 Max: 250<br>
DEBUG [144]:	<b>Validator::isLength()</b>: Value: User Information Length: 16 Min: 2 Max: 2000<br>
DEBUG [720]:	<b>Factory::StartTransaction()</b>: StartTransaction(): Transaction Count: 1 Trans Off: 1<br>
DEBUG [766]:	<b>Factory::Save()</b>: Calling preSave()<br>
DEBUG [256]:	<b>Validator::isDate()</b>: Raw Date: 1172847073 Converted Value: 1172847073<br>
DEBUG [796]:	<b>Factory::Save()</b>: Insert ID: 5203<br>
DEBUG [702]:	<b>Factory::getInsertQuery()</b>: Insert<br>
DEBUG [730]:	<b>Factory::CommitTransaction()</b>: CommitTransaction(): Transaction Count: 1 Trans Off: 2<br>
DEBUG [847]:	<b>Factory::Save()</b>: Calling postSave()<br>
DEBUG [77]:	<b>Factory::removeCache()</b>: Attempting to remove cache: 106<br>
DEBUG [80]:	<b>Factory::removeCache()</b>: Removing cache: 106<br>
DEBUG [1862]:	<b>UserFactory::postSave()</b>: Pay Period Schedule is set...<br>
DEBUG [1870]:	<b>UserFactory::postSave()</b>: Already assigned to this Pay Period Schedule...<br>
DEBUG [69] Array: <b>PayPeriodScheduleUserFactory::isUniqueUser()</b>: Unique User ID: 107 <pre>
string(3) "107"
</pre><br>
DEBUG [405]:	<b>Validator::Error()</b>: Validation Error: Label: user Msg: Selected Employee is already assigned to another Pay Period<br>
DEBUG [384] Array: <b>Validator::isValid()</b>: Errors <pre>
array(1) {
  ["user"]=>
  array(1) {
    [0]=>
    string(59) "Selected Employee is already assigned to another Pay Period"
  }
}
</pre><br>
DEBUG [1902]:	<b>UserFactory::postSave()</b>: Policy Group is set...<br>
DEBUG [1926]:	<b>UserFactory::postSave()</b>: Not assigned to ANY Policy Group...<br>
DEBUG [72] Array: <b>PolicyGroupUserFactory::isUniqueUser()</b>: Unique User ID: 
<pre>
bool(false)
</pre><br>
DEBUG [720]:	<b>Factory::StartTransaction()</b>: StartTransaction(): Transaction Count: 1 Trans Off: 1<br>
DEBUG [796]:	<b>Factory::Save()</b>: Insert ID: 111<br>
DEBUG [702]:	<b>Factory::getInsertQuery()</b>: Insert<br>
Thank you for any help. I have found a way around it by manually entering the information in the database.
shaunw
Posts: 7839
Joined: Tue Sep 19, 2006 2:22 pm

Post by shaunw »

Selected Employee is already assigned to another Pay Period
That error message has nothing to do with policy groups, but instead pay periods. I am still unable to reproduce the issue on our end. Is it possible for you to try and reproduce the issue on our demonstration server? (Click View Demo on our website) If it is, if you can provide exact steps to reproduce it then we can fix the bug.
lstoumbos
Posts: 80
Joined: Wed Jan 10, 2007 7:41 am

Post by lstoumbos »

I will give it a try.
lstoumbos
Posts: 80
Joined: Wed Jan 10, 2007 7:41 am

Post by lstoumbos »

Doesn't work on yours. No matter what I do it won't give me that error on yours. HMM I will look into this further.
lstoumbos
Posts: 80
Joined: Wed Jan 10, 2007 7:41 am

Post by lstoumbos »

It seems to have started with the this table 'policy_group_user' and the squence was off I imagine. The highest policy_group_user.id I had was 105 but in this table policy_group_user_id_seq it said 119. I automatically inserted 2 users in the database table policy_group_user, but didn't change the table policy_group_user_id_seq to show the correct id. That did take care of the error from showing up.
shaunw
Posts: 7839
Joined: Tue Sep 19, 2006 2:22 pm

Post by shaunw »

Yes, manually touching the database at all is a very bad idea, we recommend against unless absolutely necessary. Chances are quite likely it will cause problems elsewhere in TimeTrex at some later date, such as this.
lstoumbos
Posts: 80
Joined: Wed Jan 10, 2007 7:41 am

Post by lstoumbos »

I don't think your understanding. Touching the database is a bad idea but it took care of the problem. What I am trying to tell you is what was in the database before I fixed the problem.
Locked