This flag controls if a user can approve their own requisition if the requisition is within their dollar limit. 

N=no

Y=Yes

Typically this should be set to N to ensure a proper segregation of duties.

Turning this flag on, will change the workflow of requisitions in RAPS.  

Y=yes

N=no

Instead of flowing directly to the approval tree, it will send the requisition to a group of users who have been assigned the auth code ‘????????????’ which signifies they are buyers. This step will occur BEFORE the req routes for any approvals in the approval tree. The buyer will use the “Requisition Approval/Review” screen (ZRAP.M003) and will have specific mode options at the top to perform their functions.

This function is typically set to Y=yes.

Note: If the ‘Cost Controllers’ flag is also set to Y=yes, then this step will happen after the cost controllers step, but still before the approval steps.

The details of this functions are further outlined in the article here; Requisition Approval/Review - Buyers (add link)

This flag is cannot be changed, unless the ‘Requisition to PO Officer’ flag is set to Y=yes, and if the ‘Req to PO Officer’ is flag is set to N=no, then the this flag will auto update to N=no as well.

This flag will send any requisitions revised by buyers back to the original requisition raiser to acknowledge any changes and then will send up to the approval tree. This allows the end user to provide any comments or notes prior to sending it up the tree and to ensure they are happy with the changes Supply Chain has made.

This flag is typically set to N=no.
 

Note: Revised is the terminology used by RAPS when a Buyer “approves” a requisition to move forward in the process.

This flag controls what happens when a requisition is converted to a purchase order. In standard Pronto, when a requisition becomes a PO, the system checks the dollar levels of the user for STOCK and NON STOCK in the standard officer table. 

This conversion can happen manually or automatically depending on the MFF ‘Auto Convert to PO’.

If set to Y=yes, this will allow a user to set a PO to status 30 when approving a requisition regardless of their dollar limits for purchase orders. It simply uses the users requisition limit and will then allow the process to skip the PO status 10 approvals.

Most clients will have this flag turned on as the PO approval, once a Requisition has been approved is largely overkill and outside of the needs of their segregation of duties matrix. 

If this flag is set to Y=yes, then when a requisition is revised by a buyer, it will bypass the whole office table workflow tree and finds the person within the requisition raisers queue who has the $ value available to make the final approval.

Note: This function works in tandem with the MFF “Requisition to PO Officer”, and will only trigger if the buyer revises a requisition, not when the user enters the requisition.

See additional details on this function here; Escalate Req upon $ on Revised

If this flag is set to yes, and the buyer has requisitions to be REVISED in their tree, then the buyer will be able to edit the requisition in full prior to revising it. Most clients have this function set to Y=yes if the Requisition to PO officer table is set to Y.

Note: This flag works in tandem with the MFF “Requisition to PO” officer being set to Y=yes.

This MFF controls if a requisition that has been rejected for any reason is then resubmitted by the originating user, if that req then needs to go back to the PO officers for review before going into the approval workflow again, even if the PO officers has already reviewed it.

Y=yes

N=no

If it is set to N=no, the requisition will go to the 1st approver above the end user upon resubmission, and skip the PO officer.

Note: This MFF is typically used in the scenarios where the MFF “Requisition to PO Officer” is also set to Y=yes.

When this MFF is set to N=no, when the final approval is completed, users will see the below options; Approve & Approve and Convert.

Using Approve will set the final approval and then route back to the buyers for final conversion to a requisition.

Using the Approve & Convert option will set the final approval and auto convert the requisition into a purchase order status 30=ready to print.

If this MFF is set to Y=yes, then the above options will NOT display, and the final approval will simply convert the requisition to a purchase order status 30=Ready to Print . Most clients have this set to Y.

You may want this set to N=no if the buyers want a final chance to review the order and potentially merge multiple requisitions from the same vendor into a single purchase order.

See the Convert Approved Reqs article for more details on the manual conversion process by the buyers.

If this flag is set to Y=yes, then it will automatically convert/print/receive any requisition which is raised as a DIRECT INVOICE. Please see below in section ‘Commitments’ more details on the MFF “Direct Invoice”.

