My final target is to create a Business Event in order if Regular Time is Over 40H and is submitted, to put a timecard on hold, and send a SMS to the employee to notify him to correct it.
So my target is to have the total Regular Hour for a given timecard. My problem is i don’t find bounded field with this total. I see bounded fields like Total, total of overtime, total billable, but no total of Regular.
It’s acheivable to do a grouping in the GI or a calulation, but theses two things aren’t compatible with the business event!
Other option could be to customize and put the warning as an error, but I dislike it because that prevent saving the timecard, and the person could loss is data.
Thanks
Best answer by raphrf
Hi,
To let you know that we tested the business event trail without success. Timespent seem to be updated by an event at the time it’s submitted, and the result calculated(aggregation) in the GI is flakie. We did a lot of test and we decided to abandon this method.
We solve our problem with put “Validate on employee “Regular Hour Validation” and by customization , removing the check for if “Regular timespent”<40hours . In our case we don’t care if “Regular timespent”<40hours.
Here is the mod we did, just in case : we overide the “ValidateTotals” with a delegate method and removed in the base method what was causing my issue, like example 1 here
#region PersistDelegatepublicdelegatevoidPersistDelegate();
[PXOverride]
publicvoidPersist(PersistDelegate baseMethod)
{
// Insert Code to Execute BEFORE the Base Method
baseMethod();
// Insert Code to Execute AFTER the Base Method
}
#endregion
Have you considered using the “Regular Hours Validation” feature that’s built into Acumatica? This will prevent you from submitting it (if the Validate option is selected), but won’t prevent you from saving it.
The EPTimeCard.TimeSpent field is the “Regular” time spent field on the time card. This field may include other “non-overtime” time types like vacation, holidays, etc. Watch out though, because the value in this field is stored in minutes (not hours!)
You can also include these fields in your approval maps as well.
If you want to look specifically at “RG” time, then I’d suggest looking at putting together a GI including the EPTimeCardDetail or PMTimeActivities tables which look at the individual activities, BUT this table will only include the timecardCD value after the time card is submitted (pending approval, approved, rejected, released, etc.) which makes it tricky to report off of because while the time card is “on hold” there’s no link back to the time card reference number.
Have you considered using the “Regular Hours Validation” feature that’s built into Acumatica? This will prevent you from submitting it (if the Validate option is selected), but won’t prevent you from saving it.
I was wrong I thought that was preventing to save, so it’s well done!
My problem is we don’t want to prevent submitting if hours of timecard is less than 40, ex 32hours, is fine. Actually, acumatica prevent it :
“Time Card is not valid. Please correct and try again. The time card must be filled out completely. The norm of regular hours this employee should spend during a week is 40,0000 hours. You can click Normalize Time Card on the table toolbar of the Summary tab to automatically fill up the remaining hours.”
Then try using your business event with the The EPTimeCard.TimeSpent field as the trigger for the email/business event. That’s the one where the “regular time” value is stored. Watch out, as some of the time fields in Acumatica are stored in minutes not hours.
To let you know that we tested the business event trail without success. Timespent seem to be updated by an event at the time it’s submitted, and the result calculated(aggregation) in the GI is flakie. We did a lot of test and we decided to abandon this method.
We solve our problem with put “Validate on employee “Regular Hour Validation” and by customization , removing the check for if “Regular timespent”<40hours . In our case we don’t care if “Regular timespent”<40hours.
Here is the mod we did, just in case : we overide the “ValidateTotals” with a delegate method and removed in the base method what was causing my issue, like example 1 here
#region PersistDelegatepublicdelegatevoidPersistDelegate();
[PXOverride]
publicvoidPersist(PersistDelegate baseMethod)
{
// Insert Code to Execute BEFORE the Base Method
baseMethod();
// Insert Code to Execute AFTER the Base Method
}
#endregion
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
