New California sick leave requirements effective July 1

When we first heard about the final implementation of this law effective July 1 in early to mid-July, last minute changes were still being made.   One of the impacts of the law relates to a requirement to notify employees of their sick leave availability, one of the simpler methods being via a paycheck stub or equivalent.

The law states:

246 (h) An employer shall provide an employee with written notice that sets forth the amount of paid sick leave available, or paid time off leave an employer provides in lieu of sick leave, for use on either the employee’s itemized wage statement described in Section 226 or in a separate writing provided on the designated pay date with the employee’s payment of wages.

Section 226(a) outlines how employee wage payment information must be to provided to employees, and what minimum information must be provided.

With few exceptions, starting July 1, 2015 employees who work at least 30 days* for the same California employer within a one year period are entitled to the sick leave at a rate of not less than one hour per every 30 hours (see alternative method however discussed in the next paragraph).    Employees who are exempt from overtime are not exempt from receiving this benefit, but their accrual rate can be set based on 40 hours per week (unless they work fewer hours per week than 40).

*Employees can begin taking sick leave after 90 days of employment which can be restricted to a total of 24 hours; in fact, employers can provide 24 hours of sick leave in a lump sum available at the beginning of each year instead of the "one hour per every 30 hours worked" rate.   This however may not make sense for a company with a large number of part-time employees.

