iBuy

Access

All users requesting access to iBuy will need to have it provisioned via Security Application. This process will follow the standard system access protocol with users reaching out to their Unit Security Contact (USC) with an access request.

Identify iBuy Users

Those employees who currently use PCards and/or requisition/approve purchases in Banner are prime candidates to use iBuy. However, any University of Illinois System employee involved with procuring goods and services in the course of official system business may also use iBuy. This includes faculty, staff, and even student employees, such as lab and research assistants.

Once those employees who will use iBuy have been identified, the next step is to determine roles as appropriate (see below).

Best Practice Tip: Decentralize transactional activity to the organizational level at which purchasing decisions are actually made. iBuy's ease of use, workflow functionality, and reporting capability are well-suited to support such decentralization.

Departmental Approvals

Departmental approvals are one aspect of iBuy's overall approval process. As such, it is a control point that deserves attention as departments begin using iBuy.

When assigning Approvers, departments should consider which staff will be responsible for reviewing and approving the orders of others on a routine basis. Such users should be given sufficient approval authority to handle approving the most common orders. In addition, consider who will need to look at larger orders and provide those users with a higher level of approval authority. A hierarchy of approval levels will allow for appropriate allocation of workload while ensuring that large purchases are presented for review by more senior or experienced staff.

The following approval queues are available for departmental use:

$0 - $4,999 (Optional)
$5,000 - $9,999 (Optional)
$10,000 - $49,999
$50,000 - $249,999
$250,000 - $499,999
$500,000 - $999,999
$1,000,000+

Best Practice Tip: Include at least two individuals in each approval queue to address the possibility of unplanned absences.

Roles

There are certain combinations of roles within iBuy that are not allowed. Please see iBuy Access: iBuy Role Matrix to review role compatibility.

There are Internal Controls that prohibit certain role combinations of roles between iBuy, Fabweb and Biennial Inventory. Additional information can be found at Internal Controls: Prohibited Role Combinations and iBuy Access: Internal Controls - iBuy Roles Explained

Each user in iBuy has specific roles that define what the user is able to do in the system. Below are the definitions that might help you better understand iBuy roles.

Shopper

Can do everything necessary to create a requisition and submit it for approval EXCEPT adding C-FOAPAL information. When a Shopper submits a requisition, it moves into the Department Account Coder (DAC) queue for their assigned Chart/Org so the C-FOAPAL information can be entered. Generally this role is not combined with any other role.

Requestor

Can do everything necessary to create a requisition and submit it for approval INCLUDING adding the C-FOAPAL information. When a Requestor submits a requisition, it moves into the Approval queue linked to the Chart/Org entered within the C-FOAPAL information. This role can be combined with the DAC or Approver roles. However, it is University best practice for the same user to not create and approve the same requisition.

Department Account Coder (DAC)

Can add C-FOAPAL information to complete a requisition initiated by a Shopper. Once the appropriate C-FOAPAL information has been entered and the requisition submitted, it then moves into the Approval queue linked to the Chart/Org entered within the C-FOAPAL information. There may be more than one DAC within a queue for a particular Chart/Org. This role can be combined with the Requestor or Approver roles. Advised to have at least two people assigned to the role of DAC in each department.

Approver

Can approve, reject, edit, return or forward a requisition within their approval queue. The Approval queues are set up by dollar ranges with a particular Chart/Org. There may be more than one Approver within a queue for a particular dollar range and Chart/Org. This role can be combined with the Requestor or DAC roles. Advised to have at least two people assigned to the role of Approver in each department. However, it is University best practice for the same user to not create and approve the same requisition.

Executive Approver

Can only approve, reject, forward, or return requisitions (but not edit them) within their approval queue.

Query Only

Can only review requisitions, purchase orders, and invoices for validation of account or report reconciliation. Unable to perform any other actions on a requisition. This role cannot be combined with that of a Requestor.

Invoice Acknowledger

Can approve, return, or forward invoices within their approval queue. This role will only acknowledge invoices totaling $50,000 or more on vendors set up with e-invoicing. For a list of these vendors please see types of vendors. This role can be combined with the Requestor or Approver roles. Advised to have at least two people assigned to the role of Invoice Acknowledger in each department.

Hospital Requestor (UIC Only)

Some iBuy users at the University of Illinois Hospital & Health Sciences System have the Hospital Requestor role. The Hospital Requestor role is similar to the Requestor role but includes Materials Management review as an additional step in certain workflows. Hospital Requestors use the Route to Materials Management form instead of the Route to Purchasing Form. Also, Hospital Requestors have access to a subset of hosted and punchout catalogs.

Requisition Workflow

The requisition workflow based on the role of shopper.

1. Shopper creates Requisition
2. DAC enters C-FOAPAL
3. Approver Reviews