Note: If this MFF is set to Y=yes, then the MFF “Direct Invoice” must also be set to Y=yes

If this MFF is set to Y=yes, several details from the data grid will be hidden on the Requisition Approval/Review (ZRAP.M003) screen.

This is continually evolving with each versions of RAPS and is a preference for the client. 

Currently the screen will remove the below information from the data grid;

Project/GL Account - Charge code from the first line of the order

GL Description - Description of the GL account if used

Project Description - Description of the project if used

Project GL Rollup - GL account tied to the project if used

Status - Status code of the requisition

Description - Status description of the requisition

Purchase Order Notes - PO notes added to the header

Level 1-4 Acknowledgement Users - Users who has previously acknowledged this req

Work Type - Work type code of the work order, if a work order was used to charge

Description - Work type code description

Plant Item - Plant item associated with the work order, if a work order was used to charge

Plant Description - Plant item description

Project Branch - Branch code of the project, if a project was used to charge

Branch Description - Branch code description

Most clients opt to set this to Y=yes. Clients are able to turn this on and off without any other functional impacts other than the modes listed above showing.

Note: Even with this MFF set to N=no, the standard Pronto data grid management tool can be used to hide columns as needed.

If this flag is set to Y=yes, then it will check the value in the MFF ‘Allowable PO Change Amount’. If the change is within this dollar amount, then the PO will not revert back to a requisition status. If it is greater than this amount, it will revert back to a requisition and will need to be reapproved through the approval workflow.

Note: This flag only controls orders that originated as a requisition, not for direct purchase orders. Direct PO should be controlled by standard Pronto.

Enter the allowable tolerance, in dollars, that a purchase order originated from RAPS can be changed before it needs to be reapproved. 

There is significant impact on the process if the Budget Variance Approval flag is set to Y=yes. Every single requisition raised will check the GL or Project it is being raised against and will then be flagged as UNBUDGETED if the requisition will send the GL or Project over budget. The amount of the budget overage will determine if a user can or cannot approve the requisition by checking a separate approval limit for unbudgeted. 

This limit is controlled in the RAPS Limits table (SYS.M143).

For a more detailed summary of this function please see article; Budgeted/Unbudgeted Function

If this flag is set to Y=yes, then it will allow users who have access to Direct Invoice Mod (ZPSA.S001) to set a field on the requisition header called “Direct Invoice” to Y=yes or N=no.

A direct invoice requisition is typically classified for an invoice that would not typically require a purchase order (legal fees, leases, phone bill, etc..) but the business requires the requisition to satisfy the approval process for the invoice.

This is primarily used in corporate environments where a clerk entering the requisition on a users behalf by updating the buyer name on the requisition and setting the DIRECT INVOICE field on the requisition entry header to Y=yes. It effectively removes the need to receive services and puts the approval in place as the receiving process to streamline the P2P process. 

Once the user approves the requisition, the approval process will automatically perform the below actions;

• Convert the req to a PO = Status 30
• Print the PO = Status 40
• Receive the PO = Status 60
• Update the PO = Status 70

If this MFF is set to Y=yes, then when a user enters details into the ‘Supp Code’ field below, the system will cross reference this to the APN field on the inventory master record and alert the user that this item can be procured from the site warehouse. 

Note: This must be an exact match.

Exceptions to this alert can be managed in the below function Matalin APN Overrides. Specific users can be set for a certain period of time to ignore this.

If this flag is set to Y=yes, then the default entry methodology for entering PO notes on a requisition changes to a word pad. Users can enter as much text as they like in the single word pag.

This will automatically insert lines into the requisition based upon the text entered into the word pad and Pronto's standard 30 character limit per row.

If this flag is set to Y=yes, then when a requisition is raised directly from a work order under PURCHASES → NEW PURCHASE REQUISITION, the lines of the work order and the asset information will be PRE-ENTERED into the requisition as a MEMO type line.

This flag must be set to Y=yes to use the Contract Module Screens.

This flag must be set to Y=yes for the other flags to be accessible and will allow access to the Expediting Maintenance (ZPO.M002) screen.

