Sage 100

Combined, are the two updates in balance?  How many invoices are are involved?  I ask as you may have to reconstruct the entry invoice by invoice

No they are not in balance. We are double checking all of the invoices now, but it looks like the 1st journal that updated is correct. We will run a tape to confirm that all entries balance. The client does not want to do a reversing GL entry, she wants the bad data to be removed. I'm just not sure of all of the GL tables to remove the duplicated data from. 

Combined, are the two updates in balance?  How many invoices are are involved?  I ask as you may have to reconstruct the entry invoice by invoice

The client does not want to do a reversing GL entry, she wants the bad data to be removed.

Gotta love clients like this.  Technically, I think you could DFDM the detail posting register and carefully delete each line.  Then recalculate GL balances.  I am sure there is another table or two (source journal detail, source journal header).  Probably quote a couple thousand to do the work.  Or no charge the simple reversal.... 

No they are not in balance. We are double checking all of the invoices now, but it looks like the 1st journal that updated is correct. We will run a tape to confirm that all entries balance. The client does not want to do a reversing GL entry, she wants the bad data to be removed. I'm just not sure of all of the GL tables to remove the duplicated data from. 

Combined, are the two updates in balance?  How many invoices are are involved?  I ask as you may have to reconstruct the entry invoice by invoice

Yes... recalculating the balances is risky.  If there is something out of balance from 20 years ago and it carries forward into subsequent years then you have a bigger project.

The client does not want to do a reversing GL entry, she wants the bad data to be removed.

Gotta love clients like this.  Technically, I think you could DFDM the detail posting register and carefully delete each line.  Then recalculate GL balances.  I am sure there is another table or two (source journal detail, source journal header).  Probably quote a couple thousand to do the work.  Or no charge the simple reversal.... 

No they are not in balance. We are double checking all of the invoices now, but it looks like the 1st journal that updated is correct. We will run a tape to confirm that all entries balance. The client does not want to do a reversing GL entry, she wants the bad data to be removed. I'm just not sure of all of the GL tables to remove the duplicated data from. 

Combined, are the two updates in balance?  How many invoices are are involved?  I ask as you may have to reconstruct the entry invoice by invoice

The client does not want to do a reversing GL entry, she wants the bad data to be removed.

Gotta love clients like this.  Technically, I think you could DFDM the detail posting register and carefully delete each line.  Then recalculate GL balances.  I am sure there is another table or two (source journal detail, source journal header).  Probably quote a couple thousand to do the work.  Or no charge the simple reversal.... 

No they are not in balance. We are double checking all of the invoices now, but it looks like the 1st journal that updated is correct. We will run a tape to confirm that all entries balance. The client does not want to do a reversing GL entry, she wants the bad data to be removed. I'm just not sure of all of the GL tables to remove the duplicated data from. 

Combined, are the two updates in balance?  How many invoices are are involved?  I ask as you may have to reconstruct the entry invoice by invoice

Interrupted SO invoice update:

• Restart the journal update and make sure it completes.
• Post through the DTR.  There may be multiples, but that depends on whether you had to reset anything during the restart.
• With a restart, after posting, check the table data for:
  • AR_OpenInvoice (bad balance) and AR_TransactionPaymentHistory (duplicate)
  • Invoice history (all tables, looking for duplicates).
  • Inventory transaction history, looking for duplicates.
  • Current inventory tables (looking for bad QoH).
  • SO / SO history (looking for bad quantity shipped).
  • ...other tables that might be in the mix (enhancements...).
• Summary tables... I usually ignore unless the customer complains.  There are simply too many, and the data is nearly impossible to scrutinize efficiently.  If you find bad entry in IM history, you might need to recalculate IM history... but try in a test company to ensure it works as expected.
• Then, after all that, you look at what did post to the GL, vs. what should have posted to the GL (which "should" match the originally printed DTR, unless someone added another invoice to the interrupted batch... which I have seen multiple times), with manual GL entries to fix.
  • I'll edit bad data, but not GL history that has supporting DTR's.  A journal entry tagged as "interrupted batch corrections" leaves a better audit trail.

The client does not want to do a reversing GL entry, she wants the bad data to be removed.

Gotta love clients like this.  Technically, I think you could DFDM the detail posting register and carefully delete each line.  Then recalculate GL balances.  I am sure there is another table or two (source journal detail, source journal header).  Probably quote a couple thousand to do the work.  Or no charge the simple reversal.... 

No they are not in balance. We are double checking all of the invoices now, but it looks like the 1st journal that updated is correct. We will run a tape to confirm that all entries balance. The client does not want to do a reversing GL entry, she wants the bad data to be removed. I'm just not sure of all of the GL tables to remove the duplicated data from. 

