Forum Replies Created
-
Posts
-
Re: Cheque Printing, JLanno, February 19, 2007 02:37PM, “have to print cheques one at a time because with each successive cheque printed in a series the alignment changes”.
This can happen, but I have never seen it to be a problem to solve.
First: Are they using a laser or dot-matrix printer?
Assuming it is a laser then the solution has alway’s been to:
– Make sure the end of the template looks like this:
@ENDITEMS (it there is a stub at the bottom)
@FF
@ENDPAGE– PARSE the template and make sure that at the end of the PARSE the result reports “Form length:” as 59 or less with (+ form feed) after it.
Why? Most laster printers, at 6 lines per inch, have a maximum page length of 60 lines (This will vary sometimes, but not by much.) If the PARSE result is 59 lines plus a form-feed then the cheque output will fit on the printed page, and the form-feed ensures that the cheque form will be ejected and a snew one started at that point. In 20 years I have never seen this fail – but you sometimes have to experiment with the total number of lines.
Now, on a dot-matrix printer, you are in a different world. Her a cheque form is normally 7.5″. Take 7.5 and multiply it by 6 lines/inch and you get 42 lines. Now your cheque template should PARSE to *exactly* 42 lines, and you must *not* put an @FF at the bottom (which ejects an 11 inch page – not a 7.5 inch one.) Now, if you find the cheque ‘creeping’ up or down from one cheque to the next it’s because the printer is not printing at a proper 6 lines per inch. If that’s the case then report the printer make/model and someone can research the proper Esc codes to set it to that line spacing.
The bottom line is that I have never run across a printing problem like the one you describe that cannot be fixed very easily. The only exceptions were odd-ball printers that could not print at six lines per inch no matter what you did – and that was certainly not NV’s fault.
If none of the above solves the problem, then please report back with the exact printer make & model.
Bob Halpin
halpin@softrite.ca
Here’s a horror story – with a happy outcome.
A new client was having printing problems (XP, Brother Multi-Function printer, USB connection.) The problems all related to page length and lack of form-feed codes on templates – but printing itself was *not* the problem.
I fixed up templates and all was fine – even after a total cold-boot of the computer and the printer. (Too good to be true I’m thinking as I drive home.)
Sure enough by 6:00 pm that night the client was on the phone with printing problems. This time they could print one invoice or cheque, but the 2nd print job resulted in the error “Cannot write to file specified in /Print Options” (LPT1).
At a command prompt we found:
– net use lpt1 \computernameprintername /persistent:yes and the command would complete succesfully.
– DIR > LPT1 would produce a printed page.
– DIR > LPT1 a 2nd time and we would get an error.
– NET USE [Enter] would show lpt1 to be ‘disconnected’
You could go through this in circles over and over with the same result. NET USE would connect, then a print job would cause a disconnect. So, at this point we could reproduce the problem without even running NV.
One point to note: The printer’s LED display was showing the message “Change drum soon” all the time.
I called Brother and a rep suggested that we reset the drum counter and ‘trick’ the printer into not displaying that message. By the time I called the user they had a different suggestin from Brother – install an HP LaserJet driver and use it instead.
In the long run we did this:
– Installed an HP LaserJet IV driver.
– Turned on the shareing for it
– Did net use to redirect lpt1 to the HP’s share name
– Had complete success with no hiccoughs for three weeks nowThe rather fuzzy explanation I got from Brother was that the ‘network’ connection to the printer could/would be lost if during a print job the printer returned any kind of error code. In this case he thought that the printer may have been returning an error concering the drum replacement warning. Using a driver that ignored the (Brother specific) warning might get around the problem – and it did.
I don’t know if any of this helps – but there it is.
Bob Halpin
Look at:
Tools -> Import Records
And in the manual:
Appendix D – Importing files into NV2
This command replicates the functionality of the “IMPORT” procedure in NV1.
Have fun.
Hi.
The updates to NV2 are a large (~75 Mb) exe file that you ‘run’ to install the new version.
Assuming you have downloaded it and can see it on either your dektop or in an explorer, you just Double-Click on the file. This will bring up the installation dialogs where you specify where to install NV2.
To go back a bit – all updates to NV2, whether they be service-packs or whole new versions, are complete installations of NV2. They are installed exactly the same as if you were installing NV2 for the 1st time. All you need to know is where your present version is installed so you can install the update in the same place. If you are unsure about this, then run the old version and click on Help , then About.
Close to the top of the resulting help page you will see something like:
NewViews Program
Program nv20.exe
Directory c:/nv2Just intstall the new version in the same directory path as you see next to ‘Directory’ and you will be fine.
Bob Halpin
halpin@softrite.ca
http://www.softrite.caYes, some are ‘follish’. I remember when Windows ’95 came out – the lineups to get it the first day, the acrobats rappelling down the CN tower, all the fuss …
Then came the fallout. The NV users that immediately switched their computer to Windows 95 – with no testing or escape strategy – then freaked when something didn’t work – and just *had* to get going that minute. History repeated itself several more times – with Windows ’98, NT, ME, 2000, & XP. In the long run Windows got more stable and running NV on it became easier and easier, and not one ‘bug’ ever appeared in NV that required changing one byte of code. (The current DOS NV was compiled in 1993. Yup, 1993.)
So forgive my cynisym here – but I’ve seen this all before.
Now to address your questions:
> Does NV2 convert easily to Vista?
There’s no conversion required. As Martin stated on the 15th, NV2 is a 32-bit program; it will (does) run on Vista.
> NV2 has the ability to use 64 bit technology but at what cost to the client.
Sorry, but I don’t understand that one.
> I have two clients that are ready to convert to NV2 from
> NV and one will require having this knowledge for proposals
> to their Executive. They will probably also need your skills
> Bob on some custom software.Why wouldn’t they simply use/buy a ‘current’ computer that is Vista ready and run XP on it? Then, in the future they can switch to Vista when it’s been ‘vetted’ by the public, and there are a couple of service packs available.
> Is QW Page saying that it will be ??? years until they are
> ready to convert to Vista?Again, there is no conversion required. The 32-bit NV2 will run on Vista.
> These clients have been patiently waiting for NV2…
> now how long for them to be able to use Vista.From what I understand, there’s nothing to wait for.
> I have been in Future Shop and the advertising is heavy.
It will have to be – from what I’ve read there is no compelling reason for anybody to run out and convert to Vista right away.
If a business does have some application they simply must run on Vista, then it’s gotta be something pretty bleeding edge – and in my opinion should be on a separate system than their accounting data.
Now, please note, these are *my* opinions and not Q.W.Page’s. If I have said anything that is incorrect I want them to jump in and tell us.Regards,
Bob Halpin
http://www.softrite.ca
halpin@softrite.caI just have to comment on this:
> How is NV2 going to work for my clients who want
> to install Vista when it hits the shelves?Upgrading a system your business relies on the minute something new and fancy hits the shelves is utter folly.
Bob
The problem is that the ROE routines have to go back close to a year to report insurable earnings/hours. To do this it ‘walks backwards’ through the employee’s pay cheques and, for each pay cheque looks at the pay period number it was issued for. With that number, it knows which ‘slot’ (Box 15 if memory serves) to add the earniings/hours to.
In your case the employee is (currently) paid under 26 pay-periods, so the program gets a little confused when it encounters a pay cheque that was issued for a pay period number greater than 26 (it was issued while the employee was weeklt.)
Unfortunately there is no way to remedy this – you will have to complete the ROE manually (but I guess you have already done that.) When the ROE support was added it was obvious that it would be a large effort to accomodate this situation when the number of employers that change their pay frequency is close to zero.
Regards,
Bob Halpin
2 Items:
– You can make the NV2 Server start automatically at boot by copying the NV2 Server icon from the Start menu to C:Documents and SettingsAdministratorStart MenuProgramsStartup.
– Norton AV (and, perhaps ofther AV software) can hamper the server considerably. With Norton you must mess with the settings (I forget which ones, firewall I think) to consider NV2 a trusted application and the speed difference is immediately noticable.
One last thing. JLeotta wrote:
>A few days ago I called QW support because NVEXPORT was hanging and I was told
> to set the properties of the NV1 shortcut to full screen, set the idle
> sensitivity to lowest, and place some object on thekey during the export.
> This was a great solution since it cut my export time by 1/3 and removed the
>hanging problem. This needs to be included in the documentation for NVEXPORT so
>that others don’t have to waste so much time finding it for themselves and reduce
>the calls to QW support.This is in the on-line manual. At: NewViews 2.08 Manual > Appendix C – NV1 Users > Converting NV2 to NV2 > Exporting NV1 Data > Exporting the NV1 Books you will see:
To complete the export from NV1 in the shortest possible time, NewViews should be running in full screen mode. This is because Windows will give more CPU time to a DOS application running in full screen mode than if it was running in a window.The command to set a DOS window to full screen is
key press the key.) The same command will restore the window back to its original size. Once the NVEXPORT procedure is running, and you have switched to full screen, place a small light object (like a stapler) on the
key of the keyboard. By keeping the key pressed, Windows will give nearly 100% of the CPU resources to NewViews. Without the
key depressed, the NVEXPORT procedure could run for days or even weeks.
Bob
This could/would happen if you use the “DOS Command” option from the NewViews shell.
Instead, you must open an MS-DOS/Command Prompt window. Assuming you are using Win 2K or Win XP:
Click ‘Start’, then click ‘Programs’ or “All Programs’, then “Accesories’, then ‘Command Prompt’.
This should open a DOS window with enough memory to run the reorg.
Bob
P.S. Follow Henry’s advise 1st – DO A BACKUP!
“I’ve tried sending other things to the printer (from another program) and they print fine …”
I’m assuming those are Windows programs.
Configuring a system to support printing from DOS programs can be a bit tricky, but here goes.
1. The printer must support DOS printing – and this is getting to be a long-shot. Most new printers, especially ink-jet, do not support DOS printing. Asking a salesperson at a store, or even a support-rep for a printer manufacturer about this capability is usually a waste of time – most don’t know or really care if they answer the question correctly.
Assuming the printer does support DOS printing, you are on to step 2.
2. You can usually configure a Win 2K/XP system to support DOS printing by doing this:
– In the properties of the printer you wish to print to, note the “Share” name. If it isn’t shared, enable sharing.
– Note the name of the system the printer is connected to.
– Get to an MS-Dos/Command prompt.
Type: NET USE LPT1 \computernamesharename /PERSISTENT:YES
(Substitute the correct names for the computename & sharename)
If you get an error, try the same command but substitute LPT2 for LPT1.
If you get through this command without an error, type: DIR > LPT1 [Enter]
(Or LPT2, if that is what worked above.)This will send text output to the printer. If it prints, you are in business. If it doesn’t then either the printer doesn’t support DOS printing, or there is some other bug-a-boo at work. Note: Until you can get output from the printer doing DIR > LPT1 (or LPT2) then you won’t be able to print from NewViews (or any other DOS program.) That DIR command is the acid test.
Assuming it worked, then in NewViews put LPT1 (or LPT2) in the FIle Name field of /Print Options and you’re good to go.
Bob
P.S. Contrary to prevalant mythology, this can work on a system where the printer is connected via USB.
I’m going to correct the previous post, slightly.
You can print through a USB port if you concoct the correct NET USE command (and the printer supports the PCL language.)
Bob
Footnote
These are the most common problems we solve when users have difficulty downloading their payroll update:
– The file is saved to the wrong place, ie: not the NewViews program directory. Then, when you log into the correct directory, the file either isn’t there, or *last year’s* version is there and they mistakenly execute it. The result in the latter case is reinstalling last year’s payroll.
– They change the name of the file in the “Save In” dialog, and then don’t remember the name. Now it is truly lost and you have to download again.
– The file is saved to the desktop – and when you double-click it the files are extracted, but to where? Probably some path that starts with “Documents and Settings …”
– It’s fatal to navigate the “Save In” dialog to the NewViews Directory and then double-click on the NV program file. That causes the downloaded file to replace NV.EXE – and your NewViews will no longer run at all (you have to reinstall it.)
– They save the file to last year’s payroll update disk, then GETLIB the library as usual. The result is last year’s payroll again.
– All goes well, but the books are on a network drive and NewViews is installed on multiple local drives. When another user opens the books and tries to run payroll they get the incompatible version error because the books expect the current version of payroll, but last year’s version is what is in their program directory. (Solution – copy the three library files *from* the 1st computer to the NV program directory of each other machine.)
It would be nice if we could make the process simpler, but we really can’t (this is DOS after all.) Supplying more instructions would probalby be counter-productive – the longer they get the more people are less likely to read them.
Bottom line – if you have a problem, don’t get get frustrated – call Support.
Bob
There’s no real right or wrong.
Accounts that ‘belong’ to an employee are converted to the correct type during import if they were not ATYPE’s properly before the export. The only downside is it slows the import down a little bit – say 10 or 20 seconds per employee.
Accounts that are ATYPE’d as Employee that are not in fact employee accounts are converted to General during the import. Again, the only downside is a second or so per account.
Bob
>Re: Rev Can Audit
>Posted by: HMah (AC5-Webproxy46.direcpc.com)
>Date: September 12, 2005 03:04PM>The problem with PRREPORT is that it prints the actual information for
>the date ranges recorded in the various accounts.I’m not sure how a report that prints ‘actual information’ can be construed as a ‘problem’, but let’s continue …
>For example if you voided several pay cheques after remitting than
>those cheques would no longer be included in the PRREPORT, and
>therefore the printout would not match the actual remittance figures.Well, they would be included in any report printed *before* you voided the checks and (obviously) not be included in a report printed *after* voiding them. The 1st report would match the remittance and the 2nd would not. The same would be true for any other remittance report you could think of once you start changing/deleting transactions dated in the past.
The solution seems clear: Don’t void pay checks, use reversing entries instead (dated in the current period.)
>The next remittance would deduct for the voided cheques and again
>PRREPORT would not reflect the difference for that pay period.Using reversing entries would solve that.
>My question regarding nv2 was “is there a method to print the actual employee >cheque detail which make up specific remittances (regardless of when you print the >report, at the time or twelve months later).
In the scenario you describe, this is impossible. You can’t print a report showing deductions & contributions that matches an actual remittance, void some pay checks, then produce a report that somehow includes pay checks that are no longer there.
About the only thing that would be possible is to ‘archive’ a snapshot of the amount details at the time you produce the remittance check. The pay withholdings feature *could* do that – but you run smack into a problem if you edit the remittance amounts before posting the check. In that case the details would not match the remittance and you’re back in the same boat you started in.
Bob
Re: You post of September 13, 2005 06:03PM
Question: Which [files] do I and can I move to NV2
You don’t need to move anything anywhere. The NV1 & NV2 files can occupy the same directory – there is no conflict between the versions whatsoever. If you want the NV2 files somewhere else then copy/move the database.0, database.hdr, & database.qw to the desired directory using Windows Explorer.
Bob Halpin
