|
Under certain conditions memory grew to "unmanageable" levels, resulting in virtual memory thrashing and reduced performance, or eventually an out of memory error, or a similar error triggered by the inability to allocate more memory. These conditions always involved either a major operation on a very large set of books, or a long-running server.
The NewViews internal memory management system has been revamped. As a result, these conditions no longer occur, regardless of the size of the set of books, or how long a server has been running.
See the Problem/Bug Fixes for a description of each NewViews functional area affected by this change.
Users should notice a significant performance improvement when printing documents that use print templates (i.e. checks, invoices, etc).
The previous release, i.e. version 2.07, introduced the Tools>Totalto Graph command which displays a graph of the total-to structure below any selected account. This version, i.e. 2.08, renames the command, as described below, and also introduces a similar command, Tools>Totalto>Graph Above, which displays a graph of the total structure above any selected account. The new command lets you see everything an account totals to, as shown below.
In the figure above, the Tools>Totalto>Graph Above command was issued while positioned on 1060, a bank account. As a result, the total-to structure above the account is displayed in a graph.
You can change the graph fonts, colors, styles, and so on, and decide what information to display in graph nodes. In the example above we display the account name and description, as well as the description of the account's report. This makes it easy to see that the bank account affects other accounts on several reports including the balance sheet, and two statements of changes in financial position, one based on working capital and another on cash.
Now you can now explore the total-structure both below and above any account.
With the introduction of the Tools>Totalto>Graph Above command it seemed appropriate to rename the Tools>Totalto Graph command to better reflect its purpose, i.e. to display the graph below any total account.
This command lets you search for orphan accounts.
The command helps to determine why a proof account is non-zero, that is, why books appear to be out of balance. Note that books are never really out of balance as debits/credits always balance. They only appear to be out of balance, almost always due to omitting to total an account; hence the term orphan.
Position on a so-called proof account, issue this search command, and all accounts that do not total to the proof account are displayed. Although the majority of accounts listed in the search results can be explained by those with knowledge of the total-to structure of the set of books, others will be very suspicious and often represent omissions in the total-to's, resulting in the balance problem.
Note: Only users granted access to the root account (or any object above it) can use this command. Otherwise this would be a breach of the security system since lists of accounts to which the user has not been granted access could be displayed.
This command lets you search for semiloops in the total-to structure of a set of books.
A semiloop occurs when you total one account to another more than once. Position on a total account high in the total-to structure, such as a balance sheet or trial balance proof account, issue this command, and a list of semiloops occurring below the account in the total-to structure, if any, is displayed. Each semiloop is displayed in graphic form as shown below.
In the example above, INCOME totals to EQUITY and also to LE, i.e. liabilities and equity. This is unnecessary because EQUITY already totals to LE, and therefore there is a semiloop.
Semiloops are not particularly harmful because NewViews automatically eliminates duplication on accounts that are totalled-to more than once. However, they do reflect a degree of sloppiness in the total-to structure, and they can also lead to amounts on reports that do not seem to add up correctly. Therefore you should use this command to identify and remove all semiloops from your total-to structure.
In prior versions checks had to be printed when positioned on a payment journal (pink table). Now you can mark a block of checks directly on a bank ledger (green table) and print them.
In prior versions invoices had to be printed when positioned on an invoice or order journal (pink table). Now you can mark a block of invoices or orders directly on a customer ledger (green table) and print them.
In prior versions purchase orders had to be printed when positioned on an purchase order journal (pink table). Now you can mark a block of orders directly on a vendor ledger (green table) and print them.
Whenever you enter a value into a numeric field you can instead enter an expression. Users unaware of this feature typically use a calculator to perform an operation such as calculating an after-tax amount, and then manually enter the result into the numeric field in NewViews. But you can enter an expression such as (5+6)*1.07 directly into the field and as a result 11.77 is automatically calculated and entered.
However, prior to this version the expression evaluator treated any number without a decimal point as an integer and automatically performed integer truncation or rounding. For example, entering 3/2 resulted in the value 1.00 instead of the expected 1.50.
Technically this was not a bug, but it certainly was an oversight. In this version, the expression evaluator treats all numbers as real numbers. Integer truncating and rounding have been completely eliminated and the resulting numbers are exactly as you would expect.
The only rounding that still occurs is the automatic rounding of dollar amounts to the nearest cent. Note that rounding to the nearest cent does not occur on quantity fields or other non-dollar fields.
Many settings prompts and similar windows require you to press a button to dismiss the window or to perform the relevant operation. You can now instead use the <F4> and <F5> keys for this purpose. This lets you perform operations without taking your hand off the keyboard to use the mouse.
Monthly pay periods were required to be calendar months, and semi-monthly pay periods were required to either start on the 1st of a month, or end on the last day of a month. This restriction has been removed to allow for non-standard monthly or semi-monthly pay cycles.
The symbol @P can now be used in the description paycode. The @P symbol is replaced with the perpetual balance of the earnings/deduction account when a pay check is processed.
A number of problems related to memory management have been fixed.
Under certain conditions, generally when operating on very large sets of books, or when running a server over a long period, memory grew beyond manageable levels and the revamped memory management in this release eliminates these conditions. Below, we list and describe several functional areas where problems related to memory management had occurred in the past, and the affect of revamped memory management on them.
Long-running NewViews servers.
The memory management problem was an issue when running a NewViews server continuously, i.e. never shutting it down, over an extended period of time. Memory would eventually grow and result in virtual memory thrashing, accompanied by a significant reduction in performance.
With this release, a server can run be continuously, without intermittent shutdowns, for an unlimited period, without encountering problems related to memory management.
nvreorganize
On very large sets of books, when running nvreorganize, memory consumption would eventually reach unmanageable levels and nvreorganize would eventually thrash to death on very large sets of books. This is no longer the case. Memory consumption is now contrained to a manageable level and a set of books can be reorganized regardless of it's size.
nvcheck
On very large sets of books, when running nvcheck, memory consumption would eventually reach unmanageable levels and nvreorganize would eventually thrash to death on very large sets of books. This is no longer the case. Memory consumption is now contrained to a manageable level and a set of books can be checked regardless of it's size.
Decompressing transactions.
When transactions were imported from NV1 with compression enabled, problems could subsequently occur when decompressing too many of the compressed transactions in one operation. This situation was avoided by NewViews by limiting the number of the compressed transactions that could be decompressed in one operation.
With this release, any number of compressed transactions can be decompressed in one operation, and NewViews no longer prohibits the decompression of too many compressed transactions.
Large imports from NV1.
The memory management problem occurred when importing very large sets of books from NV1. These very large sets of books could only be imported by setting reasonably small batch limits (say 10000) for the import. This had the effect of shutting/restarting NewViews periodically, resuming where the import left off.
Other reasons for using import batch limits, such as resuming after power failures and so on, remain. However, an import should now succeed regardless of the size of the books or the batch limits specified.
Huge default window setups.
Some field changes were not signalled under multiuser access.
Field changes in various settings prompts and notes views were not being signalled to other users, although the changes were properly updated to the database. This bug was introduced in version 2.07 and occurred in that version only.
A bug occurred when deleting sub-accounts.
A bug occurred under the following relatively rare circumstances. First, you had to be adding and using sub-accounts. Second, you had to change the name of an account that had sub-accounts. Third, you had to attempt to delete the account and/or its existing sub-accounts.
This bug is fixed in this release and any problems it may have introduced into existing books are fixed during conversion.
NewViews sometimes reported that a computer was not properly registered when in fact it was.
This problem only occurred on a computer with multiple network interface cards. Furthermore, it occurred only when NewViews was registered when one card was active, and then NewViews was subsequently run when a different card was active. This release fixes the problem.
NewViews version 2.07 would not run more than once.
When NewViews was already running it could not be run again. This problem only applied specifically to version 2.07 and was the result of a dynamic load library conflict. Microsoft Windows silently shut the application down so the second attempt to run NewViews mysteriously did nothing. This release fixes the problem.
EFT (Electronic Funds Transfer) problems occurred for some banks.
The EFT data generated for CIBC and the ROYAL BANK contained a glitch that resulted in their rejection by the banks. This release fixes the problem.
Employee EFT status inconsistency.
An employee EFT status was sometimes displayed as empty under multi-user access but the supposedly same value was instead displayed as non-empty under single-user access. Also, the EFT status for new employees was set to empty instead of inactive. This release fixes the problem.
Payrun processing error if employee born on Feb 29.
This bug applies to Canada only. If an employee's date of birth is Feb 29th then an error prevented the processing of the payrun. This release fixes the problem.
Employee payroll deduction accounts sometimes had an empty normal balance.
This problem applies only to employee deduction accounts that were imported from NV1. Employee deduction accounts that were not correctly a-typed before exporting from NV1, could show up in NV2 with an empty normal balance field. This release fixes the problem for data imported in the future. Employee deduction accounts that have already been imported and that have an empty normal balance must be set manually, i.e. to presumably credit in this case.
Problem occurred when remitting payroll liabilities using the Tools>Pay Wihholdings command.
If any of the five remittance categories (i.e. cpp, ei, tax, etc) were not filled in, then none were paid. This release fixes the problem.
Employer ppip contribution was posted even though employee deduction was zero.
This bug applies to Canada payroll only. An employer ppip contribution was posted even though an employee has reached their limit for the year. This release fixes the problem.
Data might be exported incorrectly from a purged NV1 set of books.
This bug applies only to books that were exported from NV1 and only if the books had been purged in NV1. When the NV1 purge audit count ended in the digit 0, the exporter ignored the fact that the books had been purged. Consequently, Transactions older than 10 years could have the wrong date and lead to the NV2 books being out of balance for these periods. This release prevents this problem from occuring in the future.
Problem occurred when a fatal error was encountered when exporting from NV1.
When a fatal history error was encountered at the end of exporting the accounts from NV1, the NV1_NV2 file was not deleted. Some users ignored the fatal error and subsequently attempted to import the partially complete NV1_NV2 file. With this release the file is automatically deleted when a fatal error is encountered.
An error occurred during printing for French versions of Excel.
Users of French versions of Excel would receive an error that no Print Area had been defined on their print templates, and that the range Zone_D_Impression was an invalid size. This was caused by the fact that French Excel uses the name Zone_D_Impression for the print area. NV2 has been updated to recognize this name as well as the English version.
Several block operations did not work when a table was sorted in backward order.
Several block operations, including printing and copying of blocks, only processed the first row of the block when the table containing the block was currently sorted in backward order. This release fixes the problem.
Phone and fax numbers were not printed on customer statements.
This release fixes the problem.
Rows sometimes did not keep their order when copied and pasted.
Blocks were copied using their creation order and therefore were also pasted in that order. This would not keep the order of the interactive index, i.e. the sort order when the line number order is selected. This release fixes the problem.
Invoices and checks printed incorrectly when printed from their table of details.
When you attempted to print an invoice or check while positioned on the invoice or check details, only the current single row representing the current detail was printed. Now the entire invoice or check is printed correctly.
Bug occurred when setting up columns and moving back and forth using <F4> and <F6>.
This release fixes the problem.