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.

Win 8: This app can't run on your PC

A somewhat strange and potentially misleading message can appear on the desktop of Windows 8 PC's:

This app can't run on your PC
(much less walk!)

Most users will probably know that "run" is the same as "execute" or "operate" or "invoke" or "launch."   So we do not quibble with that terminology per se.

Use of "app" is for those of us who have been developing software programs and software applications for decades is a little disconcerting, but is now the widely used lingo for anything and everything that runs on "smart technology" (whatever that is).  We would however never refer to our accounting software as an "app" no matter how hip that might be.  

But, besides use of the informal "can't" in the context of a relatively serious and disconcerting error message like this, our objection is that the problem could well relate to the fact that it is the operating system that cannot execute the program.  Thinking that it is the program's fault, or that of its software publisher, immediately leads to potentially errant conclusions, provoking the user to start reinstalling previously working programs in acts of futility, and making a bad problem worse.

If you receive a message like this the very first time you have ever tried to "run" a newly installed program under Windows 8, then, yes, it could relate to the fact that you have a 64-bit program trying to run under a 32-bit operating system version, or perhaps anti-virus software, user permissions or SmartScreen conspiring to block your program and not allow it to run, and potentially any number of other culprits.

But, if this message suddenly appears after programs have already been working (i.e. running), then in fact the problem could be the result of incomplete processing of Microsoft automatic updates (which is why we do NOT like to enable automatic updates).

The actual solution may be to return to a prior system restore point.   Or complete the unfinished updates.

This is all sounding eerily familiar.  Incomplete automatic update problems that lead to applications not being launchable is not a new problem.  We just have now a new unhelpful error message associated with that circumstance.

Another recent example of a problem caused by an automatic update that we wrote about:

Microsoft automatic security update causes font degradation

Problems associated with incomplete XP Pro updates were legendary.   The legend continues!

The staying power of a 25-year old application development system

While we extensively used the TAS 3.0 system released in the late 1980's by Business Tools, Inc.  (the second printing of the manual was in March 1989, and which reached its prime in about 1991) back in that same era, in recent years we have had little reason to use it except in rare situations involving converting data from very old systems.    TAS 3.0's short dates were not Y2K compliant and most TAS 3.0 users had migrated their applications forward to newer versions long before the year 2000 for many reasons besides just the date issue.

Yet some users persisted, especially those that were highly customized and also for some that did not want to deal with changes that the Business Tools TAS 4.0 development system brought to the picture in 1993.

Users of some of these older systems (who chose to fight rather than switch) survived the year 2000 by customizing their systems to use "long dates."   A conceptually simple change, it nonetheless required making dictionary changes to every file descriptor (similar to a "table"),  changing every temporary defined date field to a long date size, then going through every data input screen and report form layout to make placement changes in order to fit the long dates and replace them with the newly permanent field and temporary field changed sizes,  and recompiling every affected program.  In short, a significant amount of work.

Both TAS 3.0 and 4.0 (and also 5.0 and 5.1) were 16-bit programs, yet they continued to run on every operating system that Microsoft came out with.  They survived the Win 95 "scare."  Then Win 98. Then NT. They kept on running on XP Pro (in fact, XP Pro was and is an extremely stable and reliable environment for these systems) after another scare that 16-bit programs were not going to function.  And they still will run innately on 32-bit Windows 7 including some very old components.

Nonetheless and despite the fact that TAS (and products written in TAS including Advanced Accounting) have long since been migrated into graphical, 32-bit worlds, we have found ourselves in 2015 consulting with several users who have extensive customized systems running on modern operating systems:  one case using TAS 3.0 (see screen shot below), and another that until very recently was still using a system developed with TAS 4.0.   And we have recently we have had to make some programming changes into these environments.  With the 3.0 system, we are making bug fixes to customized source code involving EDT source files (but not using the built-in TAS 3.0 editor) on an ongoing basis,  and with the 4.0 system dealing with converting the older program code to the newer TAS Premier 7i.

TAS 3.0 components still running on a modern system on a multi-user basis (May 7, 2015)

Predecessor products were actually released long before in the early 1980's, so the TAS development system has it roots that now go back well over 30 years.

And, even in 2015, rarely a day goes by where we don't still use in some context the TAS Professional 5.1 development system (first released by Business Tools, Inc. in August of 1996).

The longevity of these systems is truly remarkable, and largely unprecedented in the computer software industry.

Printing to a file in Advanced Accounting

The form that a user interfaces with in choosing where a print job should be sent is what Microsoft Windows refers to as a print dialog box.  It is not really a box but a small modal form that loads on top of your current screen or form.

