[TThibodeau]

Henry

If you want to use nvc.exe you can turn off edit safety by inserting
“/nosafety” at the end of the command line.
I have to use the command line instead of the shell because I have found that some customers are “Key Happy” They do not watch what they are doing and in the shell when the book selection box is open they hit the “/” key .You never know where they end up.

I create a PIF file for each set of books that they use.

Thomas Thibodeau
Dihedral@eastlink.ca

[HMah]

Thomas:

Yes the /nosafety does turn off the edit safety. If your client only has to access one set of books then the nvc command works fine. Where you have to access several sets of books, or want to access different drives than the Shell provides faster access. I prefer the shell and try to teach my clients the various options available. The only item that really concerns me is the option to turn off Crash Recovery.

[DEholnikof]

The government has tried for years to legislate rules and laws – against or prevent stupidity – but it never works.

The same can be said about computer software too !

I try to write smarter / better code – but if the user insists on doing ” DEL *.* ” and after the warning, still says YES – then what do you expect from me?. At some point (as in life) we must take responsibility for our own actions. BUT It is also for the same reasons we have backups and a recycle bin, because accidents DO happen !!

Often the client is – his/her’s own worst enemy !

Me

HMah wrote:

> Thomas:
>
> I prefer the shell and try to teach my clients the various options available. The only item that really concerns me is the option to turn off Crash Recovery.
>

[DStrickler]

April 14, 2004

My payroll has about 550 T4s and T4As. The CRA is demanding that I transmit my T4 data electronically instead of on paper. Has anyone figured out how to do this and conform to the CRA request. There is a substantial penalty for not complying.

Can you help?

Don Strickler

[DEholnikof]

Hmm,

I spoke with the CRA today – and they are requesting the data in XML and on a CD or other medium to be sent snail mail (Canada Post). They have no provision for uploading directly – more than 70 employees.

Its do-able, but . . . . .

You might want to look at cantax

http://www.cantax.com/

Post Edited (04-14-04 13:56)

[LChilds]

April 21, 2004

Re: Import Procedure

Every time we use the import procedure to import previously exported accounts on the report level, after the import is complete and we issue document expand on one of the accounts we have imported we are taken to the notes view of the account and not the ledger view. Is this a bug in the import procedure? Is there a piece of NPL programming that I can add to the notes view of the procedure to fix?

Thanks

[HMah]

Are you using the EXPSETUP, then IMPORT or / B X and / B I?

Not that it makes a difference, because I can’t say I’ve encountered that problem using either method. Which are you using?

[DEholnikof]

Hi,

This is normal behavior when you export / import an account from the report level. As a procedure, it exports the transactions, distributions, and the notes. IN that order – The import happens in the same order which is why you are on the notes view.

When you do a document expand to the Account – you could simply do / DV L to move back into the Ledger view.

I hope this helps?

Regards

[HMah]

LChilds:

Must apoligize, it does leave you in the Notes view as David mentioned. It is something QW can probably fix. However, I suggest you create a Macro for yourself and call it LEDGERV. In the procedure type ~DV”L”. then add LEDGERV to the Shift F3 function key (only because that where I have all my clients add it) using FKEYS. Then you can quickly switch from the Notes (or any other view) to Ledger with Shift F3.

Post Edited (04-22-04 08:07)

[LChilds]

Hi Henry,

Thanks for the reply. We use EXPSETUP. I have known, and have had this problem for quite some time, years actually, but because of time have not fixed the problem myself. I have been using NewViews since 1987 and have been programming since that date also. I suppose this problem is more of an annoyance than anything else. Thought maybe someone else may have had the same problem. A macro added to FKEYS would work but does not actually address the bug within the procedure I seem to have. The only reason why I bring this up is because other procedures that need to access the ledger view to write data into ledger view fields have caused runtime errors. I know, strange but true. When I can find some time I will try a few things and see what happens.

Thanks
LChilds

[HMah]

LChilds:

This problem seems to occur when its a Payable Vendor being imported (probably AR also).

I’m not a programmer, but I do try to provide simple solutions where possible. I your case I would do the following:

Create a macro say IMP with: ~DE ~DV”L”.

then another say RUNIMP with: @call “IMPORT”.
@jmp “IMP”.

So instead of running IMPORT, run RUNIMP.

Not fancy but it works and one doesn’t need special skills to solve the problem.

Post Edited (04-22-04 21:19)

[DEholnikof]

Henry,

The Import / Export procedures run correctly – it is by design, that if there is something in the notes view, of the last account / item imported – then the view remains in the NOTES. If the Last item to be imported has no notes – then you will remain on the Ledger View.

For example – if you look at the notes view of any Account, jump to / go to any next account – you’re still on the notes view. This also is the same for any Distribution View D or N.

This is by design – and not a bug.

Copy the following code into an FKEY – procedure and it will correct the view for any location to a NOT Notes View. Or you can download “aView.zip” containing this code from (it will be removed in a few weeks)

http://www.prgms.com/newviews/Procs/aview.zip

Regards
David

! This procedure is supplied free of charge by
! Programmers Group D Eholnikof, cc – Copyright 2004
! AND can be redistributed with out charge or cost.
!

---

!
! IF the cursor is on A NOTE VIEW – then it will change
! If called by an other Procedure – it will restore any
! variables that were used. April 22, 2004
!

---

!
@save 0
@save 1
@declare Docu 0
@declare View 1
!

---

!
~er ! force any updates
@docu Docu ! Doc Type – Where are
@view View ! What View?
@if=$ View,”N” ! Yes, some notes view
@if=$ Docu,”HOME” @then ~dv “H” . @end ! HOME
@if=$ Docu,”REPT” @then ~dv “S” . @end ! REPORTS
@if=$ Docu,”ACCT” @then ~dv “L” . @end ! ACCOUNTS
@if=$ Docu,”DIST” @then ~dv “D” . @end ! DISTRUBTIONS
!

---

!
@if=$ Docu,”OE” @then ~dv “O” . @end ! ODDS & ENDS
@if=$ Docu,”PRNS” @then ~dv “P” . @end ! PRINTER LIST
@if=$ Docu,”PRIN” @then ~dv “P” . @end ! A PRINTER
@if=$ Docu,”PRCS” @then ~dv “P” . @end ! PROCEDURE LIST
@if=$ Docu,”PROC” @then ~dv “P” . @end ! A PROCEDURE
!

---

!
@end
!

---

!
@Restore
@Ret

Post Edited (04-23-04 07:10)

[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

[MSchappler]

When you added P4262.NPF to to your NewViews program directory did you run the following command at your NewViews program directory (for example C:NV>):

NVPATCH P4262.NPF

If you did, did it return with the following:

“Patch successfully installed and logged”

If it did not return successfull you would have received some other type of message which would point to the cause. For example, go into your books and issue /Go Runproc (/GR) SUPPORT and press enter. Note the line that displays NewViews program directory. Is this the same directory where you had run NVPATCH P4262.NPF.

Regards,

Martin

[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

[Author]

Posts