Hi Jayson,
I think Marvin is dead on track. There are two tables that work together when the HATB is printed. For history transactions it is the PM30200 (Paid Transaction History) and the PM30300 (Apply to History). Compare the following fields:
For printing by doc date:
PM30200.DOCDATE (for the invoice and payment records)
This is the document date on the invoice or payment. This is the date used on the HATB when printed by document date.
PM30200.DINVPDOF (on the invoice record)
This is the apply date of the document that caused the invoice or payment to be fully applied. Voided is considered fully applied, a write-off can also cause a document to be fully applied. The DATE1 field for the final apply record in the PM30300 table becomes the DINVPDOF.
PM30200.DISCDATE (on the invoice record)
This is the Date by which the invoice must be paid to earn the terms discount
PM30300.DOCDATE (on the apply record(s))
This is the document date of the payment being applied; like the check date. This is the 'apply from' document date
PM30300.DATE1 (on the apply record(s))
This is the date the sub ledger uses for the 'apply date'. This is set by the user on the apply window and is used by the system when creating the HATB as well as determining when a 1099 amount becomes reportable on a printed 1099.
For printing by posting date:
PM30200.PSTGDATE (on the invoice and payment records)
This is the Posting date for the invoice or payment; set by the user on the batch window or the doc date expansion window. This is the date on the GL and the date used on the HATB when printed by GL Posting Date
PM30200.DISCDATE (on invoice record)
This is the Date by which the invoice must be paid to earn the terms discount
PM30300.GLPOSTDT (on the apply record(s))
This is the Posting date for the apply record. This is the date used by the HATB when printing the report by GL Posting Date.
The apply posting date and DATE1 fields are often the cause for these balances to be out of whack on the report. Often, the user doesn't pay much attention to the apply date because it normally does not create a journal entry. Marvin is also correct in that you have to change these dates using SQL, there is no way in the UI to adjust them. You could void the existing records and then re-enter them properly if you want to avoid direct to table changes.
Kind regards,
Leslie