Print dialog boxes server a similar function in different programs, but they can differ greatly in appearance and functionality from one software program or system to another.

In Advanced Accounting (or programs written using the TAS Premier development platform), a print dialog box is triggered after a user selects something to print.  In Advanced Accounting this is done by either by (1) clicking on the printer icon in a report preview in the upper left hand corner of the screen, or (2) immediately after clicking on a Print button with the print preview unchecked.  Either of those two things causes a "print dialog box" form or screen to appear.

Normally at this point a user would simply click on OK to print if their default printer name appears in the upper drop down, and after making any other desired selections.

Instead  of printing to a printer, however,  an Advanced Accounting user can instead redirect the printing output to a file as below from the print dialog box:

What is critical above is to know exactly where you have saved the file so that if you are wanting to attach it to an e-mail, you will know where to look for it (or if directed to an XLS file type, where to open it from your spreadsheet program).




More information:

Windows Print Dialog Box

Pitfalls of online or live database backup

The proliferation of online, cloud-based backup systems ranging from the extensively advertised Carbonite to CrashPlan, Mozy, Backblaze, and many others has led to their widespread and sometimes indiscriminate use.  When it comes to the backup of critical business data (such as your accounting software or other in-house database-oriented software), these online or "live" approaches should solely be viewed as supplemental to other traditional approaches and not as a substitute for them.

Further it is essential for most users that database files be backed up on a scheduled, after hours basis and not while they are in active use, i.e. your data files should not be simply getting backed up constantly as they change (except for in the most high end, life and death environments).

Why?

Live, non-scheduled backup will likely ultimately create file locking problems (especially in multi-user, but also in standalone/singler-user, database environments) causing your software to not function properly leading then to delays and support costs to resolve.  And these types of problems have been widely reported with many different systems.

Examples:

An older report from 2011:
How Carbonite is Kryptonite for Sage ACT!

Live backups not recommended Atrex database  (2013)
Carbonite Online Backups

Reported with Peachtree (Btrieve/Pervasive) and QuickBooks (2014)
Carbonite Locking Files

We have also seen Btrieve/Pervasive status code 46 problems (in both Btrieve 6.15 and Pervasive 9 and above) in connection with supporting Advanced Accounting as well as TAS Premier/Professional custom systems created by the use particularly of Carbonite (and also by attempts to copy files in other ways while data files were in active use) on a non-scheduled basis.  A status code 46 ("access to file denied") leads to software not being able to write to the afflicted data file causing a loss of data that then has to be fixed manually.

A practical reason to not backup your database "live" relates to extreme slowdowns that can sometimes be created in a live environment.  The constant backup of your data will create delays that could create other types of record problems, and your system's overall performance will suffer.

Online backup system software makers typically offer a "Home" as well as "Business" version.  The more costly (and often much more awkward to use) business versions would at a minimum be required to backup a multi-user database on a real-time basis.   Even with the higher end versions in place, however, this would not ensure that a backup with full integrity was being achieved.   With Pervasive systems for example, a system would need to be placed in "continuous operations" mode to ensure a full backup with integrity regardless of the backup method used in situations where the database files might be changing during the course of the backup.   For most users, the best and easiest solution is to perform scheduled backups when the database system is not changing (and in the case of Pervasive systems, some users even "stop" the Pervasive service to ensure that is the case, which is not necessarily recommended, but is a possible approach).

Strong recommendation (applies to most users):  continue to use non-cloud based, traditional backup procedures, and consider your cloud-based backup as simply an additional, supplemental method.  Ideally backup files/systems after hours or when your system is not in use with respect to all backup approaches.  Make local ("on premises") backup copies that involve non-proprietary methods (such as the copy and ZIP method provided in Advanced Accounting or in backup software such as Second Copy).


24-7 environments:

In 24-7 situations, it is likely that you can still find a "low use" time for the cloud-based backup to run on a scheduled basis.

Or:

(1) Exclude the cloud-based backup from backing up the accounting software or business data folder(s)  so that those files are never backed up in real-time;

(2) Assign an office/administrative person to oversee and/or perform a traditional backup (using the backup feature of the software or a batch/script file or process provided by locally installed backup software such as Second Copy) at a regular daily time that is communicated to all staff members.  In most cases, a full local backup performed directly from the server or gateway PC directly of just a software's data files can be accomplished in well less than 15 minutes.   Rotate backup medium (e.g. flash drive) and do not use the same media (or backup folder) every time.  Periodically take one of the backups off-site and rotate those.

In Pervasive environments, place the data files into continuous ops mode (there are several ways to accomplish this and it can be automated) before any backups are initiated if the data files can potentially change while being backed up during the scheduled backup (applies regardless of backup method).