1. Talking to each Other: RazorBuy and BASIS Integration Points

2. Take Aways Big Picture of RazorBuy and BASIS flow Purchase Requisition  Single or Multiple requisition(s) in BASIS Approval process – REQT PO integration Accounting integration Vendor integration

3. Big Picture RazorBuy flow and integration points

4. BASIS RazorBuy Log In Create PO Departmental Review (Optional) Departmental Review (Optional) Send Via: cXML EDI Email Fax Portal Send Via: cXML EDI Email Fax Portal Login Shop (Shopper) Create Req. (Requester) Approvals Create PO Transmit PO Create Requisition Target Chain Approvals Create Requisition Target Chain Approvals Relieve Commitment and Encumber Funds Relieve Commitment and Encumber Funds RazorBuy/BASIS Integration Big Picture Punch-out Catalogs Punch-out Catalogs Custom Forms Custom Forms Non-Catalog Items Non-Catalog Items Hosted Catalogs Hosted Catalogs Create Purchase Req Create Purchase Req PO Create PO Create BASIS Additional Approvals: IT, Trademark & Licensing etc. Additional Approvals: IT, Trademark & Licensing etc. Approved commitment created Outbound Sync: Vendors and Accounting Information

5. BASIS RazorBuy Log In Departmental Review (Optional) Departmental Review (Optional) Login Shop (Shopper) Create Req. (Requester) Approvals Create Requisition Target Chain Approvals Create Requisition Target Chain Approvals RazorBuy/BASIS Integration Big Picture Punch-out Catalogs Punch-out Catalogs Custom Forms Custom Forms Non-Catalog Items Non-Catalog Items Hosted Catalogs Hosted Catalogs Create Purchase Req Create Purchase Req BASIS Additional Approvals: IT, Trademark & Licensing etc. Additional Approvals: IT, Trademark & Licensing etc. Disapproved or withdrawn Outbound Sync: Vendors and Accounting Information PR status changed to Rejected and BASIS comment posted to history tab.

6. Building Requisitions Creating BASIS Requisitions from Purchase Requisitions

7. PR awaiting Approval or Rejection from BASIS The PR Validation to BASIS is the integration point to export the RazorBuy requisition to BASIS for TARGET approval

8. Building BASIS Requisitions BASIS requisition is created for each unique vendor on the purchase requisition. PR 54140127 – two vendors: Bio Rad and Bio Rad Laboratories BASIS requisitions: 543656 and 543657. Each requisition is approved (or disapproved) separately and all REQTs must be approved or disapproved before sending message back to RazorBuy.

9. LRSP - Finding PR’s in BASIS

10. TARGET General Information Policy

11. RazorBuy Roles Shopper – person(s) designated within your department to perform the shopping duties - adding items to a cart. Requester – person(s) designated within your department to create the purchase requisition. This person may also be a shopper. This person must have a BASIS (Admin) id.

12. Requester The Requester role in RazorBuy is similar to the requestor in BASIS. We require the RB requester to have a BASIS (or Admin) id so the reviewer can see who created the requisition. This person is considered the initiator of the transaction. We don’t allow the initiator to approve their own transactions.

13. Workflow options considered, but not chosen Maintaining workflow within RazorBuy  Limitations, such as not being able to manage substitute reviewers (proxies) and alternates Separating shopper and requester roles  Required requester’s position to be at or above a pay grade 13 (minimum level pay grade for a proxy) Developing a dollar threshold where certain purchases would not require additional review  Cost centers are not restricted by user or BU Developing a pre-approved list of cost centers within RazorBuy  Tremendous overhead to maintain Recording any departmental review within TARGET (i.e. if same person is approving in both places)  All users in RazorBuy would need a BASIS id

14. Approval Process To maintain good internal controls and oversight of departmental funds - the decision was made to export all RazorBuy requisitions into BASIS to utilize the TARGET routing for approvals.

15. TARGET Policy A minimum of two persons must be involved in the initiation and review of all TARGET financial transactions. Regardless of who initiates a transaction, no single person may perform all review steps unless there is only one required review step. The TARGET Administrator, in the Office of Financial Affairs, has the responsibility of establishing review chains, managing desk assignments, creating emergency proxy and alternate authorizations, and providing user training. A minimum of two persons must be involved in the initiation and review of all TARGET financial transactions. Regardless of who initiates a transaction, no single person may perform all review steps unless there is only one required review step. A Primary Reviewer or an Alternate Reviewer must approve all transactions that equal or exceed the materiality threshold established by the BASIS application owner. Proxies are not permitted for transactions at this level. Proxy approvals will be permitted for immaterial transactions below the established thresholds. An appropriate TARGET chain must be established to review material transactions. Transaction Approval (Fayetteville policy 330.1) - full Policy found at: http://vcfa.uark.edu/Documents/3301.pdfhttp://vcfa.uark.edu/Documents/3301.pdf

