This article explains an issue that makes the data appear funny on the backend, even though everything has come out okay, and the front end and GL are all correct.
If you find a deposit check that is tied to a gl entry that does not exist it could be a data error, or it could be the result of the following scenario.
When creating a payment, the system creates a new GL line for each line of the payment that is pointed to a different branch that the original customer branch. The first gl entry it creates is always the one for the original customer branch, and this is the gl entry that the deposit check is formally tied to in the data. If the system gets through all of the lines in the payment, and none of them were pointed to the original customer branch, the system goes back and gets rid of the original entry it made for the customer branch, which makes sense since nothing ended up being pointed there. When this happens the deposit check is not updated, so it will still show the old journal entry that the system removed. The actual journal entries do exist, so the GL is okay, the deposit check data simply has this invalid gl entry listed. This scenario should be rare.
Written another way the steps would be:
- Create one payment for a customer belonging to Branch A
- Point that payment to multiple invoices belonging to Branches B and C
- Query the deposit check and notice id for the gl entry listed on the deposit check does not exist
- Query the check detail and notice the ids for the detail do exist and are all in balance. The deposit check simply isn't referencing them.
- This does not create any known issues, it is just something to be aware of.
