|
July 2008 Payroll
Includes Canadian & USA July 01, 2008 tax calculation updates.
Direct Deposit - Electronic Funds Transfer (EFT) for USA payroll
You can now deposit employee paychecks directly into employee bank accounts. Paychecks no longer need to be printed, although you can continue to print any paychecks when necessary. Stubs for electronically deposited paychecks can also be printed.
As a reminder, Direct Deposit Payroll (EFT) for Canada was introduced in version 2.06 December 2005.
Vendor Payment - Electronic Funds Transfer (EFT)
You can now pay vendors with Automated Clearing House (ACH) transactions that transfer the payment directly into vendor bank accounts. Vendor checks no longer need to be printed, although you can continue to print any checks when necessary. Payment Detail Advisories for electronic checks can also be printed.
Improved "Pay Account" has new settings for (EFT)
Pay Account has been updated to handle EFT Payments. With this updated version, Pay Account respects a Vendor's EFT status.
Two new options have been added to the "Pay Account" prompt,
"EFT - Start Number"
"EFT - Bank Payment Journal"
You can run a workstation and server on the same computer.
Prior to this version you could not run a workstation and connect it to a server running on the same computer. This is now allowed. Note however, for efficiency reasons, running workstations and servers on the same computer is still not recommended.
You can now print checks directly from a vendor account ledger
In prior versions checks had to be printed when positioned on a payment journal (pink table), or bank account. Now you can print checks directly from a vendor ledger (green table).
Printing behavior change and new template field
Printing of invoice detail items will now stop when the running balance of the invoice matches the invoice total. This feature permits internal "housekeeping" information on a transaction's details that will not print on the invoice/purchase order sent to a customer/vendor.
Print invoice templates now support the template field ACCOUNTBALANCE. The amount printed is the account ledger ending balance.
nvcheck has several new repair commands
nvcheck has several new repair commands.
Three new commands were added under the Repair menu item in the nvcheck window. These repair "Dangling Interactive Records", "Dangling Indirect Records", and "Dangling Double Indirect Records". These commands either report that no such records were found or else report how many were found and repaired. A record is "dangling" when objects corresponding to the record no longer exist. This can occur when no backup is available and a database has to be repaired from serious structural damage including situations where sections of the database have been lost forever.
Minor behavior changes
Transactions that have an empty Reference value, which are moved to a journal that has a Next Reference, will be given the destination journal's next reference.
In some circumstances, formula columns are not automatically refreshed when the database changes. <Ctrl+F5> will force a window refresh.
A Window>New Database Explorer command restored and cascaded all explorer windows. Users found this disorienting, so it has been removed.
Problem/Bug Fixes
History errors were sometimes reported when importing boomerang transactions from NV1.
History errors were reported after an NV1 import, if the set of books contained boomerang transactions dated in the period covered by summary postings (as seen on the NV2 odds and ends document). A boomerang transaction is a simple transaction that debits and credits the same account. Boomerangs are special because they do not show up in debit/credit ledgers or contribute the debit/credit amounts in account histories. These flows were not handled correctly in the summary postings. This release fixes the problem.
Changing an account name, and also re-totaling it, caused a bug.
The bug was identified with bug id 314120040922103744. It occurred if you changed the name of an account and then, before committing the account, you also totaled it to a different total account. This release fixes the problem.
The File>Save command caused a number of related bugs.
When in multi-user mode the File>Save command could cause a number of different but related bugs to occur. The following bugs were all a result of the same underlying problem:
314120061031101553 Encountered unexpected before mode in remote database.
314120061115103122 Could not find delta for XXX in YYY.
314120050103112516 Encountered null _current.
314120061116103624 Could not find delta for XXX in YYY.
These all occurred when one user was editing a transaction while at the same moment another user issued File>Save on the same database. This release fixes the problem.