If this flag is set to Y=yes, then the labels in the section ‘Order Dates’ on the Maintain PO Header screen will change to these values. The required date will also be set to “Promised Date”.

• ETD: Estimated time of delivery (at warehouse or consolidated warehouse)
• ETA: Estimated time of Arrival to end user
• ATA: Actual time of Arrival

If this flag is set to Y=yes, then on requisition entry, the date fields on the header will be suppressed and unable to be edited by the end user. 

This is a dynamic label that will override the label of “Buyer” on the order header screen. This eliminates the need to use any custom proscreens.

If this flag is set to Y=yes, then the PO (NOT requisition) header will have an additional type field for end users to maintain. This is stored in the XP system table. 

If this flag is set to Y=yes, then when the buyer is on the requisition maintenance screen, prior to revising a req, they can edit the promised date from this location by line.

The module is turned on by setting this flag to Y=yes. 

Any requisition raised over this value will be flagged as an RFQ type of order.

Any requisition raised over this value will be flagged an an RFP type of order. 

This flag must be set to Y=yes to use this function. 

This module will allow users to enter 0 dollar requisitions and it will progress to the buyer. The buyer is able to print the quotation, add email information for the vendor, and transmit a request for quotation to the vendor out of the system that the vendor can respond to as per the RFP/RFQ module above. 

Note: If this MFF is set to Y=yes then the MFF “Resubmitted reqs always to PO officers” and the MFF “Requisitions to PO officer” must both also be set to Y=yes. 

This determines the number of quotes each submitted requisition will generate in Pronto. 

This can be set to 0 if the buyer's prefer to simply print a generic quote and manually send to as many vendors as they like.

If this flag is set to Y=yes, the end user will not have the option to select a vendor on the requisition entry screen and will be forced to leave this field blank.

This field will automatically give each RFP/RFQ "x" number of days for the vendor to complete the process for the RFP/RFQ. This can be changed by the buyer on the approval screen if needed. 

Example: If the Dynamic Days is set to 5, then the supplier has 5 days to submit intent to quote/bid and provide supporting documentation. If the process is not complete in 5 days then that supplier will be rejected from that specific RFP/RFQ.

If this flag is set to Y=yes, then when the requisition is approved the order will auto print the PO form and set the purchase order to Status 40=On Order.

When this flag is set to Y=yes, this function will trigger a pop up prompt after the revision mode is used during the buyers review step. 

This prompt will ask the buyer if they would like to email the buyer upon conversion. 

If YES is selected it will automatically email the supplier (using the email address tied to the supplier master record for purchase order communications) once the Req has been approved, which will then update the order to Status 40=Open Order. It will also BCC the buyer on that email.

If NO is selected it will automatically email the buyer once the Req has been approved which will then update the order to Status 40=Open Order.

This Major Function Flag will simplify the amount of fields that are shown on the REQ Lines. This will help with newer users using the system. Please see below the differences.

Simplify Line Fields Set to N. Highlighted fields are removed when MFF is set to Y

Simplify Lines Fields set to Y

This Major Function Flag controls the emails that go to the originator of the purchase order. These emails are to notify the user when the order has less than the given percentage remaining. The purpose of this, is to let the user know in case there needs to be a change order, or another PO created for the vendor.

With the Remaining Balance set to Y it will activate the emails. The company can select when they want the users to be notified by the percentage left on the purchase order. 

Once the remaining balance of that purchase order hits the percentage threshold a notification will be sent out to the originator. This email can be customized.

This makes PO Notes Mandatory on the header of the REQ. With this MFF set to Y the user will have to select notes that are populated in the UA Table to continue to the lines on the REQ. These notes will also appear in a column on the Buyer Approval Screen. Companies can you use this for priority, departments, etc.

When entering a requisitoin the user will get a hard stop if no notes are added to the Notes Field

The user can press f2 or click on the magnify glass to view the notes that can be selected. These notes are populated in the UA Code Table

Once PO Notes are populated the user can move forward to lines. These notes will populate on the Req Approval Screen for the buyers to give the users more information about the requisitions entered.