Serving accounting software users worldwide for 25 years

Q.W. Page Associates

NewViews™ • 2.2

Version History

Current version             Click Here To DOWNLOAD

Released - September 3, 2009

-->

NewViews 2.15

Released - July 27, 2009

This is a version change, not just a service pack. The service pack number is reset to zero. After installing this version, each workstation, server, or application database will be automatically processed the first time you open it. You will be asked for confirmation before any processing is performed, and as a precaution, a backup is made automatically before each conversion.

IMPORTANT NOTICE

This version will convert application databases (i.e. sets of books).
Basic performance testing suggests it will take approximately 2 to 6 hours per gigabyte.

If you have a time critical schedule (e.g. a payroll to process) allot time for conversion, or perform the time critical tasks in version 2.14 prior to conversion.

Therefore you should arrange to install version 2.15 and convert your books/databases when you have enough time available for that purpose, say overnight or on a weekend.

Converting to version 2.15

Version 2.15 contains two major changes. First, summary postings have been replaced by an internal mechanism that we refer to as account histories. Second, you can now turn on/off account postings indexes for individual accounts and turn on/off journal transactions indexes for individual journals. These are described in more detail below.

When you convert a database, the conversion will turn off the postings collections for all accounts except the root account and posting accounts. It is similar for journals. Journal transactions collections are turned off for all journals except leaf journals and the root journal. You can turn the collections back on for any or all accounts and journals after the conversion.

These changes lead to significant savings of disk space and performance improvements. However, conversion to 2.15 will also likely take significantly longer than previous version changes. This is especially true if the database being converted was configured to use summary postings, because the conversion must eliminate and replace the summary postings.

What's New

  • Summary postings have been eliminated.

    Summary postings were introduced to reduce the amount of disk space consumed by larger accounting databases. They accomplished this goal but they had several limitations and increased complexity. Account histories provide the same functionality, and more, in a simpler way. Below, we outline differences between summary postings and account histories.
    • Summary postings were configured by setting dates on the Odds and Ends document.

      From version 2.15 onward, this is no longer necessary. The date ranges for summary postings resolutions, i.e. yearly, quarterly, 13 period, monthly, none, and so on, had to be set on the Odds and Ends document. Understanding summary postings and setting these dates appropriately placed a burden on the user. Starting with version 2.15, all fields controlling summary posting dates have been removed from the Odds and Ends document. This leaves nothing at all on the Odds and Ends document but it continues to exist, reserved for future use.

      Unlike summary postings, account histories are behind the scenes. They are automatic, always available, and require no user action such as configuration.
    • Account histories provide daily resolution.

      Summary postings provided different resolutions as configured for different ranges on the Odds and Ends document. For example you might have configured a database for yearly resolution up to the year 2000, monthly from 2000 to 2006, and full (daily) resolution from 2007 onward. The blue tables of accounts and account history views could only report according to the resolution configured for any date range. This places a burden on the user, i.e. providing a reasonable configuration and then knowing what is available when reporting.

      From version 2.15 onward, daily resolution is always available for blue account tables and account histories. There are no exceptions. There are no configuration requirements.
    • Summary postings summarized all account ledgers.

      Summary postings appeared in account ledgers of all accounts. Each such posting summarized all postings for a period such as a month or year. The postings contributing to this summarized period were available in a collection of postings "under" the summary posting, but not on the account ledger itself. Generally, this led to some confusion and a return to having all postings available on the ledger became a goal that led to the replacement of summary postings.

      From version 2.15 on, all postings are again displayed on any account for which the indexes have been enabled.
  • Account postings indexes can be turned on/off.
  • Journal transactions indexes can be turned on/off.
  • Sample Books
    2.09
    No summary postings
    2.10 to 2.14
    Summary postings
    New 2.15
    Daily history
    Size in MB
    1037
    682
    399
    Report resolution
    daily resolution
    limited
    daily resolution
    Account postings
    full resolution
    summarized
    full resolution
    Total Account postings
    full resolution
    summarized
    full resolution
    or disabled
    nvCHECK time - hh:mm
    23:39
    14:35
    5:28
    nvREORG time - hh:mm
    29:39
    15:23
    8:29
    Data entry speed
    slow
    medium
    fast
    Re Total accounts
    slow
    medium
    very fast


  • Enforce unique transaction Ref #s

    A common request is for the ability to prevent a data-entry operator from adding the same vendor/supplier invoice twice (which is then accidentally paid twice).

    This release includes the ability to enforce unique transaction Ref #s, per journal, and per account. The per account capability includes control for uniqueness on the debit view, credit view, or both (i.e. the ledger view). The per journal case is just a simple yes/no.

  • Terminal Server User Serial Numbers

    A new User serial number for NewViews can be purchased that controls multiple logins with the same workstation serial number. This is not a concurrent licensing model.

    Although many users are running NewViews in a Terminal Server environment. We do not recommend running NewViews workstations on "thin clients".

    However with an powerful machine loaded with multiple gigabytes or RAM, it is feasible. Although current Terminal Server installations are restricted to 2 connections to the same NV2 server, this new User serial number allows more than 2 connections with the same workstation serial number.

  • New Columns Account PayCodes Script

    Version 2.15 now includes a qw_script to create paycode columns on blue tables. This gives a birds eye view of common paycode settings on payroll accounts. The fields added to the blue table are;
    • check description
    • type
    • quantity
    • rate
    • percent
    • percent base
    • frequency
    • annual limit
    The script should only be run from a blue table of payroll accounts.

    For example, when using Canadian payroll create a copy of the setup view of the /OBJECT/NEWVIEWS/ACCOUNT/PAYROLL/CANADA, or on a Payroll's Employee List, Account Setup.

    When using US payroll create a copy of the setup view of the /OBJECT/NEWVIEWS/ACCOUNT/PAYROLL/USA, or on a Payroll's Employee List, Account Setup.

    See, Managing Column Layouts for details on creating new blue table views.

    On the newly created layout, delete any unwanted columns. For example "Normal Rep", "Active", "Ledger Indexed", "Unique Ref #s" can be deleted to make the new table more manageable.

    Run the qw_script found in c:/nv/nv2.exe/object/newviews/payroll/new_column_account_paycodes_basic.qw_script. The script will add eight (8) new columns to the blue payroll account table. They are the common paycode fields from the Credit and Debit payroll accounts.

    With the paycode columns added to the /OBJECT/NEWVIEWS/ACCOUNT/PAYROLL table, you may sort the table by description. When sorted by description, all .REG accounts will line up and you will see all pay rates for all employees with .REG accounts in a block.

    Fill Column can be used to update values in the columns in a block or in discontiguous (fragmented) blocks.

