mattcull
9th January 2003, 14:57
We have document lines with the sequence number 99
which make the document not balalnce.
I remember fixing batches like this before by deleting the documents with sequence 99...is there another way?
Matt
Leerebeer
9th January 2003, 17:35
Hi there,
I guess you are referring to the background sequence number in the table tfgld102.
Records with background sequence number 99 are records which are going to be deleted by the background program. First some background:
If your update mode of your transaction type is finalisation then during finalisation the tax and rounding difference records are being created and also the history tables are being updated. If you delete tfgld102 records with a transaction type equal to finalisation then you can always just delete those records as this will not influence the history.
If your update mode of your transaction type is real time then the tax/rounding records are being created by the backgroundprocess real time and also the history tables are updated with the non finalized amounts. If in a script a tfgld102 record has to be deleted then you can not just do this, as the history also has to be reversed. The solution for this is to mark such a record with background sequence number 99 and let the backgroundprocess delete this record and revert the history.
If you can see with ttaad4100/ttaad4500 still records with background sequence number 99 then the background process was not correctly invoked. In every version of BAAN there is a session which you can run to invoke the background process again (tfgld1214m000). But I guess you should also check the value of the field tfgld102.back of all the involved records in the document as they should have the value "not processed".
So if your document balances according to you and only those 99 records are preventing the document from being balanced then I would first invoke the background process again, but first check the value of the tfgld102.back field for all the records as that should be on "not processed".
Regards,
Leerebeer