16. Review criterion for REQT Greater than $10,000 – Material Review. Approved by Primary or Alternate. Below $10,000 - Immaterial Review. Approved by Primary or designated proxy. Standing Orders (unlimited spend) – Material Review. Approved by Primary or Alternate.

17. Approval by initiator of the transaction The initiator or requestor of the REQT transaction is not allowed to approve the transaction. Except, where the review level is less than 500. The less than 500 level is normally, added to the TARGET for informational purposes. All TARGET approval chains have at least one reviewer at a level 500 or greater.

18. REQT - what happens? TARGET approval Rejection Withdraw

19. Link to RazorBuy Purchase Req

20. REQT – Pending Review

21. PF11 – Displays the Reviewers

22. Approved? Yes or No Once the all REQT transactions have been approved or disapproved for a PR, BASIS sends a Yes or No back to RazorBuy for each vendor/PR combination. Additionally, the transaction comment is sent to RB. Especially important if the REQT was disapproved so the requester knows why it was disapproved. A PR may have a mixture of approved and rejected lines.

23. BASIS Requisition Status Once approved, the BASIS requisition status becomes G (awaiting generation of completed PO assignment). If disapproved or withdrawn, the BASIS status becomes X (Cancelled).

24. REQT – withdrawn in BASIS If a REQT is withdrawn in BASIS, the transaction cannot be resubmitted. The integration will send through a rejection with a comment that it was withdrawn in BASIS.

25. BASIS Validations – Suspend or Reject PR doesn’t pass the BASIS validations – what happens?

26. Suspended PR There are a few validations errors that will cause a PR to suspend and not upload into BASIS:  Unit of Measure doesn’t exist in BASIS  No buyer set up for the PR’s BU  TARGET routing not established for a cost center distribution  UNSPSC code not available in BASIS Once the error is corrected, a BASIS requisition will be created.

27. Rejection of PR There are a few validations errors that will cause a PR to be rejected. The following are few examples:  Packed quantity exceeds the field size in BASIS (3.3 field size).  Date Desired is not valid. User typed in a date that was outside BASIS system dates.  Invalid Shopper ID  Invalid Requester ID (doesn’t match a valid BASIS ID)

28. PO Integration REQT approved PO created in RazorBuy

29. PO integration For all approved PR lines, RazorBuy will create a PO(s). The PO integration sends the PO number along with the vendor/PR combination. Basically, the BASIS requisition is used to build the PO using the number from the integration. The BASIS requisition status becomes C (PO Generated).

30. Accounting Integration BU Cost Center Categories

31. Accounting Info All Budgetary Unit (BU) number/Company Cost Center (CCC)/Category combinations are available in RB BU number is the parent and all associated company cost centers are the children. In turn, the CCC is the parent and associated categories are the children. The BU description contains the alpha code with hyphen before the actual BASIS description to assist our users with finding the BU number.

32. Accounting Integration Nightly, the accounting integration matches the previous day’s BU/CCC/Category combinations with that night’s combinations. All new cost centers are added via the integration along with associated categories and BU parent. If CCC inactive is the next day, the integration sends it as “active = false” and it is disassociated from BU and categories. Only MAINT and UTIL type categories are populated in RB. In other words, no salary type categories are populated in RB. Departmental Accounting Center (DAC) – the integration populates the categories for each CCC based upon what the DAC has assigned.

33. Accounting Splits In RazorBuy, the user will not be restricted when entering CCC/category combinations on the header or lines of the purchase requisition. When the PR is created, an RB workflow will “validate” the correct number of CCC/category combinations allowed: ◦Max of 10 CCC ◦Max of 5 different categories for a CCC

34. Accounting Distributions The Accounting distribution may vary between the purchase requisition lines. Accounting Splits may be by percentage or Dollar amounts.

35. Vendor Integration Nightly

36. Vendor Format Vendor Base + Vendor Name: 123456-01- All vendor addresses will be associated with each vendor base + vendor name Name will be reformatted – remove semi- colon and send as first name and last name Integration will add city, state, and zip as Fayetteville, AR 72701 when it’s blank in BASIS Integration will add area code of 479 when it’s blank in BASIS

37. Vendor Rules Active vendor with TIN source code of T (TSM verified) and Employee vendor (designated with employee id) – send all active addresses with address type of O (order) and R (remit) For inactive vendors in RB – must have at least one active address in RB so the last address will be coded as active, unless another active order address is available Ignore vendor addresses with a cXML order distribution type Cannot inactivate cXML addresses Obsolete addresses sent as inactive

38. Vendor Integration Only vendors with a TIN source of T or employees vendors are populated in RB. Nightly a comparison is run to pick up new vendors or addresses and inactive vendors or addresses.

39. Questions?