Various third party sources indicated that employers were required to provide employees with a notice stating sick leave "days" that were available.   Not only would that be a very confusing way to to notify employees and difficult to calculate (based on an employee's part-time vs. full-time status for example), it is not what the law states.    The law states employees are to be provided with "the amount of paid sick leave available."  Logically, that would not be "days" but rather hours.

Accordingly in mid-July, Advanced Accounting 7i paycheck stubs were updated to include that information.

The new law will require potential changes to personnel policies and added administrative burdens.

For employees of employers who would otherwise be entitled to no time-off whatsoever, the new law should be helpful and might make some public policy sense.

But for employers already offering various vacation/sick/holiday plans and for those who may offer paid "leave" for time-off without trying to distinguish as to whether it is for a "sick" day or for vacation, personal day or compensatory leave, etc. does not in our opinion make much sense.  Employers should not be placed in the position of having to be watchdogs with respect to the reason an employee might take a day off, whether planned or unplanned.  If completely unscheduled, then some reasonable explanation should be provided by the employee and the unplanned absence tracked by the employer at its discretion, but the employer should not then be placed in the position of determining whether the employee was "really" sick or not, nor whether the sick leave was taken in accordance with the type of circumstances  that might qualify as sick leave under the act.  Mandatory plans that segregate different types of leave tend to lead to abuses.    If employers want to combine their sick and vacation and any other paid leave into one package to their employees, they should be allowed to do so.  The new law does not regulate nor require vacation or other types of paid leave.   For employers who already offer more enlightened and more generous benefit programs, the new law will simply lead to a certain amount of gamesmanship and the changing of certain words in policy manuals simply to comply with the law which in the end will not likely lead to any real benefit for their workers and will simply add to the employer's administrative costs.


Background information:

http://www.jdsupra.com/legalnews/at-last-amendments-to-ca-s-paid-sick-56103/

http://www.natlawreview.com/article/california-enacts-urgent-clarifications-to-california-paid-sick-leave-law

http://www.natlawreview.com/article/emergency-legislation-to-amend-california-s-paid-sick-leave-requirements-signed-gove

http://www.natlawreview.com/article/last-minute-amendments-to-california-s-sick-leave-law

http://www.lcwlegal.com/Questions-and-Answers-about-Californias-New-Paid-Sick-Leave-Law-AB-1522

State of California general link:

http://www.business.ca.gov/StartaBusiness/AdministeringEmployees/EmployeeBenefits.aspx

Pervasive 161 (license count status code)

A Pervasive (informally Btrieve, and now owned by Actian) status code 161 as intercepted and returned in an Advanced Accounting environment might appear as:

While most often it is in workgroup installations (i.e. using the Actian/Pervasive workgroup engine, even if installed to a "real" production server) when this error is generated, it can also occur in client-server versions since the 161 means (from Pervasive's status code documentation):

161: The maximum number of user count licenses has been reached 

You attempted to open another session when you were at the limit of your user count license. Either close a session or upgrade your user count. 

This status code is also returned after a trial or temporary license has expired. If all users receive this error and no one is able to access the database engine, then most likely you have been using a temporary license key and you must now apply a regular license key. Please contact your reseller or Pervasive Software to purchase a regular license. 

For more information about purchasing and installing additive user counts, refer to Getting Started With Pervasive PSQL. You can use Monitor to determine which users currently have connections to Pervasive PSQL. For information about Monitor, refer to Advanced Operations Guide. 

A 161 however can mean something quite different than the explanation above.   In a workgroup situation where the gateway locator has been appropriately set using the Pervasive/PSQL Gateway Locator Utility and the accounting or other software is moved to a different server or gateway PC, this can then lead to the user receiving a 161 until a new "server" gateway assignment is made.

The Gateway Locator Utility (which again, only applies to Actian/Pervasive workgroup configurations and not Actian/Pervasive client-server installations) is located under the utilities section (or can be searched for under PSQL Gateway Locator in Win 8 or just search for gateway).  

This utility should be used to assign the PC that "hosts" the software application and needs to point to the data folder where the Pervasive data files are stored.  In that folder, it will create a read only file name PVSW (an abbreviation for Pervasive Software) that is enclosed in tildes and that has an LOC extension, i.e.:  ~PVSW~.LOC.   Designating a PC as gateway then basically allows that designated PC to act more like a server would in a true client-server installation.   In other words, the Pervasive workgroup engine has some built-in client-server type capabilities.   The locator file can be removed manually only by first removing its read only attribute or by using the Gateway Locator Utility.  Removing it would solve the status code 161 but if the gateway locator is not set, then the first PC to open the data files becomes the gateway computer and that can lead to a number of problems (if for example that first PC is then shutdown after other PC's have accessed the data while it was still the "traffic cop").    We would therefore highly recommend always making a gateway assignment when using the Actian/Pervasive workgroup engines.

When migrating the data folder(s) of a system to a new computer, all of the data and related INI files (and usually also the software as well) are naturally going to be copied to that new computer.  But this then will pick-up the locator file.  Then, when trying to run the software even after deauthorizing and re-authorizing the license via the Pervasive License Administrator, an error 161 may result since it will be the old server/gateway with the deauthorized license that new server/gateway as well as the other workgroup engines will be looking for.   If the old server/gateway is off-line, instead of an error/status code 161, a status code 11 (invalid file name) or some other status code might be returned, and it may also take a long time before that error is returned while the database engine/Windows tries to find the old server name.

To resolve, a new gateway assignment needs to be made.   The new server name would be entered under "Enter the computer name of the gateway" and this would be run directly on that same computer:

Without re-booting, it should then be possible to run the application that accesses the data files without getting a status code 161 or some other error, both from the gateway PC as well as from other computers with an installed Pervasive workgroup engine (and assuming those other PC's have been pointed to the NEWSERVER name in the Pervasive license administrator which needs to be run on each PC in the workgroup).

Pervasive 11 status and Windows 10

In light of the release of Pervasive 12 (PSQL v12) late last year (see Actian releases Pervasive 12: first look), Actian has as of June 30, 2015 stopped selling new user copies of PSQL v11.

One day later, however, a v11 patch was issued on July 1, 2015 (Pervasive PSQL V11.30 install build 11.31.073 read me file).   Nothing in that patch appears to be of great importance for our user base.

While official support for v11 from Actian is planned to continue until July 1, 2016, Actian does not plan to support v11 on Windows 10, scheduled to be formally released by Microsoft very soon.   That timing is awkward.  It is nonetheless likely that v11 will work at the very least in connection with Windows 10 clients and in workgroup configurations.  

PSQL releases are normally compatible if within one major release of each other and typically do work on the "next" major Windows operating system release (but not always).   Whether v11 will also work on "Windows 10 server" remains to be seen, but a release of server technology based on Windows 10 is not yet imminent.

End users are always advised to wait until the first service pack (SP1) of a new operating system or database engine is released before migrating to that release, absent extenuating circumstances.