System parameter

Explanation

Use database server date and time

This parameter tells e-timecard which time to use when it does the following.

• checks for late entries

• checks for late submits

• validates when an employee enters hours on a future date to an earning code that is not allowed for use in the future

By default, e-timecard uses the database server time. If your company has only one web server, then you may want to use the web server time instead, because the processing time will be faster.

If your company has more than one web server, then you should leave the default of the database server time, because that one time will always be unique.

Note that e-timecard always uses the database server time when it sets create and update times, regardless of your setting for this parameter.

Use this parameter in combination with the late entry and late submit parameters, as well as the Validate earning codes on future dates (user-defined label) parameter.

Consider time zone for late entries/submits and future dates

You can decide whether e-timecard considers the time zone when it:

• checks for late entries

• checks for late submits

• validates when an employee enters hours on a future date to an earning code that is not allowed for use in the future

If you select Yes for the Consider time zone for late entries/submits and future dates field, then e-timecard uses local time rather than the database or web server time when it performs these validations.

Your selection for this field is important if your company has many offices throughout the country or the world. For example, if your server is in New York and you have an office in California, and you set 5PM as the time for late entries, e-timecard would consider a California employee’s 2:05PM time card entry late unless you select Yes for Consider time zone for late entries/submits and future dates.

If you tell e-timecard to consider the time zone, then you must set the time zone difference between the server and each of your company’s locations. To do this, go to the Valid Values screen. Retrieve the location code, then enter a positive or negative number in the Database Server Time Difference (+/-) field. For example, if your server is in Washington, DC and the location code is in Los Angeles, you would enter -3.

Use this parameter in combination with the late entry and late submit parameters, as well as the Validate earning codes on future dates (user-defined label) parameter.

Log locked user accounts

You can tell the system to write a record to the event log when a user fails to log in more than the allowed number of times due to incorrect password. Keeping a log of failed logins can help you track users who are trying to access the e-timecard system without authorization.

Use this parameter in combination with the Disable users after failed login attempts parameter described below.

Disable users after failed login attempts

You can disable users’ ability to log in after they try but fail due to incorrect password. By users, we mean everyone who accesses the system: employees entering their own time and expenses and approving others’ time and expenses, group time/expense keepers, and administrators.

If you decide to disable users after failed logins, you choose a number between 1 and 5 to determine how many times the user can attempt to log in. Once the user’s ability to log in is disabled, you must go to the employee record to restore login privileges, unless you turn on the Enable users when they request passwords parameter described below.

You may find the disabled login feature useful in the following situations.

• If your company is a government contractor that is audited by DCAA, it can help you fulfill any requirements for locking a user out of the system after a specified number of failed login attempts.  

• You can use it to secure your system from unauthorized users. If someone knows a valid ID and attempts to guess that user’s password, the ability to lock out the ID limits the number of opportunities that the intruder has to try to enter the system.

Enable users when they request passwords

If you select to disable users after failed login attempts as described above, then you also have the option to enable users when they request a new password.

You can turn on the Enable users when they request passwords check box to automatically restore the user’s access once s/he indicates on the web that s/he wants the system to send a new, temporary password.

The default for Enable users when they request passwords is turned off, meaning that you must go to the disabled user's employee record to manually restore his/her access to e-timecard on the web.

Disable time card web entry

You can use this parameter to temporarily cut off all users’ access to the e-timecard web application. You may find this useful if you are performing system maintenance and don’t want anyone to log in until you are done.

Under normal circumstances, you should leave this check box set to the default of turned off to allow users access to e-timecard on the web.

Enable attachments

When you enable attachments, users can attach files to time cards, pre-authorization requests, and expense reports. An employee can attach and manage .gif, .jpeg, .pdf, and .doc files for his/her time cards, requests, and reports, and an approver or group time/expense keeper can attach and manage files for the time cards, requests, and reports under his/her authority.

Some typical uses for attachments are for an employee to scan paid time off forms or receipts for expenses incurred, then attach the scanned images. The approver can then download the documents and receipts directly from e-timecard or e-xpense.

Hide comments and explanations during time card entry

You have the option to turn off text comments on time cards as well as text explanations for reason codes.

The Hide comments and explanations during time card entry check box defaults to turned off, meaning that comments and explanations are available for entry.

Turn on this check box to disable text entry. When you do so, users will not see comment and explanation entry options for the following functions.

• time card entry

• change reason codes

• late entry reason codes

• late submit reason codes

• reject time card reason codes

• mass entry reason codes

Date format

The date format defaults to MM/DD/YYYY. So if the date is February 14, 2017, the system displays it as: 02/14/2017.

You can change the date format to DD/MM/YYYY if your company uses that format; for example, if you are based in a country that formats dates with the day before the month. The same date listed above appears as: 14/02/2017.

All e-timecard and e-xpense entry, administration, and mobile screens display dates in the format that you select.

One screen to note is for e-xpense entry users. If you select DD/MM/YYYY, then the Mileage screen name changes to Kilometre, and the Miles field label changes to Kilometres.

When you select the DD/MM/YYYY date format, you must add the following key to the web.config file. In this example, we use en-AU, but you can change this to the code for another country that uses the DD/MM/YYYY format.

<globalization requestEncoding="utf-8" responseEncoding="utf-8" culture="en-AU" />

For more information about making settings in web.config, see the JAMIS e-timecard Systems Guide.

Also, if you select DD/MM/YYYY, then you should change all messages in the JMEROR table to use the DD/MM/YYYY format and replace "miles" with "kilometres." You can do this on the Messages screen, or you can use SQL.