[LChilds]

Hello Martin,
Thank you for the quick reply. I did just that after posting my question. Did take a bit of manipulation getting the scanned signature aligned properly for our NV2 checks but it works great now. Not as difficult as I thought it was going to be.
Thank you
Les

[LChilds]

Hello Martin.

Thanks for the info. I do have about 755 procedures in total. A good portion of them that I have programmed myself to accommodate our requirements over the years. I will remove these procedures as we obviously won’t be using them again in NV2.

Thanks

Les

[LChilds]

Hello,

Thanks for the reply. Deleting transactions to free up space is not an option for us. The books have been purged up to Dec 31, 2009 and the only remaining transactions are current year 2010 transactions. These absolutely cannot be deleted as it will cause our books to be completely inaccurate for year end purposes. The converted set of books will not be accurate either and deleted transactions would take months to re-enter into NV2. This would not be an option.

The only option that I can see is to have to build a completely new set of books with opening balances. This sort of defeats the purpose of converting and having history information in the books.

But my question remains, “Why would I receive the error message that the books have reached the maximum size when NV2 is exporting all data to the NV1_NV2 file which is not apart of the dos books database file? I realize that the books have reached their maximum size I just do not understand why NVEXPORT needs block space within the NV1 set of books to export into a completely different file for the NV2 format.

I remain confused.

Thanks

[LChilds]

I checked the page layout under print options and set the “adjust to” and scaling was set to 100%. I then attempted to print 3 sequential cheques and the printer ended up printing 12 pages. The cheque did not print on one page. The first cheque printed with missing information on the right side. The next page was blank. The second cheque printed in the same manner and then a blank page. So on and so on.
We are using Office 2010. Could this be the problem?

Thanks

Les

[LChilds]

Hello Martin. Thanks for the reply. Actually I found the problem not soon after posting this message. It seems that NV2 Payrun does not like the word “processing” being typed into the “status” field on the payrun table. After I used F3 to select “processed” payroll fired up so to speak and only took a few seconds to complete.
Who knew NV2 would be so fussy on a particular word.

Thanks

Les

[LChilds]

Hi Bob.

I realize that all my years of custom programming is worthless in NV2 but it would have been so much easier if NV2 had this capability built in or at the very least allow the addition of scripting to accommodate our requirements. Speaking with Q.W.Page regarding our requirements would take months and months as we are probably one of few companies that have such extensive programming in place for use with NV1.

I will continue to review and test NV2. Perhaps I will find a solution or a work around to our requirements.

Thanks kindly

Les

[LChilds]

To continue from my last post.

Is this scenario going to be able to be set up within NV2? We have been using NV1 for almost twenty years but the time has come to upgrade our accounting system and it would be great if we could move to NV2.

Any thought or help on this would be greatly appreciated Bob.
Thanks
Les

[LChilds]

Hi Bob,
Thanks for the reply. Under normal circumstances you would be correct…that they would be considered suppliers. However being in the construction industry our company provides services based on supply and install. Our company supplies all materials and our subcontractors supply labour only. Our company sets the labour rates that are paid to our installers depending on what is being installed. Hence different rates for different installers. Under NV1 we are able to use and post various labour rates and other expenses and deductions for, ie tool purchases to job cost accounts and installer “payroll accounts”. There can be upwards of 10 to 15 different accounts depending on what is being installed. We use the term payroll accounts that are on a subcontractors payroll report for convenience only. This has been accomplished through my complex programming within NV1. Labour rates etc. are chosen from procedure screens that are called during processing of individual work orders. The “payroll accounts” then total to various labour and other expense accounts on various reports. Just to clarify, this situation is not a normal “payroll” scenario with income tax, cpp and ei type deductions.

While testing NV2 I’m finding that the process of entering labour rates based on quantities of materials installed, ie number of square feet, is somewhat cumbersome and time consuming. Not being able to use the pick command to set up materials used and labour rates or price lists from within the “quantity and rate fields” which to chose from makes this extremely time consuming on a keyboarding and entering basis.

[LChilds]

Hello Martin. Thanks for your reply. Actually I have already downloaded DOSBOX and have it installed. I am able to bring up NV1 in the box but I can’t seem to get NewViews to print from Dosbox. I have reseached the problem on the web but can’t seem to find any printing solutions that work. Perhaps you know of one that does. Thanks.
Les

[LChilds]

Hello Martin,
Finally been able to get back to you. I downloaded and installed the new version of NV1PD7. The PRTPAY procedure did as you say correct the running balance on my cheque stubs when taking discounts. Thanks. However the procedure will not recognize the SIMPLETRANS command in the first notes line. It keeps on putting the word “payment” within the Supplier account ledger not the name of the supplier. Here is what I have in the first note line: @DISCONTAX=N @PYMTDESC=SUPPLIER @SIMPLETRANS=Y. Can you tell me why this setup is not working.
Thanks
Les

[LChilds]

Update on Download of Productivity Disk.
Talked to Technical Support on the problem. It seems that Q.W.Page’s Customer Service or whomever is responsible did not upload the file onto the ftp website hence why I continually received an error message. Once the file was uploaded I had no problems downloading the disk. All is good.
Thanks for the replys.

Les

[LChilds]

Good Morning,
The address used was as follows as provided in the download instructions:
ftp://ftp.qwpage.com/hidden/pd773636.exe.
Thanks
Les

[LChilds]

Good Day Martin,
An update on the problem with PRTPAY. I began reviewing the source code for the PRTPAY subprocedures, namely ~RTPAY.1. I should point out that the program version number is 1.41b and the procedure library version is 12 for those who are interested.
Because this seemed to be a discount calculation matter I reviewed the subroutine DISCOUNT in the ~RTPAY.1 subprocedure. At the bottom of the subroutine are two lines as follows:
@sub IBal%=IBal%-IDisc%
@sub IPaid%=IPaid%-IDisc%

I put an ! mark in front of the first line @sub IBal%=IBal%-IDisc% to remove it from the programming. I then ran further tests on using the Take Discounts function in PRTPAY and the running balance on the printed cheque stub was now correct and being calculated properly. I also ran tests not using the discount function and it seems to be functioning properly as well.

It would appear that removing that one line of code from the subroutine fixes the problem.
Perhaps if anyone else has had the same problem they can try to do the same fix.
Thanks
LChilds

[LChilds]

Good Day Martin,
Yes I did receive the message that the patch was successfully installed and logged. I followed the instructions exactly as per the Readme file in the Patch directory on the January 2004 Payroll Update disk. What I did notice is that an updated copy of PRTPAY has been added to the NewViews program directory. Should that not have replaced the old copy of PRTPAY that is in the Proc directory? The install also reinstalled versions of the PRTPAY subprocedures as well.
I ran tests using the patched PRTPAY proc and it still didn’t work.
Thanks
LChilds

[LChilds]

Good Day,
After years of not having to use the “Take Discounts” function when running PRTPAY to pay vendor invoicing, the need finally arrived. The problem is that the running total being printed on the first line of the cheque stub is not correct. As an example:
Amount – Discount = Paid = Total
100.00 – 2.00 = 98.00 = 96.00
350.00 – 7.00 = 343.00 = 432.00

As you can see the total field is subtracting the discount amount
from the paid field a second time and adding it to the total field.

I have added the patch P4262.NPF to the PRTPAY procedure as it says it is suppose to fix the problem but it does not.

Any idea as to what is causing the problem?
Thanks
LChilds

[Author]

Posts