This table holds pending payments. A pending payment can be paired with an existing payable, so that the payable can be paid. What this means here is that the pending payment would be turned into a real payment, and then applied against a payable. |
pending_ap_payment_KEY | int (4) | NOT NULL | Primary Key for this table. |
ap_payment_type_KEY | int (4) | NOT NULL | The AP payment type. |
checkbook_KEY | int (4) | NOT NULL | This ties us to a client bank account for the payment. |
transaction_date | datetime (8, 3) | | The date of the pending payment. |
journal_KEY | int (4) | NOT NULL | The journal of the pending payment. |
gl_period_KEY | int (4) | NOT NULL | The gl period to adjust key of the pending payment. |
is_handwritten_check | bit (1) | NOT NULL | True if this pending payment is for a handwritten check. False otherwise. |
reference_number | nvarchar (32) | NOT NULL | The reference number of the pending payment. |
vendor__contact_address_type_KEY | int (4) | | Determines the appropriate vendor address to use on the check that will be created when the pending payment is printed. The address type comes from the payable being paid. If the pending payment applies to more than one payable with differing address types, then the user is asked to pick a type and that is stored here |
is_transaction_date_override | bit (1) | NOT NULL | This value lets us know that the user has chosen to set the transaction date of a pending payment themselves through the User Interface. There are two ways to set the transaction date in Manage AP Payments when creating a pending AP payment. The first is to programmatically set the date to a value. The second is for the user to set the transaction date themselves via the user interface. We need to know if the user has overwritten the system transaction date so that we do not continue to try to reset it. For example, in Manage AP Payments, there is an option to use the oldest due date of a group of payable transactions as the payment date. If the user has set the payment date themselves, and then adds additional payables to the group, we need to know that we do not want the system to update the payment date. Once it is set by the user, it should not be set by the system. This field will be false if the user has not overridden the system calculated date. |
is_posting_period_overridden | bit (1) | NOT NULL | If this is true, the use_transaction_date_to_default_posting_period flag in Client_GL_Setup is ignored when deciding if the posting period needs to be updated to match the transaction date. |