Addsum web site and general info

Postings here will focus mainly on Advanced Accounting software updates, tips, and related topics. They will also include general comments relating to troubleshooting PC/Windows/network problems and may also include reference to our other software products and projects including any of our various utilities, or to the TAS Premier programming language. We considered setting up separate blogs for different topics so that users/others could subscribe to topics mostly aligned with their interests, but decided that it would be better to keep things simple since some topics cross over into others. We would nonetheless welcome your feedback/input in this regard. Our web site URL is www.addsuminc.com. Call us at 800-648-6258 or 801-277-9240. We also maintain www.advancedaccounting.us so that older Business Tools users in particular have a greater chance to find us.

Follow

We highly recommend that accounting software users "follow" this blog via e-mail (enter your address and click on Submit below) or subscribe to a feed (see also below) as a way to keep current on the latest updates and accounting software news and information. You may also want to whitelist this e-mail address: noreply@blogger.com.

Follow by e-mail

Wednesday, October 10, 2018

Defer the Win 10 October 2018 update


The October 2018 Microsoft update (version 1809, dubbed Redstone 5) may cause some PC's to crash that do not have sufficient disk space.  Further, the update will likely not be ready for prime time deployment in business environments.

A couple of preliminary articles warning of potential issues:




While ensuring that your devices have plenty of available storage space going forward,  our advice as always for business users:  do not automatically update to the next major update (like the October 2018 update).  The 1809 update should be deferred.  

For Windows 10 Pro users, the simplest way to defer the update is to ensure that your Windows update settings under Advanced options are set to "Semi-Annual Channel" rather than "Semi-Annual Channel (Targeted)" as outlined below.


Windows Update Settings (Windows 10 Pro ver. 1803)





Advanced options under Windows Update Settings (Win 10 Pro ver. 1803)



You may also wish to pause updates for the next 30 days as a temporary stopgap measure (see example above), and more importantly, set the next feature update to 180 or even 365 days (also see example above) to allow time for issues in the October 2018 update to be resolved.

A few additional references with various additional approaches to consider in blocking this and other Windows 10 updates:




Thursday, August 23, 2018

Adv 8 autocomplete and SO notes display


To document just two of the many new features in the upcoming release of Advanced Accounting 8, this first video covers the new "autocomplete" feature when entering a product code in the enter/change sales order option:




There is a new setup option in SY-A-B that allows you to default the "autocomplete" check box either on or off.


A second video covers a new feature with respect to the display of notes attached to sales order line items:







A mentioned in the videos, for now we have added the autocomplete and note display feature in sales order entry only, but that may be expanded in the future to purchase orders and quotes (with respect to both features), and the autocomplete feature may be expanded to other inventory/product code lookups  as well as to other types of lookups. 


(Your browser will need the ability to support videos in MP4 format.  If you have any issues in playing these recordings, please let us know.)


Technical tidbits:

The autocomplete feature simulates to a fairly high degree what end users are experiencing when searching for information on-line.  The term  autosuggest is another way it is sometimes referred to as well as: look ahead, typeahead, search-as you-type, incremental search, instant search and others.

In the TAS Professional/Premier programming world which includes software products like Advanced Accounting,  we've long had this feature in lookup lists or grids where it has been referred to as "Fast Search."   In fact, in graphical versions of the TAS programming language, data grids have even included a property called FastSearchFld to reference a text field that is connected to the grid for the purposes of finding matching characters in that field as they are typed.

How this new autcomplete feature has been implemented, however, is from a single entry field that it not connected to a grid and so in that respect is new, and in fact was not realistically possible until our release of TAS Premier 7i release 11 which included enhancements to the TListBox object.

Users should hopefully understand how to select the desired item to "complete" the rest of the product/item code but it does have to work a little differently than an autocompletion in a web browser search:  the main difference is that you don't press the enter key nor use up/down arrow keys to select the available option in the list box beneath the product code entry field but instead use a pointing device to select/click the desired item: it then auto fills the product code field and moves the user automatically to the product description field (which is in turn then automatically populated with the product code's default description as established in the inventory module).


Adv 8 autocomplete