Behavior Changes

  • Views of tables now store more information.

    When you select a view of a table, a list of column names and column definitions is activated, and the information displayed changes. Along the same vein, when you issue the Windows>Define Columns command (or shortcut ), and press the New button, the current list of columns names and definitions is copied to provide a starting point for future edit.

    However, additional information about your current view was not saved, at least not for activation as you switch from view to view. For example, the number of title columns set (to freeze the leftmost columns and stop them from scrolling out of the window).

    This version saves additional information about each view, to make switching from view to view feel more familiar.

    Note: this was confusing/annoying with account Multiple Period Analysis. The settings window behaved like a "tool", showing you the last settings you used (applied) to a blue table of accounts, not the settings for the columns you are currently looking at. This version will track and display the settings for the current view.

  • Copy/Paste table columns can now append as well as replace.

    The old Window>Paste Table Columns command deleted all existing columns before pasting the new ones from the clipboard. This approach eliminated the ability to create many varieties of column arrangements.

    The new version of this command will prompt you to replace the existing columns, or just append the new ones.

  • Over-sensitive mouse block select.

    Several users reported a problem, also noticed by Q.W. Page staff, that blocks were being marked by accident. The reasons for this are technical, and involve processor speed, mouse sensitivity settings, and a bug/problem in Window's event queue management. This release requires that you hold down the [Ctrl] while using the mouse to mark discontiguous blocks.

    If you prefer the default behaviour of version 2.14, you can add a command line argument. Booting NewViews from a command prompt looks something like:

    C:\NV>nv2 -file workstation.nv2

    A command line argument "-mouse_motion_select_no_control_key" will enable mouse motion select, without the [Ctrl] key held down while the mouse is moving. The new command line to boot NewViews looks something like:

    C:\NV>nv2 -mouse_motion_select_no_control_key -file workstation.nv2

  • Automatic window tab select for journals and transactions.

    When you activate a "branch" journal, the Journals window tab is automatically selected. Also, when you activate a "leaf" journal, the Transactions window tab is automatically selected.

    This behavior is now the same as Report windows. The idea is that you activate a branch journal to see the list of sub-journals, and you activate a leaf journal to see transactions. Of course you can still manually switch around to see, for example, all the transactions "below" a branch journal by selecting the Transactions window tab.

  • Automatic "rollback" of partial work completed before an error occurs.

    Some operations could encounter an error part way through, but would leave the work completed up to that point intact. (e.g. Tools>Pay Account for vendors could reconcile several invoices being paid, and possibly also create boomerang transactions for the remainders of partially paid invoices, only to fail posting the payment because of a date outside the user's allowed transaction date range, or a duplicate Ref #, etc.).

    This release will "rollback" partial work completed in support of the task at hand, if the ultimate objective of the task can't be fulfilled without error.

  • The Tools>Fill Column command will now pause on an error, and prompt you to select one of three behavior options.
    • A Yes button to skip the offending item and continue.
    • A Yes to All button to skip the offending item, and any others encountered, changing only the items that can be changed.
    • A Cancel button to terminate the operation, leaving any changes up to that point intact.
  • Note * Version 2.15 consumes more memory than 2.14.

    If you are using any of the -memory_record_scale command line options we recommend that you subtract 1 from the value used. For example, if you are using -memory_record_scale 4, we recommend you set it to -memory_record_scale 3.

Problem / Bug Fixes

  • The Tools>Create Transactions>Post Dated and Tools>Create Transactions>Duplicate commands could not process Additional Info.

    The Tools>Create Transactions>Post Dated and Tools>Create Transactions>Duplicate commands worked most of the time but could fail when information was found in the Additional Info view of the transaction about to be copied.

    This release fixes the problem.

  • Script evaluate selection window repositions and resizes properly.

    The selection window used for running scripts will be the same size and position as you last left it, instead of always positioning in the same place at the same size.

  • Audit details were improperly hidden from users with valid access.

    Users granted access to their own User object couldn't see the details their own audit trail items. Also, users configured with access to the Data Audit View couldn't see the details of audit trail items (e.g. accounts, transactions, etc.) The security system was being too aggressive, and this release fixes the problem.

  • Performance improvement for the Windows>Define Columns command (or shortcut [F11]) options window.

    The Define Columns window was sluggish (very in some circumstances), and prone to crash when clicked on before it fully refreshed and "settled down". This version should improve performance and correct the bug.

  • Window>Default Setup commands restricted.

    This command was mistakenly permitted in several places that it shouldn't be (e.g. "pop-up" style windows, like pick boxes).

  • Window>Define Columns commands restricted.

    This command was mistakenly permitted in several places that it shouldn't be (e.g. "pop-up" style windows, like pick boxes).

  • Default time-of-day values are taken from the server computer when running multi-user.

    In some cases default time-of-day values were taken from the server, and in other cases they were taken from the workstation (e.g. [F3] key edit assist on a timecard). This didn't matter when running single-user but for multi-user all time-of-day values are now taken from the server computer.

  • Journals with two or more tags did not auto-increment the next Ref# properly.

    This release fixes the problem.

  • The Block>Paste accounts command had some errors when pasting into a sub-foldered database.

    This release fixes the problem.

  • Excel "disappears" after printing.

    If Excel was running and a NewViews print templated document operation occurred, Excel disappeared from the task bar (and the running applications list). This release fixes the problem.

  • Tools>Pay Withholdings displays 0.00 for amount remitted under multi-user access.

    After paying payroll withholdings using the Tools>Pay Withholdings command, a notify window entitled Remittance Recorded is displayed. This window in turn displays the amount remitted. However, under multi-user access this amount was always displayed incorrectly as 0.00. This release fixes the problem.

  • Print>Account Ledgers crashes on incomplete transactions.

    In some cases, printing account ledgers with transactions that are "incomplete" caused NewViews to crash (e.g. a sales invoice, with distribution items posted to sales accounts (with all amounts equal to 0.00), but no customer specified) This release fixes the problem.

<Back to Top>

NewViews 2.15 - Service Pack 3

Released - September 3, 2009

Problem / Bug Fixes

  • Enabling a total account's postings indexes could fail.

    Starting with version 2.15 you can now turn account postings indexes on/off. However these operations could be painfully slow for databases that contain semiloops in their account totaling structure. The best solution to this problem is to eliminate the semiloops. However, since a significant number of existing databases continue to contain semiloops, we attempted to speed up the enable operation in release 2.15.2. However there was a bug in the change such that although the work is done, the result is never displayed. This release fixes the problem.

    If you have a database with semiloops and you experienced this problem, then it would be a very good idea to run nvreorganize on the database. Note that in version 2.15, since many account posting and journal transaction indexes are disabled, nvreorganize runs much faster.

  • Adding transactions to ledgers caused account history errors.

    The introduction of account histories to replace the old summary posting mechanism was a large internal change and some subtle bugs and omissions have turned up (none that can permanently damage a database). Adding transactions to account ledgers revealed an omission in the updating of account histories. As a result, amounts may not be correct on (blue) account tables. Also, from time to time NewViews may report a bug that it encountered invalid amounts in account history records. This release fixes the problem.

    If you have been adding transactions directly to (green) account ledgers (as opposed to adding them to (pink) journals), then you should rebuild the account histories. To do this, run nvcheck, select the database, and issue the Repair>Rebuild account history menu command. Note that although account histories are also rebuilt as part of nvreorganize, a full reorganize is not necessary in this case and rebuilding just the account histories is much faster.

  • Print account ledgers for total accounts reported an incorrect opening balance.

    This release fixes the problem. If you turned some total account ledger indexes on as a workaround, you can now turn them off.

<Back to Top>

NewViews 2.15 - Service Pack 2

Released - August 28, 2009

Problem / Bug Fixes

  • Retotaling accounts didn't work.

    When retotaling an account, due to a bug, the account was not actually re-totaled. This error was introduced in the previous release, i.e. 2.15.1, and should not be a problem if no re-totaling has been performed since that version was installed.

    To correct the problem, or to simply ensure that a database's history is correct, you can run the nvcheck utility. In the nvcheck window select a database and then issue the menu command Repair>Rebuild account history. This command is much faster than performing an nvreorganize. However, if nvcheck does not subsequently succeed, run nvreorganize on the database.

<Back to Top>

NewViews 2.15 - Service Pack 1

Released - August 14, 2009

Behavior Changes

  • nvcheck has a new Repair>Rebuild account history command.

    Account histories are an internal mechanism that replaced summary postings in version 2.15. This new command in the nvcheck command menu rebuilds the account histories from scratch. This rebuild of the account histories can be performed at any time.

  • Version 2.15.1 includes an updated qw_script to create paycode columns on (blue) tables of payroll accounts.

    A very useful column was omitted;

         employee name

    Delete the original eight (8) new columns and run the script again to create nine (9) new columns.

Problem / Bug Fixes

  • The conversion from 2.14 to 2.15 did not enable the timecard journal transactions indexes.

    If you already converted to 2.15 then turn the timecard journal transaction indexes on by setting the Transactions Indexed field to Yes. The timecards will not appear at this point. Run the nvreorganize utility on the database and the timecards will then appear.

    This release prevents the problem from occurring in the future.

  • Enabling account postings collections could overflow memory.

    When a database has semiloops, enabling the postings indexes of an account can take much longer and consume much more memory. When enabling the indexes on an account with a very large number of postings, say a proof account, memory could overflow.

    This release fixes the problem.

  • The nvreorganize account history progress bar sometimes did not reach 100 percent.

    Version 2.15 introduced account histories to replace the old summary posting mechanism. A third progress bar was added to the nvreorganize utility at that time. However, it did not reach 100% when a journal had more than one tag. This was just a display issue. There was actually nothing wrong with either the database, or the reorganize operation.

    This release fixes the problem.

  • nvcheck utility sometimes had a "bad option" error.

    This error would sometimes occur when nvcheck detected a session with a bad date. This was rare but did occur once.

    This release fixes the problem.

  • Amounts displayed as zeros on blue account tables when a tag was not specified.

    In version 2.14 amounts were typically non-zero on blue account tables when a tag was not specified. In release 2.15.0 which introduced account histories, the amounts displayed as zero. This release restores the original behavior where non-zero amounts are again displayed when the tag is not specified.

  • Journal re-parenting progress bar did not increment.

    When re-parenting a journal, (i.e. making a journal a sub-journal of a different parent journal), a progress bar for the corresponding movement of transactions did not change at all because it was not incrementing.

    This release fixes the problem.

<Back to Top>

Important Notice:

Service Packs

Version History

A version history with build changes is available here.

Note

It is Q.W.Page policy to release new service packs immediately when bugs are detected and corrected. The alternative is to accumulate a larger number of fixes until it is convenient to introduce a new release. Although the Q.W.Page policy results in a larger number of service packs, each containing fewer fixes, this makes the fixes available at the earliest possible moment. This policy is made possible largely because installing a new release is relatively fast and painless.