This page provides an overview of the current state and past state for purchasing.
Purchasing policies and supporting documentation requirements have not changed as a result of the transition to Aggie Enterprise.
| Previous State | Current State |
|---|---|
| There were two separate systems for purchasing, one for catalog purchasing (AggieBuy) and one for non-catalog purchasing (Kuali Financial System - KFS). | Aggie Enterprise is used for purchasing items from catalog suppliers, purchasing against existing university agreements and creating non-catalog and non-agreement orders. Catalogs continue to be the recommended and preferred way of purchasing, and catalog purchasing is available in Aggie Enterprise. |
| There was a Purchasing User role in KFS and a Requisitioner role in AggieBuy for creating Requisitions. | There is a role that allows users to create and submit catalog and non-catalog Requisitions and perform receiving functions. This role is similar to the Purchasing User role in the Kuali Financial System (KFS) AND the Requisitioner role in AggieBuy. |
| There were approximately 10,000 commodity codes in KFS. | There are approximately 200 purchasing category names from which to select for non-catalog purchasing. |
| Purchases in AggieBuy and in KFS started with a Requisition. | Each purchase in Aggie Enterprise also starts with a Requisition. The Requisition requires the approval of a department fiscal approver (PPM Project Manager or Charge Account Approver), and the fully approved Requisition generates a Purchase Order. |
| Purchase agreements were available for use in AggieBuy and in KFS. | Customers are still able to order from many of the same suppliers they previously used in AggieBuy, as well as purchase from the same university purchasing agreements they used in KFS. |
| Historically, Departmental Blanket Agreements were set up on the Agreement Request document in KFS. The department purchased against the blanket agreement by citing the Agreement Number of the fully approved Agreement Request document on their Requisition document. | Departmental Blanket Requests are established on a Requisition document. Once the Requisition is fully approved, the department can cite the approved Purchase Order when contacting the supplier to make purchases, and the supplier will invoice accordingly. |
| Accounts could be split by quantity or percentage of total order amount. | No change. Users are still able to split accounts by item quantity or by percentage of total amount of order. |
| Users could use an existing Requisition as a template for a new one. | There is a duplicate functionality available for copying a previous Requisition and adding multiple item lines to a Requisition at one time. |
| Purchases of restricted goods (e.g., controlled substances) and purchases over the delegated Automatic Purchase Order (APO) limit not citing a purchase agreement routed to and required the approval of a buyer in Procurement & Contracting Services. | The following route to and require the approval of a buyer in Procurement & Contracting Services:
|
| In AggieBuy and in KFS, users could identify default delivery locations and and accounting codes. | There is a Requisition Preferences screen, which allows users to set up default accounts ahead of time, as well as give each of those accounts its own "nickname," making it easier to process purchases without having to search for an account each time! The Requisition Preferences screen also allows users to easily save their most frequently-used delivery location. |
| The Requisition validated whether the referenced agreement has sufficient funds and does not allow it to be submitted if there aren't sufficient funds. | In Aggie Enterprise, a user can cite an agreement on a Requisition even if it has no balance, and the Requisition will submit successfully. An insufficient agreement balance prevents a Purchase Order from being created. The buyer in Procurement & Contracting Services works with the department to add funding to the agreement as appropriate. |
| Change orders were initiated via the Purchase Order document in KFS. | The ability to initiate and process change orders is initiated via the Requisition document, and not the Purchase Order. |
Purchase Order numbers started with:
Purchase Agreement numbers start with A (e.g., A71726) |
|
| The Online Pre-Purchasing (OPP) System interfaced with KFS and AggieBuy. | The Online Pre-Purchasing (OPP) System interfaces with Aggie Enterprise. |
Non-Purchasing Agreements (NPA) Information
Users in central departments with very specific purchasing needs could create Requisitions in the Kuali Financial System (KFS) known as Non-Purchasing Agreements, or NPAs, that bypassed approval from Procurement & Contracting Services.
Previous KFS users with the KFS_NPAUSER role have been given access to create the following documents in Aggie Enterprise that behave much the same way as the NPA did in KFS.
- Restricted – Delegated Purchasing Use Only – Rate Based
- Restricted – Delegated Purchasing Use Only – Quantity Based
These documents:
- are restricted to only those commodity types that could previously be acquired via the NPA process, with a drop-down menu of Category Names that limit the user to a pre-defined list of commodity types,
- require approval from the PPM Project Manager or chart string approver, as well as Capital Asset Accounting for some of the specified commodity types,
- do not require Procurement & Contracting Services approval, as was the case with the current NPA process, and
- generate a Purchase Order once all required approvals have been secured.