How Can We Help?
Dynamics GP can leave rows in your work tables (both GP or ISV tables) where required columns are left empty. For example, you can have a row in the GL10000 table with a JRNENTRY number but no BACHNUMB or BCHSOURC values. This happens because, when you open the Transaction Entry window to enter a new Journal Entry, Dynamics GP immediately reserves a record in the GL10000 table with the default next Journal Entry number. When you close the Transaction Entry window, Dynamics GP removes the reserved record, but if you have an unexpected error or a problem closing the window, or you crash while the window is open, that row is not cleared by Dynamics GP. The next time you open the Transaction Entry window, Dynamics GP thinks it cannot use that Journal Entry Number anymore, so it will leave that row alone and there’s no way to edit or even see that row from within Dynamics GP.
This same type of empty row can be left in all modules: Payables (PM10000, PM10300); Receivables Management(RM10201, RM10301); Purchase Order Processing(POP10100, POP10300); Sales Order Processing (SOP10100); Inventory (IV10000); Payroll (UPR10200).
When these records are left abandoned in your database, other routines in GP can create an empty row in the SY00500 table. For example, if you have an empty row in the Inventory Work table (IV10000) and then run Check Links on the Inventory Transaction table, Dynamics GP will create a batch with an empty Batch Number, so you cannot clean up these rows from inside Dynamics GP. As part of your regular maintenance, you should regularly check work tables for empty rows.
Leaving these empty rows can cause problems for Dynamics GP, so they should be removed on a regular basis. Standard GP processes such as Check Links or Reconcile will not remove these empty rows. You will have to delete them manually through SQL Management Studio. Before removing these rows with an empty batch number, first make sure that someone isn’t currently entering a transaction by checking the SY00800 table.