debit and credit amount and amount unmatch in G/L entry

richtsang

This is very strange to me. I cannot think of any reason. Hope someone can share with me.

The version NAV3.70B SQL2000 and window server 2000

User uses General Journal to post an entry (no VAT, no subledger involved).

for example,
debit G/L Account 123A $100
credit G/L account 123B $100

there will be 2 entries created in G/L.

then, in G/L entry line for 123A should be as follows:
Amount 100
Debit Amount 100
Credit Amount 0

G/L entry line for 123B should be as follows:
Amount -100
Debit Amount 0
Credit Amount 100

this should be normal. debit amount - credit amount = amount

However, in my client database, I found that the follwing

G/L entry line for 123A is as follows:
Amount 100
Debit Amount 0
Credit Amount 100

G/L entry line for 123B is as follows:
Amount -100
Debit Amount 100
Credit Amount 0

this is weird.

Another case is
for example, the amount is 220 when posting

G/L entry line for 123A is as follows:
Amount 220
Debit Amount 648
Credit Amount 0

G/L entry line for 123B is as follows:
Amount -220
Debit Amount 0
Credit Amount 648

this is another odd example.

My client had used the software for nearly 10 years. the no. of entry is talking about millions.

We identified 13 entry with weird result. ](*,) ](*,) ](*,) ](*,) . And these posting include G/L account only.

Hope any experienced people can share with me on these cases, and give me some reasons why it happened.

regards,
Richard

matttrax

I understand why it let it post as the amounts do balance, even though they are incorrect. These entries don't have currency conversions? Perhaps using Navigate on the documents in question can lead you to a common thread among them.

Can you definitely rule out no one going into the table and manually changing the data?

richtsang

Thanks for your reply. I don't think it is modified in the back end. Since all entries are included in the several batch. So, they can be balanced by themselves.

as explained, it does not include any subledger. So, I don't think it should relate to currency.

regards,
Richard

Marije_Brummel

What about the field system created entry? Is that set to TRUE?

And are the entry numbers sequentialy?

I have seen a piece of code written once by a consultant who created entries without going though the journal and codeunit 12. This is the only way in NAV to get the data inconsistent other than modifying them from the SQL Backend.

Alex_Chow

Check to see the Correction field is not marked on the journal when posting.