Combined, are the two updates in balance?  How many invoices are are involved?  I ask as you may have to reconstruct the entry invoice by invoice

Interrupted SO invoice update:

• Restart the journal update and make sure it completes.
• Post through the DTR.  There may be multiples, but that depends on whether you had to reset anything during the restart.
• With a restart, after posting, check the table data for:
  • AR_OpenInvoice (bad balance) and AR_TransactionPaymentHistory (duplicate)
  • Invoice history (all tables, looking for duplicates).
  • Inventory transaction history, looking for duplicates.
  • Current inventory tables (looking for bad QoH).
  • SO / SO history (looking for bad quantity shipped).
  • ...other tables that might be in the mix (enhancements...).
• Summary tables... I usually ignore unless the customer complains.  There are simply too many, and the data is nearly impossible to scrutinize efficiently.  If you find bad entry in IM history, you might need to recalculate IM history... but try in a test company to ensure it works as expected.
• Then, after all that, you look at what did post to the GL, vs. what should have posted to the GL (which "should" match the originally printed DTR, unless someone added another invoice to the interrupted batch... which I have seen multiple times), with manual GL entries to fix.
  • I'll edit bad data, but not GL history that has supporting DTR's.  A journal entry tagged as "interrupted batch corrections" leaves a better audit trail.

The client does not want to do a reversing GL entry, she wants the bad data to be removed.

Gotta love clients like this.  Technically, I think you could DFDM the detail posting register and carefully delete each line.  Then recalculate GL balances.  I am sure there is another table or two (source journal detail, source journal header).  Probably quote a couple thousand to do the work.  Or no charge the simple reversal.... 

No they are not in balance. We are double checking all of the invoices now, but it looks like the 1st journal that updated is correct. We will run a tape to confirm that all entries balance. The client does not want to do a reversing GL entry, she wants the bad data to be removed. I'm just not sure of all of the GL tables to remove the duplicated data from. 

Combined, are the two updates in balance?  How many invoices are are involved?  I ask as you may have to reconstruct the entry invoice by invoice

Kevin, 

Thanks for that information.

The client (who is one very tough cookie) wanted it all out. So I spent hours fixing stuff. I got her to sign off that she understood that it was not my recommendation to fix it this way.

What was interesting and I have never seen before is that the invoices partially updated to the subledgers and completely updated to the General Ledger with a GL Journal No 120. The client actually sent me the DTR for the update, but when she clicked update at the DTR prompt, she was given an error. The invoices were still in SO Invoice Data entry. I pushed the invoices through and then had a second GL Journal 122 with a 2/3 of the original invoices from GL Journal 120. 

Interrupted SO invoice update:

• Restart the journal update and make sure it completes.
• Post through the DTR.  There may be multiples, but that depends on whether you had to reset anything during the restart.
• With a restart, after posting, check the table data for:
  • AR_OpenInvoice (bad balance) and AR_TransactionPaymentHistory (duplicate)
  • Invoice history (all tables, looking for duplicates).
  • Inventory transaction history, looking for duplicates.
  • Current inventory tables (looking for bad QoH).
  • SO / SO history (looking for bad quantity shipped).
  • ...other tables that might be in the mix (enhancements...).
• Summary tables... I usually ignore unless the customer complains.  There are simply too many, and the data is nearly impossible to scrutinize efficiently.  If you find bad entry in IM history, you might need to recalculate IM history... but try in a test company to ensure it works as expected.
• Then, after all that, you look at what did post to the GL, vs. what should have posted to the GL (which "should" match the originally printed DTR, unless someone added another invoice to the interrupted batch... which I have seen multiple times), with manual GL entries to fix.
  • I'll edit bad data, but not GL history that has supporting DTR's.  A journal entry tagged as "interrupted batch corrections" leaves a better audit trail.

The client does not want to do a reversing GL entry, she wants the bad data to be removed.

Gotta love clients like this.  Technically, I think you could DFDM the detail posting register and carefully delete each line.  Then recalculate GL balances.  I am sure there is another table or two (source journal detail, source journal header).  Probably quote a couple thousand to do the work.  Or no charge the simple reversal.... 

No they are not in balance. We are double checking all of the invoices now, but it looks like the 1st journal that updated is correct. We will run a tape to confirm that all entries balance. The client does not want to do a reversing GL entry, she wants the bad data to be removed. I'm just not sure of all of the GL tables to remove the duplicated data from. 

Combined, are the two updates in balance?  How many invoices are are involved?  I ask as you may have to reconstruct the entry invoice by invoice