Payment Journal - Document No. already exists

gemini_shooter

Hello all,

I have this weird error in the payments journal. when I try to print checks it always stops at tells me document no. 611165 already exists in payment journal; batch = XXX and line = 50000

When I check in the vendor ledger, I couldn't find 611165, I also checked the G/L and couldn't find 611165 document no. and also check bank ledger and could not find 611165.

Can anyone please help and comment if they have had the same problem before.

Savatage

Why are you looking at the leger entries & gl entries. Look at the payment journal.

Perhaps you have a duplicate entry trying to pay the same inv??
If not check the Check Register for 611165 - perhaps someone made a manual payment & used that #?

gemini_shooter

I did not .. I could not find a duplicate entry on the same journal

Savatage

How about another payment journal? Perhaps checks were printed and never posted in another payment journal with a different name?

Else turn on the debugger & perhaps that can provide some other details.
It doesn't sound like an error that should be hard to find.

Alex_Chow

The obvious question would be were there any modifications done recently?

gemini_shooter

OK so I manually looked at the journal batch and found that the one of the payment lines had a very long stub and it crossed over into another check and messed up the next check number.

How do you deal with a situation like that when the check stub is very long and uses another sheet of paper and the system should skip one check and jump to next check.

--payment line 1 -- applies to 5 invoices fits on one page, check no. 10215
--payment line 2 -- applies to 15 invoices and the stub does not fit on one page and uses the next page 10216 (Stub is very long so it is using pages 10216 & 10217)
-- payment line 3 should use 10218

How do you run the suggest vendor payments batch job so that it accommodate's such a situation ??

davmac1

The correct way to do it would be to either:
1) void the additional checks and print only the detail on the stub OR
2) print only the first 15 lines and print the following detail on a separate report.
I had to use method 2 for a customer who consistently had this problem and did not want all the voided checks.
This was in an old accounting non-Navision accounting system, but you could use the same methods with some customization.

themave

gemini_shooter wrote:

OK so I manually looked at the journal batch and found that the one of the payment lines had a very long stub and it crossed over into another check and messed up the next check number.

How do you deal with a situation like that when the check stub is very long and uses another sheet of paper and the system should skip one check and jump to next check.

--payment line 1 -- applies to 5 invoices fits on one page, check no. 10215
--payment line 2 -- applies to 15 invoices and the stub does not fit on one page and uses the next page 10216 (Stub is very long so it is using pages 10216 & 10217)
-- payment line 3 should use 10218

How do you run the suggest vendor payments batch job so that it accommodate's such a situation ??

check for a modification to your system, we have printed checks that use multiple stubs for 10 years, starting with Navision 2 through Navision 4.0. Pretty much every check run we do has many checks that take up multiple stubs, the system list each stub as void, and the final stub as the check number

Savatage

we use check on bottom - so we changed the MaxIteration property to 25 & chnage the fonts to arial narrow & smaller to fit more lines on each check.

STPC-CA

I ran into a similar problem in NAV 2013. Kept receiving a similar error except that the reference was to line 20000. The cheque had never been used, it had not been applied in multiple instances - and it left me scratching my head. It took me awhile to notice that for some unexplained reason one of our clerks had entered in posting dates which were dated prior to our last cheque run. For instance, the last cheque run was on the 18th and the clerk had entered in a posting date of the 12th. To easily resolve the problem the posting date was modified to the date of our cheque run - problem solved.