|
Users should experience an improvement in response times when entering transactions. Feedback indicated that users were experiencing inadequate response times when adding transactions. As a result, we stepped up efforts to improve the speed at which you can "feed the beast".
With this release, the response time for transaction entry will be independent of the depth of the total-to structure. Therefore, the improvement you will experience will be directly related to the depth and complexity of the total-to structure of a set of books. In general, the more complex the total-to structure, the more improvement will be experienced.
Experience with actual sets of books has demonstrated that the improvement can be as low as 10 to 20 percent faster, or as high as 10 to 20 times faster. Such improvements are achieved under both single and multi-user access.
Prior versions attempted an ad-hoc solution to auto-incrementing transaction reference numbers in a way that could be used in a multi-user environment. Extensive testing and practice revealed there could be no substitute for user-control of reference numbers.
We had tried to make reference numbers increment in a transparent, silent, and automatic way, but it didn't work for a number of reasons. Now <F3> is used on the transaction reference field to explicitly take the next transaction number. F3 can be used to grab the next reference number on either a journal's transactions (pink) or a account's postings (green).
Tables of accounts (blue) have a new command, Tools>Totalto Graph. Position on any account row in a table, issue the new command, and the underlying total-to structure is displayed as a graph, as shown below:
This graph shows accounts under the balance sheet proof account to a maximum depth of three. Using graph options you can control the maximum depth, colors, fonts, arrow and node styles, graph orientation, and so on. The new command lets you explore the total-to structure of a set of books in a way that was not previously possible.
We suggest that you take the Tools>Totalto Graph command for a test drive:
Navigate to a table of accounts and position on any total account that you want to explore.
You can position on any account row on a blue table of accounts, but it only makes sense to position on a total account. If you position on an amount cell, the amounts displayed in graph nodes will respect the amount cell tag, type, and period.
Issue the Tools>Totalto Graph command.
The graph will be displayed according to the account selected, and the current graph options. Help is available when displaying the graph.
Adjust the graph options until you are satisfied with the result.
Note, the command is introductory in this version and it does not include some features that will be available in the future. In particular, there is currently no way to save and/or print the graph. We will continue to work on these areas.
Rhode Island provided 2006 tax tables after the prior release of NewViews.
This change applies to the workstation login table, and the server directory and connection tables. The new View>Standard Columns command sets up these tables with the standard default columns. Prior to this version, you could delete columns from these tables but you had no way to add them back since the Window>Default Setup command is not available on them. Now, should you delete columns and you want them back, just issue the View>Standard Columns command while positioned on the table.
Twelve additional formats were added to the already available six formats to address the full range of possible situations for Canadian payroll checks.
<F12> is now equivalent to issuing the Edit>Default Value>Set command. This sets the default value of the active column.
<Shift+F12> is now equivalent to issuing the Edit>Default Value>Get command. This sets the active cell to the current default value.
<Control+F12> is now equivalent to issuing the Edit>Default Value>Clear All command. This clears the defaults for all columns.
When a block is pasted, the pasted rows are now marked as a block on the target table, and the currently active row is set to the first row of the block. In addition, when pasting into a table that is in line number order (also called interactive order), the rows are pasted into the current active row position, instead of being appended to the end of the table.
<Alt+I> and <Alt+A> had been used for inserting and appending rows. These were removed because they encountered interference with the Windows menu accelerator key mechanism. In the worst case, this could result in a general protection fault in the underlying software.
<Alt+E+I> and <Alt+E+A> are still available for inserting and appending rows (if the Windows menu is turned on). These are the accelerator keys that invoke the Edit>Insert and Edit>Append commands respectively. The <Ins> (Insert) key can also be used to insert rows.
This command was originally added for compatibilty with the NV1 IMPORT procedure. As such it was restricted to general transactions and these transactions could post only the general accounts. Although the restriction to general transactions remains, imported transactions can now post to any type of account.
Also, imported transactions can now contain quantities and rates.
Notes views now wrap long lines, breaking between words, so they automatically adjust to the width of the notes window.
Prior versions did not allow the editing of compression transactions imported from NV1. Now these compression transactions can be reconciled.
The Reconcile field sometimes displayed an empty value after editing it.
The Reconcile field displayed an empty value after editing it. This happened only when working on a remote database with multi-user access. This was a particularly annoying and potentially serious problem from the point of view of reconciling, but the value entered was in fact set in the database and would be properly displayed after exiting and re-opening the database.
This release fixes the problem.
The <F9> key did not work under some circumstances.
The <F9> key is supposed to switch from a transaction on a journal to a posting on an account, or vice versa, but this does not work properly when accessing a remote database with multi-user access.
This release fixes the problem.
There were several problems associated with the Block>Copy and Block>Paste commands.
Pasting transactions did not work on a remote database.
This bug was actually in the block copy command but was revealed through error messages only when subsequently pasted. In circumstances occuring only under multi-user access to a remote database, and only for transactions, the information accumulated by the copy was incorrect.
Object references set in block paste buffers, and subsequently deleted, caused errors.
If you had copied objects to a paste buffer that referenced other objects that were subsequently deleted, errors occurred during block paste.
This release fixes the problem. Now the missing values are automatically set to empty if the original referenced objects no longer exist.
Some block operations did not work when multiple tags were in use.
Several block oriented operations such as filling a column did not work on account postings collections and/or journal transactions collections when multiple tags were in use.
This release fixes the problem.
Default setup sometimes produced an error.
The Window>Default>Setup, when invoked on an empty desktop, resulted in an error. This usually happens when a top window is parked on the title row and therefore a desktop below is empty. This was not usually a problem until version 2.06, when windows are automatically re-setup due to a version change, (after conformation from the user).
This release fixes the problem.
Object references set by Default>Value>Set and subsequently deleted, caused errors.
If you had set the default for a field such as a transaction posting account, an account's report, an account's total parent or any other field that references another object, and then the referenced object was subsequently deleted, an error occurred the next time the default was used.
This release fixes the problem. Now the defaulted value is automatically set to empty if the original object no longer exists.
The blinking cursor was sometimes displayed in the wrong position within a cell after a row commit.
When a row was committed by pressing <F5>, thus staying on the same row after the commit, if the active cell was currently being edited, the cursor would sometimes continue to blink at the last insert position.
This release fixes the problem.
The Print>Payroll Report command caused errors.
The command did not work and instead reported errors because of underlying program bugs. Note this problem was introduced in version 2.06.
This release fixes the problem.
Payroll had problems crossing year-end boundaries.
Year-to-date amounts were based on the calendar year of the pay period instead of the calendar year of the paycheck transaction date.
This release fixes the problem.
The employer's PPIP contribution was not posted.
For Quebec only, the employer's PPIP (Provincial Parental Insurance Plan) contribution was calculated but not posted.
This release fixes the problem.
On 2006 pay checks, Quebec Provincial income tax was being calculated using 2005 rates.
This release fixes the problem.
Check templates containing field ITEM_YTD caused an error.
Check templates that contained the name ITEM_YTD caused an error when used.
This release fixes the problem.
Payroll report templates that used cell name to print various earnings types (CPP earnings, EI earnings, etc.) produce an error when used. Note this problem was introduced in version 2.06.
This release fixes the problem.
Number of accounts on a report table did not change in real time.
The number of accounts column did not change in real time as accounts were added/deleted. The column did change to the correct value if you switched away from the window and back, but it did not change in real time as accounts were added/deleted.
This release fixes the problem.
When printing pay checks and empty employee EFT status was interpreted incorrectly.
When the print pay checks settings EFT status was set to disabled, checks were not printed for employees whose status was set to empty. These employees were skipped instead of printing their pay checks. This problem applies only to users who converted to version 2.06.
This release fixes the problem.
A problem could occur when changing a transaction's journal.
The problem described here only occurred under a very specific set of circumstances. You had to be changing a transaction's journal to a different journal and this change had to be performed as described below. First, the transaction had to have line items and one of those line items had to have just been added and not yet committed. Second, instead of performing any of a number of operations that would cause the line item to be committed, you had to immediately use the mouse to position on the transaction header and change it's journal field. Third, the new journal had to have a set of tags differing from the old journal's set of tags.
This problem was rare but it did occur. Although rare, it could affect database integrity and had to be corrected using nvreorganize.
This release fixes the problem.
A
version history with build changes is available here.