The requisition workflow based on the role of requestor.

1. Requestor creates Requisition
2. Approver Reviews

Results of the requisition based on actions taken within the workflow:

• If the requisition is approved, PO is created and sent to the vendor.
• If the requisition is returned, the order will return to the Draft Cart of the individual who created the requisition. The issue that caused the return can be corrected and the order resubmitted.
• If the requisition is rejected, a PO is not created and order is no longer valid.

Vendors

Catalog Vendor Types

Hosted Catalog

Hosted Catalog vendors have static lists of items and prices negotiated by one of the University Purchasing offices.

Punchout Catalog

Punchout Catalog vendors have a specialized vendor website within iBuy that contains items and prices negotiated by one of the University Purchasing. When the user is done shopping, they checkout from the vendor site and returned to iBuy to complete the requisition process.

Non-Catalog

Non-Catalog vendors do not offer a hosted or punchout catalog within iBuy. Orders are placed with these vendors using the Purchase Requisition or Standing Order Form.

Types of Vendors

Suppliers

The party has a Banner Vendor profile that is synced into iBuy. The party will display with a green check to indicate Active For Shopping. This means that they are for selection on a requisition. This is the party type required for Payable and Hybrid contracts and can also be used for No Funds or Receivable contracts.

See iBuy Vendor: UPAY - Adding a Banner Vendor to iBuy for additional information.

Customers

The party can be used for No Funds or Receivable contracts. The party will display with a red x to indicate Inactive For Shopping. This means that they will not be available for selection on a requisition.

See iBuy Contracts+ General - Searching For and Establishing Second Parties for additional information.

Requesting a Vendor to be added to iBuy

If the transaction will be a Requsition, a Payable contract or Hybrid contract, use the Vendor Information Form using Adobe Sign (VIF) found at Vendor Payment Forms.

If the transaction will be a No Funds or Receivable contract, use the Second Party: Customer Information Form using Adobe Sign found at Purchases Forms.

Note: If the Second Party sends the completed form to you instead of following the recommendations in the form, submit the form via email to OBFS UIVendor at uivendor@uillinois.edu.

Process

Vendor Information Form (VIF)

You will be emailed by Vendor Maintenance once they have completed the vetting process and approved the Vendor Information Form (VIF). They will provide the assigned Banner ID.

The Second Party will display in iBuy with Contract Party Type: Supplier and available for use on requisitions and contract requests.

Second Party: Customer Information Form

You will be copied on an email from Vendor Maintenance once they have completed the vetting and approved the Second Party: Customer Information Form. AITS iBuy Production will respond to the email once the Second Party has been added to iBuy.

The Second Party will display in iBuy with Customer Party Type: Customer and available for use on the Contract Request.

Banner Integration

iBuy integrates with Banner, which remains the university's financial system of records.

PO Numbers

Purchase order numbers in iBuy are generated in Banner EXCEPT when the purchase is made with an internal vendor (iBuy PO number).

Accounting Codes

iBuy users can enter full CFOAPALs or Index codes to allocate purchase costs. The codes available in iBuy will be synchronized with and validated against those available in Banner.

Encumbrances

Purchase orders created in iBuy encumber the selected funds in Banner EXCEPT when the purchase is made with an internal vendor.

Payments

University Payables processes in Banner all payments against purchase orders created in iBuy EXCEPT when the purchase is made with an internal vendor. In the latter case, the internal vendor processes a charge back to the FOAPAL(s) provided in the iBuy purchase order.

Financial Reports

Encumbrances and payments based on iBuy purchase orders appear in the standard financial reports generated out of Banner.

Ship To Addresses

Must be established in Banner to be used in iBuy.

Vendors

A vendor must be established as an e-procurement vendor in Banner to be used in iBuy. When searching on a non-catalog form, if you cannot find the vendor you are searching for, please review the job aids for assistance.

Commodity Code

For catalog items, iBuy automatically provides commodity codes to Banner. For non-catalog items, users need to select the appropriate commodity code from the Commodity Codes.

iBuy Reporting

iBuy's History tab gives users the ability to search on requisitions and/or purchase orders created against their Banner Chart and Level 5 (3-digit) Organization code, e.g., Chart 9 - Organization 123.

Searches can key on:

• requisition number,
• requisition name,
• purchase order number,
• supplier name, or
• catalog number.

And there are multiple ways to filter search results, including date parameters and the current status of the requisition/purchase order.

Whether as public (meaning it's available to any iBuy user) or private (meaning it's only available to the user who created it), any search performed in History can be saved as a query to streamline any future use of that particular search.

Users also have the option to export the results of History searches or queries as CSV (comma separated values) files into other applications, such as Excel. This feature offers a simple, straightforward way to integrate other tools outside of iBuy in order to enhance further users' ability to track, evaluate, and report their spending.