fmgo12 Trouble with date script in FM Go

[emncwundy]

We have a time card solution running on an ipad (connecting via wifi to our server which runs FM12 Advanced) for use by our employees who enter their start and finish times for the day. 

 

It is a fairly basic set up - with buttons set with 'insert current date' script attached, so that today's date will automatically enter.

 

the script reads:

 

Go to Field [employee_TiMECARDS::DateManual]

Insert Current Date [select]

Commit Records/Requests []

 

For some reason though, the ipad or FM GO does not seem to be recognising the correct date. The employees who are using the solution tell me that sometimes it enters yesterdays date, or it just stays blank.

 

Could this have something to do with FM GO going to sleep whilst not in use?

 

Is there a script i could attach to a button - which the boys could run when they open the solution up (or wake it up) before trying to enter their time - to make the ipad or or the GO software realise the correct date and time?

 

Any suggestions would be great, thanks.

[gilbenl]

Show Custom Dialog ["Clock In"; "Are you sure you want to clock in?']
If [Get(LastMessageChoice)=2]
     Exit Script[]
End If
New Record/Request
Set Field [Observers::Observer; Get (AccountName) ]
Set Field [Time Clock::Date; Get (CurrentDate)]
Set Field [Time Clock::TimeIN; Get (CurrentTime)]

I have a timeclock in my DB and this is the script I have tied to my clock in button. I run it on FM GO on iPhone 4S, 5 and iPad Retina and don't have any issues. How is your timeclock table set up in relation to your DB as a whole?

[emncwundy]

Hi Gibenl

 

Thanks so much for your suggestion.  

 

My timecard table is related to Employees by the __pkEmployeeID

 

On the ipad i have created a timecard entry screen, which is an employee table, showing portals for this weeks TimeCard records (filtered), with one portal filtered to show records for today only. It is within the portal which filters for today only records, that there are buttons to click for Insert Current Date (to insert todays date into the DateManual field), then 'StartTime', AutoLunch (which inserts 0.5hrs for lunch if lunch is taken), then a EndTime button which inserts the current time into the EndTime field.

 

It seems to be the InsertCurrentDate field, which has the following script which is problematic.

 

Would i be better to SetField; Get(CurrentDate) instead of InsertCurrentDate?

 

cheers

[gilbenl]

I'm not 100% sure, but I know that I've had problems with InsertCurrentDate and therefore use SetField; Get(CurrentDate). Also, the way your portal is set up may have something to do with it. Not sure if this is the best way to do this, but it has worked for my purposes. See attached. Username is admin with no pass. 

 

Now, the question remains as to whether or not your want to have a portal displaying the employees past entries. This is a bit more complicated. However, if you're the only one who will see this info, I suggest creating an admin dashboard.

TimeClockExample.fmp12.zip

[emncwundy]

Thanks gilbenl. I've changed the script to SetField : Get(CurrentDate) and just waiting for feedback from the boys to see if they are having problems with it. Thanks also for uploading the sample file.  Who do you email the file to once someone has clocked out? And what format does the file come through in? cheers

[gilbenl]

So the database is used by a group of students to document surgical cases. The observers have no need to see other records; they just enter data. Each session, they download an empty DB file, enter their data, and the script sends me a copy of the now populated DB (.fmp12). I then add the new records to the main DB on my computer. Next time around, they just pull a fresh copy of dropbox and repeat.

 

 

Side note: If you're using this time sheet to track your employees hours for payroll purposes, you may want to consider one of the many pre-made solutions. You can find yourself with a major headache unless you implement significant data verification. 

[emncwundy]

Hi Gilbenl

 

What do you mean by needing to implement significant data verification?

 

cheers

[gilbenl]

I am at the limit of my knowledge on the issue, but some examples that come to mind:

 

-Measures to prevent editing of clock in/out time values, intentional or accidental (IE: Security)

 

-Means of handling folks failing to clock out 

 

-Verification of time in/time out. IE: You don't want someone being able to clock in/out in the middle of the night (when they weren't authorized to work). You can check this after-the-fact, but that isn't ideal, or foolproof.

 

I'm sure there are others in the forum who are far more knowledgeable though...

[emncwundy]

ok thanks for the heads up gilbenl. cheers

[Lee Smith]

ok thanks for the heads up gilbenl. cheers

 

Our site doesn't make it easy to do in-line quotes, so I'll hope you can follow what I mean this way.

The insert scripts requires that the targeted field be on the current layout. The word "Insert" literally means put it where my cursor is or follow this track to the field.

 

Reading your script, it may be that the script isn't finding your target field.

Instead of Go to Field [], which may be on a different layout than the current one, change it to

Go to Layout [yourDateLayout]  

Insert Current Date [select]

 

HTH

Lee

[emncwundy]

thanks Lee, the Set Field : Get (CurrentDate) seems to be working ok. Is it preferable to use one over the other, ie Insert Current Date vs Get (CurrentDate)?

[Aussie John]

As Lee implied set field doesn't require the field to be on the layout.