Advanced Accounting 8 main menu


























Tuesday, July 10, 2018

Short dates revisited

Short dates allow a software user to enter the year of a date by just indicating its last two digits.  It is convenient and saves time.

The problem with short dates is that they have to be interpreted as to which century they fall in, since they are after all only denoted with two digits.

This was the infamous Y2K problem when systems interpreting those last two digits after 1999 ("99") rolled over to 1900 ("00") instead of 2000 (also "00").   At some point, however, when whatever sliding century logic is in place and the end of its 100th year is reached, then a "Y2K" problem recurs.

For the most part, calamity does not ensue when the "next century" begins because software typically works on a relative basis.  The only real problem for accounting software for example was that once we were in 2000, the software (depending on the version) might not understand that "99" was older  then "00."  And while this would be a problem for the proper display of certain detailed data when crossing years, it in no way prevented the software from continuing to work within the relative space of the "current" year.  Hence, the world kept turning and life moved on.  The main problems that users had in 2000 who failed to move to a compliant system was when running a report that crossed into a prior year or where there was date logic that required comparision with pre-2000 dates (such as making an accounting entry into a prior period).  After a few years however most of those issues also became moot for those users who decided to live with that problem (although older historical data would still be out of chronological date sequence order).

The Windows operating system deals with the sliding century for short dates through regional settings where date formats can also be assigned. These settings also impact how short dates are interpreted.   XP Pro, Windows 7 and Windows 10 all default the century as 1930 to 2029 (which can be changed via the Control Panel under Clock, Language and Region in Windows 7, 8 and 10; under the Control Panel's Regional and Language section in XP Pro).

It is the application  itself typically that determines the sliding century and not the database. So for example with Btrieve/Pervasive data that we frequently work with, there was no Y2K type problem:  all date values were already being stored in a long date format.   It is instead the application that has to tell the database engine how to interpret the short date which is then saved into a long date (albeit potentially in the wrong century).

In the TAS programming world and the applications written in it (including Advanced Accounting), we wrote a memo in 1998 outlining short date issues in various versions of the products that then existed.   See Year 2000 issues and statement of year 2000 compliancy.    No version prior to 5.1 was technically compliant.   Versions 3.0 (and prior) were not at all compliant.  Version 5.0 was meant to be compliant but had some issues in the year 2000 itself.   

Programmers of highly customized TAS 3.0 systems (including highly customized versions of Advanced Accounting 3.0) typically chose not to move those systems forward into version 5.1 as the year 2000 approached, but instead took on the time consuming task of changing every defined short date field (both temporary variables and permanent field variables established via the data dictionary) from the short size (i.e. 8) to the long date size (i.e. 10).  Technically the data files did not require a restructure because the byte size of the field wasn't being changed, but typically the data was nonetheless restructured and every single use of those fields had to be identified and changed including on every screen and report form which required extensive manual repositioning of each and every date field since they now occupied two additional characters and also because of how the TAS 3.0 screen editor worked.  To migrate the TAS 3.0 code forward was admittedly potentially costly particularly for programmers who had not been working with the newer versions and were not familiar with them (version 3.0 did not even support functions), plus because it was relatively primitive code to start with, so some re-writing of code was inevitable; hence the long date approach was typically always chosen.  Converting code forward from version 4.0 (assuming it was written in that more modern language) is easier than 3.0.   But there was a better way than the above in terms of dealing with the Y2K issue even staying in the 3.0 version.

Version 5.1's sliding century, as outlined in our 1998 memo, was set by the prior publisher to be 1920 to 2019.   That century period however is now coming to a close and anyone running the  5.1 version will have to anticipate making some changes since January 1, 2020 will be here fairly soon, and since a 01/01/20 (mm-dd-yy) date will be saved by the 5.1 runtime engine as 01/01/1920 (mm-dd-yyyy) internally and not as 01/01/2020.    So the exact same issue is coming up for the 5.1 version that users of 3.0 versions were faced with in the 1998-1999 timeframe.  But does this mean that the same long date solution is required?   While that would be a potential solution, no, nor it is necessarily the optimum solution.

Before outlining an alternative solution for version 5.1 (besides migrating the application to a newer version altogether), it should be noted that the sliding century of the current version 7i (then TAS Professional 7 as first released by us) was expanded back in 2004 to be 1961 to 2060.  Users therefore of our 7 and 7i runtime versions should have no worries with respect to short dates.  Prior to that in TAS Professional 6 as released by Business Tools, the sliding century was defined as 1931 to 2030, so even a TAS Pro 6 user has nothing to worry about for now with respect to short dates.

Version 5.1 users do have another option that does not involve having to modify and adjust every single screen and report form nor change all of the temporary and permanent data variables in every program.  Instead, a one-line function can be called right after any field with a date value is being assigned and its century then adjusted programmatically.    As with the long date option, it does still require that programs with date values be recompiled and still requires some amount of work.   But it otherwise should involve far less time, end users will not notice any difference, there will be no repositioning issues, and users will still be able to enter short dates.

An example of the type of alternative function for 5.1 systems using short dates which we have called get_new_date() is outlined below.  We have placed this function in a 5.1 library file (Addsum.lib) in-house for use by systems we support that may need it (the semi-colon reflects the principal way of commenting a 5.1 program):


;Assume that the permanent field BKAR.INV.INVDTE 
;(the AR invoice date) has a value before saving 
;it to its corresponding data file

bkar.inv.invdte=get_new_date(bkar.inv.invdte)


And here is the function contained in the LIB file (the calling program needs to have a #LIB compiler directive referring to that file and since all of accounting software programs already have a compiler directive referring to the Addsum.lib file where we have placed it, it creates no additional work):

;Copyright 2018 Addsum Business Software, Inc.
:get_new_date

#proc
define old_date,ret_date type D size 8 local
define newyear_a type A size 4 local
define longdate_a,newdate_a type A size 10 local


func get_new_date old_date

   ;we are simplistically assuming that any date less than 2020

   ;needs to be adjusted - there are many different ways 
   ;this could be accomplished, this is just one example
   ;NOTE that more variables have been used than
   ;absolutely necessary to make it somewhat more understandable
   ;this routine could be used on data saved with older
   ;versions, changing 2020 to a date such as 1980
   ;and then when re-saved back to the data file, a date in 
   ;the wrong century would then be fixed
 

   ret_date=0
   if val(year(old_date))  < 2020
      longdate_a = dtoc(old_date)
      newyear_a = "20"+mid(longdate_a,7,2)
      newdate_a = mid(longdate_a,1,6)+newyear_a
      ret_date = ctod(mid(longdate_a,1,6)+str(newyear_a))
   endif
   ret ret_date

#endp
::get_new_date



Just as there were reasons for some users to stay with TAS 3.0 and even though 5.1 is also 16-bit (unlike newer versions), the same reason for staying with a highly customized TAS 5.1 system persists potentially into 2019 and beyond just as it did in 1999 with TAS 3.0.



Related information/posts:


Year 2000 issues and statement of year 2000 compliancy (1998)

From Books 2.04 to Advanced Accounting 7i  (2017)

Friday, June 29, 2018

TAS Premier 7i release 13 available

Release 13, our 2018 release in the TAS Premier 7i series, is now available.

The first release of TAS Premier 7i was in 2005.  Since then we have usually released an annual update related to cumulative improvements since the prior release.  This release then marks now some thirteen years in updates in the 7i series.  TAS Premier 7i was in turn based on our 2004 release of TAS Professional 7, building on prior versions released by Business Tools, Inc. including TAS Professional 6.



Releases 11, 12 and 13 taken together could have justified a new version altogether, i.e. a TAS Premier "8," but we have so far decided to simply continue to number these updates sequentially within the 7i series.

The next major release of Advanced Accounting will be based on this release.   Several of our users requiring some of the new features included in rel. 13 have already been using the underlying runtime engine for many months. Enhancements and other fixes and updates have been actively made since release 12, i.e. since mid-November 2017 to the present.

Release 12 made some major changes the full impact of which could not all be fully contemplated until it was more widely tested and deployed at end user sites.   Release 13 resolves the several remaining issues that we became aware of, and provides additional features to deal with the "topmost" behavior which we had to migrate towards in order to solve other problems and to keep up with operating system changes in rel. 12.

One of the issues that surfaced in rel. 12 that rel. 13 resolves relates to the folder lookup when printing to a file that would fall behind the printer dialog box.  Resolving that required a new API call and subsequent extended open file dialog support.  This led us to also incorporate separate but similar calls incorporated within GET_FILES() and GET_RUN_PRG()  so that they could work without having to adjust the Z-order of the calling form in advance (which could be problematic if multiple prior topmost forms were loaded).  These now also have extended file open dialog support. 
Print to file "save file as" dialog invoked by clicking on the folder/file lookup button
































GET_FILE() with 5th param set to true allowing it to be used as a "Save as" dialog




GET_RUN_PROG()

A new feature when printing a report and selecting print to file is that the file type last chosen in a runtime session is "remembered" and used as the default in the next request. This feature was responsive to a request by an accounting software user who would at month's end need to send multiple reports to an outside account via PDF and avoids having to scroll the file type drop down box with each and every print to file request.

Another new feature is a function which returns ISO format 8601 date-time values, as well as a function that allows the programmer to retrieve the total number of currently open files in a runtime instance.   Clarification of the number of files that can be opened in a runtime has been made, and the number of files expanded from 255 to 999.



Another new function calls external executables in a Windows "CreateProcess" thread and has the ability to wait before relinquishing control to the calling program, and it also attempt to make the executable that is called topmost.   It is sort of a cross between the existing EXEC command and the TShellExe object.




A significant amount of attention has been also given in this release to help file support.  The WHELP command (as well as F1 form key presses) now attempts to load CHM (Microsoft's proprietary compiled HTML format) files topmost.  Because of the increasing uselessness of the CHM format, we have brought back HLP support for newer operating systems.  The HLP format is actually in many ways more feature-rich than CHM and does not suffer from the blocking problems that have evolved with that format even though it is still the Microsoft standard.  













Wednesday, June 27, 2018

Microsoft fixes beleaguered Win 10 1803 update

Yesterday (on June 26, 2018), Microsoft released a promised update to fix problems introduced by the now infamous Windows 10 1803 update:

https://support.microsoft.com/en-nz/help/4284848/windows-10-update-kb4284848

entitled:

June 26, 2018—KB4284848 (OS Build 17134.137) Applies to: Windows 10, version 1803

All of the items refer to 'addressing an issue' including this item:

Addresses an issue where some users may receive an error when accessing files or running programs from a shared folder using the SMBv1 protocol. The error is "An invalid argument was supplied."

The SMB* issue created by the 1803 update was not returning the error quoted that the end user  could actually see to our knowledge.   And it seems to have impacted much more than the fix would allude to. 

*SMB stands for "server message block" and is a protocol used by Windows systems to share information over the same internal network.  As newer operating systems have evolved, different SMB protocols have as well.   Newer operating systems have to be able to switch to a lower level SMB version to communicate with older systems.  Major SMB versions are sometimes referred to as v1, v2 and v3:   SMBv1 (Windows 2000, XP Pro, Server 2003), SMBv2 (Vista, Windows 7 and  Server 2008 ), and SMBv3 (Windows 8, Server 2012, Windows 10, Server 2016).   SMBv1 referred to also sometimes as SMB1 is said to be the least secure, but that may or may not be much of an issue on every business network.

More information

Background:

The Win 10 1803 update, known also as the Windows 10 April 2018 update (which started to be rolled out to end users by the first week of May), was actually an entirely new release of Windows 10 involving mostly new features (but with few security features of critical importance; therefore there was no need to rush to install it).   Computer users generally started to begin reporting problems almost immediately following this update; other users who are just barely now starting to install this update have also reported problems immediately following installation of the update.

Some initial reaction and reports about this update:

https://www.computerworld.com/article/3232632/microsoft-windows/how-to-block-windows-10-april-2018-update-from-installing.html


https://pureinfotech.com/avoid-problems-installing-windows-10-april-2018-update-1803/

https://www.techrepublic.com/article/how-to-resolve-network-problems-caused-by-the-windows-10-april-2018-update/

https://www.windowscentral.com/windows-10-april-2018-update-biggest-user-problems-and-complaints


https://blog.mertech.com/windows-10-version-1803-breaks-some-shared-folder-applications

Our first report of an issue with our users was during the third week of May.  This user had a Windows 10 client connected to an XP Pro PC which was hosting the software.  The user received various Pervasive (Btrieve) status codes including 94 and 3103 on the Win 10 client following its 1803 update. The Pervasive version in use was 9.71 (running a client-server version with the server version running on XP Pro, not officially supported, but it works just as client-server also works using Windows 7 Pro as the server rather than a "true' server).   Yes, a very old version involving an operating system without ongoing updates (which means it is going to work the same every day), but it was working without any problems until update 1803; PSQL version 9.x can in fact be configured to run on every operating system released by MS so far, as can Btrieve 6.15). 
Uninstalling update 1803,  the user's system started to work again as expected.

At first the indication was that the SMB issue would only impact users running older operating systems (the version of the database in use was not the issue) and only when running over a network (which is how most businesses function!).

The most prudent action for the few users that initially started to experience this problem was to rollback the 1803 update, something that many software companies and consultants recommended.  (One source indicated that it would be costly to rollback this patch:  not true.)

Fairly quickly Microsoft acknowledged the SMB issue and indicated it would come out with an update to resolve.

Just this week however an end user of ours suddenly had three Win 10 clients over the course of several days receive Pervasive (in this case PSQL version 12) status code 3012 after the 1803 update was installed yet these PC's were connected to Server 2008 which normally natively supports SMB2 protocol.  So on balance, this was a modern system.   On two PC's, the update was rolled back which resolved the problem.  On a third PC however more than ten days had past since the 1803 had installed itself.  Following a major build, while Windows retains the files needed to uninstall the new build initially, after just ten days Windows automatically deletes those files and you cannot rollback to a prior version without reinstalling the operating system!  This user however was able to solve the problem without having to replace the computer or reinstall the operating system by installing the June 26, 2018 patch referred to at the beginning of this blog post. 

Comments/recommendations:

As we have stated again and again, automatic updates are dangerous.

As with changing to any new version of Windows, users should especially wait and postpone major updates; some experts were suggesting to wait until at least August of this year to deploy the Win 10 1803. 

Unless you want to be a guinea pig.


Running programs "across networks" is exactly how programs were designed to run.  That is how executables are normally run with respect to multi-user applications in on-premises, multi-user environments.

It is simple to uninstall and "HIDE" and postpone a Win 10 update using MS provided tools (it if is done quickly).

Users do NOT have to accept every update that is thrown at them nor should they be forced to do so.

Ten days is a ridiculously short period of time to disallow a rollback.  In the example cited above, the end user had been out of town. That user should therefore be penalized?

Policies of forced software updates and ten day time frames where files are automatically deleted are tactics that business and individual users should rebel against in the strongest possible way.

Further and unfortunately, any user that put themselves into a position of automatically installing every single update that comes out more or less immediately is putting themselves into a level of higher support costs and should expect that things may not work the same from one week to the next, and that they **will** have business interruptions as a result. While most security and related computer technology sources stress "keeping your system up to date" to prevent malware and similar attacks, in fact, it is not prudent to put your PC system on the line at the whim of every update that comes out more or less the second it becomes available.  That is not prudent nor wise.  In most cases except for the highest priority security updates, prudence dictates waiting not just weeks but also often months before installing the "latest" updates.  And it is best do be present and monitor those updates while they are being installed to ensure they completely finish successfully.


No doubt the time is coming when our "smart" cars and "smart" houses fail to function the next day following an automatic update.  And then maybe users will revolt against this constant push of untested updates creating constant business interruption and chaos in their lives, as that is exactly what these "updates" often amount to.   

And this is why many savvy users don't put their accounting systems "on-line" at all and accordingly their support costs are vastly less and experience reduced levels of frustration.  And these are points that many in the industry seem to fail to understand. 

It is also noteworthy that users happily running Windows 7 in any configuration weren't impacted by this update.


 

Wednesday, May 30, 2018

Use relative paths for e-mail attachments

When an attachment (such as a sales invoice, statement, quote, or purchase order) has to be automatically created for inclusion with an e-mail to be sent from a software program, the attachment normally has to be saved somewhere before it can be attached to the e-mail.  Once the e-mail is sent, the attachment can then be deleted (or optionally retained).

In Advanced Accounting, there is a setting for the attachment path for this purpose.  In establishing this path, sometimes users create a path that is only accessible by a single computer.  If the same path, whether locally or across the network, doesn't exist from the point of view of other client PC's on the network, users working from those PC's will not be able to send e-mails with automatically created attachments.

While you could use a local drive letter with a subdirectory path that exists on every PC, that could still create issues when a new PC is later added or replaced on the network and the same path then doesn't exist from the perspective of that PC, plus it means that attachment files (typically PDF's) could be littered across the system rather than exist centralized (if retained).   Or the local path could be different for every user on the network as well (might be important only if the e-mails are being retained rather than deleted).  One reason to create a local path would be to protect confidential attachments (created in PDF format).  But most accounting software documents that are commonly e-mailed are not so highly confidential that they can't be placed on a shared network drive (and for those documents, a subfolder with limited read/write access could be created), and they are deleted after being sent, there is really little to no possible exposure of confidential information.

So for ease of maintenance and to most easily allow all users to be able to send e-mails with attachments, we would recommend using a simple relative path for all users (based on how different file attachments are named automatically when created by the software, there is also little chance of a file conflict between two different users sending e-mails at the same time; to date in fact we've never seen that happen).  Or depending on e-mail settings selected, a different relative path could be used for each user logon if you are retaining e-mails sent (but is normally not necessary).

A relative path is simply a path that uses your current directory path and that causes the operating system to navigate to that path based on that directory.  In comparison, an absolute path specifies the entire path to reach that folder starting with either a drive letter and then one or more subdirectory names (folders) to reach the ultimate path.

For example, assume the program sending e-mail is installed in an upper level folder called Somemainfolder.The path C:\Somemainfolder\TempFiles would be an example of an absolute path where temporary files might be stored.  A UNC path such as \\SomeServerName\SomemainFolder\TempFiles would be another example of an absolute path.  If the server name changes later, then the UNC path would no longer be available.  If the C: drive path is used, attachments will only be able to be created on PC's that have that exact same path on their local drive.  If a drive-mapped absolute path such as F:\Somemainfolder\TempFiles is used, then that has the chance of working as long as F: always remains available in the event of a server migration.   

But a relative path is even simpler.  In the example above it would be:

TempFiles\

(It is important that there is only an ending backslash.)

So regardless of how the program is launched nor where the software is moved later, as long as it starts with the working folder Somemainfolder, the TempFiles\ subfolder will be available (and assuming end users have read-write access rights to subfolders under the main folder which typically they do).

We like to place the temporarily created files used for e-mail attachments in a folder under the company data folder within the Advanced Accounting subdirectory structure.  Since Advanced Accounting has a separate subfolder for each company's data set, and since the main company data is usually in a folder called MainData, then the relative path might instead be:

MainData\TempFiles\

When the e-mail is generated, it will be able to then create the file in that path, and attach it to the e-mail form.

While you can use spaces in folder names, we would recommend using short, simple folder names without spaces.

In the case of Advanced Accounting, the path setting is created in either one or two places:

(1)  If you are using a global setting (same e-mail setting for all users which is required if logon codes are not being used) then via SY-N E-mail Setup and with Global checked, click on OK;

(2)  If in SY-N you have selected Per User Logon, then settings per user are established via SY-C-A where you would highlight the desired user logon, click on Edit and then click on the E-mail Settings button.  Settings established based on user logons is recommended.

In the event of either approach selected, in the middle of the e-mail options setup screen, the attachment setting can be established:


E-mail attachment setting using a relative path



If the desired path does not exist, when you click on the Save button you will be asked:

The attachment path entered does not exist. Would you like to create it?

Simply answer "Yes"  and the path will be created for that setting.   Once created, that same relative path can be used for other user settings as well.




Monday, April 30, 2018

Utah up next plus new Oregon transit tax

Utah changes its income tax withholding formula effective May 1, 2018:

Utah is the latest state to make income tax withholding changes as a result of the ongoing fallout relating to federal income tax legislation passed late last year.  These changes go into effect on May 1, 2018.   While these changes should be implemented by sometime in May in terms of employer withholding, Utah reduced its effective tax rate slightly (from 5% to 4.95%) retroactively effective to the first of the year.  Corporate income tax rates were similarly decreased.  

Just looking at the percentage change however does not tell the whole story, nor does the summary of changes provided by the Utah State Tax Commission fully outline what has changed.  Buried withinin the updated publication 14 document:

  • No longer is there an allowance of $125 multipled by withholding allowances (see further comment below)
  • Base allowances have been increased  from $250/single and $375/married  to $360/single and 720/married
  • Exempt wages have been changed from $12,000/single and $18,000/married to $7,128/single and 14,256/married.  

Utah does not have its own W-4 form and has used the IRS W-4 form.  The IRS W-4 form however still asks for the number of allowances.  In Advanced Accounting there has always been a separate entry field for state allowances (under the label St) in addition to federal allowances (plus the ability to add an optional additional amount for either as well).  But in light of this change, any number entered in the state allowances field will now be moot because the Utah formula no longer takes those allowances into account in computing state income tax withholding; and the new tables published similarly show computed tax amounts solely for "Single" and "Married" with no allowances. This is a significant departure from the past.  So while an employee could claim five (5) allowances which still (at least for now) makes a tremendous difference in the federal income tax withholding calculation, as of May 1 it makes no difference at all in the Utah state income tax withholding calculation.

Curiously, the there is no also difference in the single and married withholding amounts once a certain wage amount has been attained (at about $1,338/weekly; $5,800/monthly).

The 1.3% multiplier has remains unchanged. 

Overall these are changes with unintuitive consequences.  For some employees these changes may mean relatively little.  In our quick testing of the old rates versus the new, the difference that all of these changes make seems to be on balance quite small, sometimes slightly more, sometimes less.   It all depends on income levels as well as allowances that were previously being claimed.  Employees with high allowance numbers may be surprised by how much their Utah state income tax increases.  Our testing shows that an employee claiming a single status with formerly five (5) federal/state allowances earning $3,000 (taxable) per month will see a monthly increase of $46.00; and a married taxpayer with the same allowances and earnings will see a monthly increase of $26.00.  For a single or married employee with the same earnings but no allowances, the withholding amount is essentially the same for single status employees both before and after the May 1 change, but for an employee that is married, a decrease of $26.00/mo. can be anticipated.

There are no "UT" tax tables in Advanced Accounting's PR-K (Maintain Tax Tables) since, as with several states, the withholding logic is embedded in the program option (PR-B) that performs the calculations, because the logic doesn't follow a traditional tax table approach.   So Advanced Accounting users with Utah employees will need to obtain a program update from us to implement this change (this change has been made and an update is available; it is the first change that we've had to make to the Utah income tax withholding logic in over ten years).

Another Utah change relates to the filing of quarterly returns which now must be made on-line which can be completed by establishing a TAP account (see link below) and submitting the information via an on-line form

Utah has for several years also required the electronic filing of W-2 forms for all employers (which is unusual compared to the rest of the country, although the trend is clearly in the direction of lowered thresholds; it is in fact somewhat surprising the minimum requirements hasn't decreased on the federal level but increasingly employers want to e-file for security and other reasons).

More information:

Utah Publication 14 updated May 1, 2018
Utah State Tax Commission: Utah withholding taxes
Utah's Taxpayer Access Point (TAP)
IRS 2018 W-4 form


Oregon has a new transit tax that employers will have to start withholding in July

Effective July 1, 2018, Oregon employees (including the wages of nonresidents that perform services in Oregon) will be subject to a 0.1% tax.  This is a tax solely paid by employees but that employers are required to withhold and remit on a quarterly basis (and no matter how small that remittance might be).   While paid to the Oregon Department of Revenue (ODOR), payment of the tax requires two new quarterly forms (a summary sheet accompanied by a detail form similar to a state unemployment tax wage list) as well as an annual reconciliation form.

Advanced Accounting users should be able to easily accommodate this new requirement but should plan now as to which user-defined deduction to use for this purpose (in part because it is best to use the same user-defined deduction for the same purpose throughout a given calendar year).  The steps to set this up include:

(1)  Establish a new GL liability (type L) account in SY-E (Create/Chg G/L Accounts) in a range proximate existing liability accounts for payroll withholding accounts for FICA/Medicare, FIT, SIT, SUTA, etc.

(2)  Decide whether to use your existing vendor code for the ODOR which should be fine as long as the remitted tax is paid separately from other taxes, or establish a new one to be used solely for remittance of the tax.

(3)  In SY-D (Enter/Chg PR/GL Interface), decide which of the six numbered deductions* to use for this withholding tax, enter a short description such as TRANSIT TAX next to that dedcction, and then enter the liability account that you created in step 1 above.  Then:

  • Under Deduct Amounts enter the rate of:   0.0010 
  • This is NOT a pre-tax deduction so answer the next question accordingly.
  • Choose option 6 - % of Gross pay for the post-tax calculation method (Calc how will display 6). 
  • Enter the vendor code (press F2 or click on F2 Display Vendors) that you decided to use in step 2 above.


Press F10 or click on the F10 Save button to save.   Repeat for each of your active payroll divisions.

*While we would normally recommend use of one of the six user-defined deductions, if all of those are in active use, there is another albeit less desirable option.  In addition to the six user-defined deductions, Advanced Accounting has at least four other possibilities.  Two of those however do not provide any automatic calculation capabilies ("Misc" and "Special") so they would also not be desirable. Workers compensation employee withholding fields could be used but each employee record would have to contain the appropriate rate and that would also obviate the possibility of using those fields for their intended WC purpose. However, an option that could work would be the SDI deduction.  SDI is normally only used in states that have a state disability insurance requirement (and there are very few of those, only five that we are aware of - one of which is California - and Oregon is not one of those states).  In Advanced Accounting, we have also co-opted SDI to handle, in part, COIT in Indiana but it could be used elsewhere for other types of employee only withholding involving a flat rate applied to gross wages (to handle certain city or municipality taxes, for example).

Confusingly an SDI "expense" column exists in the Advanced Accounting SY-D setup that goes back to very old versions of the software which implies that some expense account would be ultimately debited (which would not be appropriate for the transit tax withholding)  when processing payroll checks, but it appears that was something put into place for potential future implementation by the original developer and not actually ever implemented, so only the GL liability code comes into play. 

When using SDI for an additional deduction, some unobvious issues must be dealt with.   SDI deductions have to be "enabled" at the employee level (PR-A).  To use SDI as an additional deduction of some kind, you would have to change the "SDI" flag for each employee in PR-A from the default of "Y" (which normally means exempt from SDI) to "N."

Then you would still set up a new liability code (as in step 1 above), decide on which vendor to code use (as in step 2) and in SY-D connect the new liability code in the liability GL code column, and in order to get access to the vendor code currently the program requires that some valid GL expense code be entered (since it is never used, we will change the way this behaves in future releases).

Next, for each division you would in the PgDn Rates section of SY-D enter the rate next to State Disability, but amounts there are input as percentages, so instead of 0.001 you would need to enter 0.10  (to indicate 0.1%) and under the limit input 999999 so that the Enter Pay Info option (PR-B) will attempt to compute the withholding amount on any/all wages (since in the case of this transit tax, there is no wage limit) and then save each of payroll divisions.

"SDI" amounts withheld can also be included in box 14 of W-2 forms and e-filings if desired (to communicate to each employee how much in transit taxes were withheld for the year).

More information:

Oregon new statewide transit tax
Oregon Quarterly Statewide Transit Tax Withholding Return
Statewide Transit Tax Employee Detail Report (quarterly form, accompanies the above form)