This flag forces the user to select supplier types when running a selective invoice payment. When getting to the supplier type field, a pop up will appear with a data-grid showing the supplier types. This is a PSA Air specific screen and is only called when this BANK_SECU flag is set to “Y”. The control is that only specific supplier types of the same type can be paid in this run. IE, if a supplier type of type G is selected, only other supplier types of G can be selected.

This is commonly used in mining for CEE expenditure where supplier types for CEE must be paid out of a specific bank account.  

Default date format, A for DD/MM/YYYY, U for MM/DD/YYYY

Currently this is only valid to be set to PO. It is what the details of the invoice are set to at the tie of posting an invoice. In default AP Automation, it will set the cr-tr-details field to the PO number from the invoice matching. 

This is the default supplier key to map from and it is currently only valid to be set to ABN. 

This flag defines if the department on an invoice should be automatically gathered from the 1st line coding of a requisition. If a PO is automatically scanned by OCR, it will find the PO and allocate the department based upon the GL mapping rules set in Departments GL Prefix. 

If a user adds a PO, corrects a PO, it will also set the new department code.

When a user changes the PO, and it picks up a different department mapping, it will ask the user if they want the new department to be allocated. 

This flag defines if the department on an invoice should be automatically gathered from the user who entered the requisition or purchase order.

When this flag is set to Y the program will look at the PSA Air - Department Default from Reqn User table. This table can be found in PSA Air - Setup

When a purchaser order is tied to an invoice inside of PSA Air the program will look to see who raised that purchase order or requisition. The program will look at the buyer/requisitioner field on the purchase order/Req header.

If that user is defined in this table then it will automatically assign the department associated with that user based on the Department Default from Reqn User table. If the user is not in this table then the department on the invoice will remain blank.

In this table a user can only have one record. They cannot be tied to multiple departments.

This MFF can also be used along side the DEPT_WHSE MFF. Both MFF will need to be set to Y. The program will check the Department Default from Reqn User Table first and if the program cannot find the user then it will then check the Department Default from Warehouse Table

If the warehouse on the purchase orders matches a warehouse in this table then it will assign that invoice to the associated department. If this fail checks and the user and the warehouse are not in either table then it will leave the invoice department blank.

This flag determines if the department on an invoice should be automatically gathered from the warehouse on a requisition. If a PO is automatically scanned by OCR, it will find the PO and allocate the department based upon the warehouse mapping rules set in the warehouse mapping rules.

Should the mapping filter out the commas during the mapping process. 

Define the tax group from the standard tax tables for GST.

This, if set to Y, will hide the Direct Code mode from the department screen.

Define the tax group from the standard tax tables for HST.

If this flag is turned on, the value of the invoice MUST match the value of the PO to authorize the invoice. This is primarily used when any variances will force the users to raise a subsequent PO/Req to ensure the values reconcile. 

This flag is only used when IAUTH_PO is in use. It allows the users to define a tolerance to accept if there is a variance.

This flag, should generally always be turned on in a tax processing environment. This allows for the user to edit taxes when allocating multiple POs to an invoice and posting the invoice. 

This will prompt for a GL batch date when posting from the validate invoices screen, opposed to taking todays date, if the flag is set to “Y”.

Warning to appear when PO Option for a variance has been escaped out of and there is a remaining variance amount. 

This flag allows for different approaches to matching multiple invoices to the same PO. 0 = Matching to a completed PO is aloud; 1 = Allows matching to a completed PO (status 90) but prompts with a warning; 2 = Matching to a completed PO is not aloud.

Because the invoice number is not completely posted to AP until the invoice leaves the validate invoices screen, this flag depends on the users certainty of the invoice number being finalized. This flag controls if a document register mode is available on this screen, if Y it is available, if N it isnt available.

This is because, when an invoice is in air, it posted to /VENDORCODE/INVOICENUMBER/

In the validate invoice screen, the user could change the invoice number. IE, an attachment is put to /VENDORCODE/INVOICENUMBER1/ and then a user changes the invoice number and posts it to /VENDORCODE/INVOICENUMBER2/, the attachments from INVOICENUMBER1 are going to be lost. 

If this flag is turned on, then standard GL masking will analyze the PO. If the PO is coded to GL codes the user does not have access to, they will not be allowed to action an invoice where the PO has already been matched. 

Furthermore, if this flag is on, in the PO search screen, the user will not be able to see any of the POs they do not have access to.

This is a preventative control to stop users from allocating other department's POs to their own invoices. 

Define the tax group from the standard tax tables for PST.

This will auto load the default GL code from the supplier into the invoice direct coding

Define the primary tax group. This is typically a composite when in a place that uses multiple tax codes, like GST + PST for example. 

If set to Y, the user will have the option to post Use Tax at the time of invoice authorization. This is only used in the United States. 

This is primarily used for a Finnish client who needs to provide an additional 30 character reference against their invoices for governmental purposes. This can be used by non-Finnish clients if needed. It is a 30 character field to provide more reference information on the invoice, like a government invoice ID etc. 

Provides user the ability to see or hide the “Mark Invoice” and “Post Marked” modes.

Value = “Y” will show the modes

Value = (blank) will hide the modes

This Major Function Flag is step 1 of 2 to set up a threshold for the system to allow/stop a certain invoice variance amount to be processed

This Major Function Flag has two options Percentage Based or Amount Based. If the user wants a Percentage based calculation when processing variances on invoices then they will put P in the value column. If they want an amount based or currency based they will put A in the value column.

This Major Function Flag works directly with VAR_THRES (Invoice Var Threshold Limit)

This Major Function Flag is step 2 of 2 to set up the system to allow/stop a certain invoice variance amount to be processed

Depending on if VAR_MODE is set on P or A will determine what the user will put in the VAR_THRES value field.

If VAR_MODE is set on P for Percentage then the user will need to put in what percentage of variance is allowed. If the value is 10, then the system will HARD STOP any invoice variance greater than 10%. 

If VAR_MODE is set up on A for Amount then the user will need to put in what amount/currency amount of variance is allowed. If the value is 200, then the system will HARD STOP any invoice variance greater than 200.

If there is an invoice variance when a user is processing an invoice they will be lead to the WARNING! Invoice Variance Exists Screen and will let the user know what variance is left on the invoice. 

Here if the VAR_MODE and VAR_THRES MFF are on it will determine if that Variance Amount is outside of the threshold allowed. If it outside of the allowed limit it will not let the user move forward with processing the invoice. It will give them a HARD STOP and let the user know they are over the limit. The only option that can be selected on this screen is M for multiple orders. The user will then need to add more orders to the invoice to get the variance inside of the allowed threshold. If the user gets the variance below the threshold then they will be allowed to move forward with processing.