Get documents about "RB Working Doc 041912
Document Sample
Value Timeframe
Short Up to 3 months
Term Mid 3-12 months
Long 12+ months
Short Up to 3 months
Implementation
Mid 3-12 months
Timeline
Long 12+ months
1 N/A
Execution 3 N/A
Complexity
5 N/A
1 N/A
3 N/A
Business Impact
5 N/A
Definition
Arkansas is able to start working towards this recommendation within the next 3 months. There are
few barriers to begin implementing this recommendation.
Arkansas is able to start working towards this recommendation within the next 3-12 months. There
are several barriers to begin implementing this recommendation.
Arkansas is able to start working towards this recommendation within the next 12+ months. There
are a significant number of - or extremely complex - barriers to begin implementing this
recommendation.
Implementation will take up to 3 months.
Implementation will take between 3-12 months.
Implementation will take 12+ months.
There is little to no organization, time, cost, change management, supplier complexity or risk in
implementing this recommendation.
There is a moderate amount of organization, time, cost, change management, supplier complexity
or risk in implementing this recommendation.
There is a significant amount of organization, time, cost, change management, supplier complexity
or risk in implementing this recommendation.
This recommendation will have some positive impact on the business either operationally,
financially, or organizationally.
This recommendation will have a moderate amount of positive impact on the business either
operationally, financially, or organizationally.
This recommendation will have a significant positive impact on the business either operationally,
financially, or organizationally.
Section R# Recommendation UA Response & Rationale Final Outcome
Re-evaluate solution design options against project components: time, We chose a hybrid of both options. We will
cost and functionality. This includes workflow configuration, keep the Buyers as a part of the workflow in
functionality (i.e. the ability to assign a substitute approver or forward Decision was made to go with Option B., with the RB and the dept's can chose to be a part of
Solution a requisition to another approver), and integrations. See Solution exception of keeping the Buyers review in RazorBuy the departmental workflow in RB (this will
Design 1 Options for details. before the transaction goes to BASIS for approval. be BU driven).
Buy and build a user profile synchronization to more effectively and
efficiently maintain user information in SciQuest and reduce security
risk for the University. The Shopper role could be synced over in the We recognize we need to make a decision on which
integration or could be handled through a separate registration route we want to take. We will make this a priority topic
Integrations 30 process. See subsequent slide for solution concept. as this could impact the timeline.
Define and document processes for manually onboarding, maintaining
and inactivating users. Arkansas should consider if both training and
written authorization will be required for onboarding. If both are
required, additional work effort will be needed for the initial role
allocation per user. Ongoing, Arkansas could develop an offline
approval process or could leverage a form in SciQuest that would route We recognize we need to make a decision on which
to the Department for approval (as depts want to be able to determine route we want to take. We will make this a priority topic
Integrations 29 who gets access) and then to the system administrator for setup. as this could impact the timeline.
UA needs to clean the vendor master in BASIS to ensure order
addresses and remittance addresses are correct and accurate in the
Integrations 32 system We agree we will address this issue. WIP
We believe it is critical that the buyers work in the same
Drive workflow in one system (see also Solution Options) to make the system as the end users, due to the efficienies in that
process as efficient as possible. The goal is for RazorBuy to be the path design and the integration of the RF/X module into our Done. Buyers will be in RB. BU's can choose
of least resistance while maintaining proper controls for purchasing Higher Markets product. Financial workflow will remain if they want Approvers in RB. Financial
Readiness 38 goods and services. in BASIS. workflow will remain in BASIS.
Identify 15-20 key campus stakeholders that represent faculty and
departmental business offices to function as the project’s core user
group. These resources will function as change agents within their
respective departments, provide insight into critical business processes We agree. In our user acceptance testing we will Heather will engage a small group of end
to help shape solution design, support user acceptance testing, and act identify key campus stakeholders to be trained first and users to review documentation and
Readiness 41 as a first line of help desk support during post-production support. utilize them as change agents. participate in some RB testing.
Develop a communication framework to plan communications for the
duration of the implementation and through post-production support.
The communication framework should consist of both proactive
communications and reactive communications. See previous slide for
Readiness 42 example. Yes, we agree.
4 11/16/2012
Section R# Recommendation UA Response & Rationale Final Outcome
Develop a Business Process Transformation (BPT) plan that includes a
change management resource leading an effort to work with individual
departments on process re-design. Requirements can also be gathered
through these departmental sessions to ensure all reasonable process
and data requirements for reporting purposes are documented and
implemented (if possible). High-volume, sensitive or highly influential The accounting data is not going to change. How the
departments should be prioritized in this effort. See subsequent slide dept's utilize the data in Razorbuy or the data
Readiness 40 for details. warehouse will be addressed after implementation.
Arkansas needs to define and document how tax will be managed on
the PO and how that will be reflected on the invoice (i.e. header vs
Solution line). Determining how to allocate tax charges across lines and Yes, we agree and we need to test to ensure the PO is
Design 21 distribution lines will also be required prior to the invoice export build. reflecting the way the Req is setup.
We had not considered PO changes in the scope of
phase 1 implemention. We agree that this will cause the
two systems to have different data. We wish to have
futher discussion with Huron to determine the most
See Solution Options. If Solution Option B is implemented, create efficient method of synching the two systems in terms
change orders in BASIS and push PO updates to RazorBuy allowing for of data. This could also have relavence in the discussion
Solution the change order to not be dispatched if change does not need to be of the final payment data between the two systems as
Design 3 sent to the supplier. well. Goes with R# 2.
Arkansas should define how POs, PO-related documents and electronic
invoices will be retained (i.e. is SciQuest sufficient or is documentation
in another imaging tool needed). An additional integration may be
Solution necessary if Arkansas requires these documents to be retained in their Yes, we agree this is an issue and we are actively
Design 22 imaging system. pursuring a solution.
Develop test plans and corresponding test scripts for unit testing,
validation testing and user acceptance testing to reduce operational
risk at go-live. Arkansas should be responsible for developing and
successfully executing these test plans. Errors and failures should be
documented and reported to SciQuest as needed. Error resolution
should be thoroughly understood by the Arkansas system
administrator, functional representative or technical lead and proper
documentation should be maintained. This will provide greater stability
and efficiency in troubleshooting issues during post-production The model we have successfully used is a sharing of
support. SciQuest can provide a baseline test plan to which UA can add responsibilities between IT and the functional user. We
additional scenarios unique to UA’s integration design and business will continue to use this model. We will develop a plan
Integrations 27 requirements. for testing and we agree this is an integrual component.
5 11/16/2012
Section R# Recommendation UA Response & Rationale Final Outcome
*Agree we have a need for Change
Develop clearly defined roles and responsibilities for the duration of Management/Communication to be addressed, cannot
the project as well as post-production support. Arkansas should review create a role just for this. Need to determine how best
current outstanding decisions and tasks and assign them to the to fill this need. *We have reservations on
appropriate project role. Deadlines and expectations for task implementing a new Project Steering Committee as this
completion should be clear and documented within the Arkansas would impact the current timeline. *Testing will
Project project team as well as the SciQuest project team. See subsequent slide primarily be done by Purchasing, Accounts Payable,
Organization 46 for details. Vendoring, and Training.
Develop a standard template and format for project documentation
including a business decision log, risk register, critical path analysis and
key successes. A standard project status update should also be
Project developed and distributed on a recurring basis. See subsequent slides
Organization 47 for details. We agree. We will document these tasks/decisions.
Consider automating the change order process in RazorBuy to ensure
purchase order data is congruent between two systems. Arkansas
should explore one of two options for change order processing as an
alternative to processing change orders in BASIS alone: 1)Work with
SciQuest to automate the change order process during the PO Export
integration design and build. 2)Utilize SciQuest's custom form
functionality to create and route PO change orders. These changes
could be routed for approval before being manually entered/updated
in BASIS. This would be a manual work step (vs automation of change Do we need the ability to update/make
Solution orders in BASIS) but would provide congruency of PO data between changes to PO's in RB in Phase I? If so, we
Design 2 RazorBuy and BASIS for audit purposes. Option B was selected. need some "PO change order" capability.
As a part of the SciQuest/Arkansas contract, SciQuest will create five
custom forms for Arkansas for go-live. To date, all five custom forms We have not developed any custom forms yet. The
Solution have been developed: After-the-Fact, (i.e. Invoice Attached), Personal forms currently in the Razorbuy test system are canned
Design 3.1 Reimbursement, Business Cards, Catering, and Sole Source. forms used as samples.
The Procurement Dept has re-addressed this
issue and is already seeing a reduction in
these transaction types. Buyers requested
that a written policy be posted on the
Procurement website or sent out to the
Reduce the volume of Invoice Attached and Personal Reimbursement University via a list serve to reinforce the
transactions (9,750 and 4,149 transactions in FY11, respectively). This expectation with end users and give buyers
can be done by implementing policies around these types of We recognize the need to reduce these types of documentation to refer to. Linda will type up
transactions, such as stricter approval flows including senior transactions. We will continue to take steps to reduce a policy and f/u with Jim to determine the
Solution executives, and/or by creating a more efficient process through which the current level of usage. A UA policy directive may be method of communication. This will be
Design 4 to buy and pay for goods and services. discussed in the future to address these issues. completed by the end of the week, April 13.
6 11/16/2012
Section R# Recommendation UA Response & Rationale Final Outcome
Prioritize and balance custom forms based on critical business need
and purchasing strategy. For example, Arkansas may not want to
accommodate blanket orders in RazorBuy as a way to strategically
reduce the volume of blankets, however business processes may
dictate the need for (limited use) blankets (i.e. Construction).
Commonly, blanket order requests are routed through Purchasing at all Agreed. We need to have a meeting just for
Solution dollar levels to allow for close monitoring and potential rejection of forms. All forms will stop at a buyer, unless
Design 5 this order type. We agree. otherwise determined.
Leverage SciQuest’s internal notes capabilities on a requisition to
support internal audit requirements, specifically around the evaluation
of the business purpose of a requisition (i.e. Personal Reimbursement).
Business Purpose could also be placed on the requisition as a custom
field if it needs to be brought into BASIS or be reportable. This should We agree. We intend to use the internal notes and
Solution be incorporated into end user training documentation and course attachments capability. As we identify custom fields we UNSPSC code information plus the product
Design 6 curriculum. need to capture from Razorbuy to BASIS we will. description will meet this need.
Consolidate forms where possible and consider three key factors when
developing a custom form: 1)Does it need to create an encumbrance?
Solution 2)Does it need to be different and distinct workflow? 3)Does it need to We agree we will consolidate forms where possible. We
Design 7 be distributed to the vendor? would like further discussion on this topic. We need to have a meeting just for forms.
Develop consistency in form design and layout to alleviate user
confusion. Utilize and require delivered fields for base values, such as We agree. We have not developed any custom forms
Description, Price, and Quantity, to ensure these values are reportable. yet. As we identify custom fields we need to capture
Other fields such as catalog number, manufacturer, etc. should not be from Razorbuy to BASIS we will. We would like further
Solution required fields. Custom fields cannot be utilized to populate these discussion on the custom fields mapping as sub-line
Design 8 delivered fields but can be mapped as sub-line values (see example). values. We need to have a meeting just for forms.
Review and chart permissions per role to ensure users do not have
unnecessary or incorrect privileges within the system. Ensure that
Solution these permissions are thoroughly tested during validation and user
Design 9 acceptance testing. We agree. We will do this. This is a management decision.
Solution Reconfigure the homepage layout to ensure that all catalog suppliers
Design 10 are visible and most frequently used forms are easily accessible. We agree. We will do this.
Summarize the list of commodity codes and commodity code
descriptions (vs the actual code) to provide a more user-friendly
experience. Map the short list of commodity codes to the UNSPSC. This We have some specific needs in the tax area that
Solution allows a roll up of commodities for spend analysis but still allows a require more extensive codes in our non catalog forms. No, we're not changing this process. We will
Design 11 deep dive by UNSPSC for catalog content. We will address this with training for the end users. use all the UNSPSC codes.
When converting a cart to a requisition, reconfigure the requisition to We want to continue to give the end users flexibility in No, we're not changing the default screen.
Solution default to the Summary tab. This will allow users to populate required how they veiw the requistion. We will have training on We want end users to have flexibility and
Design 12 fields on one screen, without having to click on every requisition tab. this topic. we'll show them options in training.
7 11/16/2012
Section R# Recommendation UA Response & Rationale Final Outcome
Ensure all custom fields are needed. There are currently 4 custom fields
that users are required to populated on the requisition that are
redundant fields (listed in observations). Remove the requirement for
users to populate these fields in the General section of the site. This
will improve the user experience. Additionally, default custom field We are satisfied with the 2 required fields.
data in the user profile when possible (and applicable). Ensure custom Data for most custom fields can be set in the
Solution fields are in the document search criteria and are populated in the PO Yes, we agree. We will review all custom fields to ensure users profile and custom field data is in the
Design 13 export for reporting purposes in both RazorBuy and BASIS. they are needed. document search.
Centralize billing. Billing addresses should be limited and defaulted to a
central location to ensure a single point of entry for all invoices.
Additionally, disallow the configuration or edits of billing addresses by Yes, decision was already made that end
end users. Users at external locations can be loaded with their unique users billing address will be "pre-loaded"
Solution billing address, all users should be loaded with the billing address most We agree. End users will not be able to edit or add when their profile is created and they will
Design 14 appropriate to them with the default as central AP. billing addresses. not be able to edit or add billing addresses.
Matching tolerances should be set on the invoice and should not be
configurable by end users. For example, if an invoice is +/-10% the price
or quantity of the PO, the invoice should be routed to the department This is not perceived as an issue. Keep the
Solution for approval. Allowing users to determine the tolerances per We understand this is a best practice. We will address same functionality we have today and allow
Design 15 requisition increases financial and reputational risk for the University. this topic in Phase II of our project. end users to change this field if needed.
Define how, where and who will flag capital assets. Universities handle
asset management differently. One option is to assign capital assets in
the ERP (i.e. BASIS) on the back-end of the purchase order process. This
is typically a manual process. Another option is to request that users
flag products as assets within the RazorBuy system and pass that
Solution information to the ERP (i.e. BASIS). This process would still require a Currently have a process in place via BASIS and will Done. Currently have a process in place via
Design 16 manual post-audit to ensure goods were properly flagged by end users. continue to use this process. BASIS and will continue to use this process.
Solution Define how IT purchases will be managed through the Bookstore for We will continue with the current process as we Done. We will continue with the current
Design 17 imaging, configuration and delivery. See subsequent slide for details. designed in Razorbuy. process as we designed in Razorbuy.
Define the process for purchasing through the VWR stockroom.
RazorBuy could be used for stockroom purchases in two ways: 1.
Stockroom replenishment: VWR resources could have a shopper role to
create shopping carts with replenishment goods and assign the cart to
an Arkansas requester for purchase. 2. Purchasing from the VWR
stockroom: A custom catalog could be generated for stockroom items.
Visibility to this catalog could be limited to specific users; purchase
Solution orders would route directly to the stockroom for fulfillment. An We want to give this additional thought as we have not
Design 18 additional catalog license would required for this solution. heard a recommendation that meets all our needs.
8 11/16/2012
Section R# Recommendation UA Response & Rationale Final Outcome
Define if and how forms could be utilized to manage internal
requisitions. The current process is cumbersome and includes a post-
audit review (vs approval of charges on the front-end of the process).
Solution User interviews suggested a need for process improvement around Internal blanket orders are currently not in the scope of Done. Internal blanket orders are currently
Design 19 internal charges. this project. not in the scope of this project.
Arkansas needs to ensure that distributions are allocated properly and
exported from SciQuest to BASIS properly, specifically to ensure that Done. We agree with this process and it has
Solution SciQuest’s ability to distribute based on percentage, quantity or dollar We agree with this process and it has already been already been included in the Razorbuy
Design 20 amount. included in the Razorbuy design. design.
Develop a comprehensive supplier enablement test plan and
corresponding test scripts to minimize operational risk at go-live. A live
order test plan should be developed as well. The supplier enablement
test plan can be inclusive of the live order test plan or can be a separate
and distinct plan. Either way, a University of Arkansas resource should
be responsible for the successful execution of the supplier enablement
and live order test plan(s). See subsequent slide for an example of key
supplier enablement test plan components. Additionally, key
functionality elements for each supplier should be documented
separately and made available for user support, i.e. catalog type,
catalog product restrictions, non-catalog purchase order distribution
(cXML, email, or fax), modify or view items functionality, deadline for
orders to ship same day, eQuote functionality, punch-out "time-out" Yes, we agree. We will need to work with SciQuest to
Supplier threshold after period of inactivity, email ship acknowledgement sent ensure they have tested their side and we will ensure
Enablement 23 to requester, browser compatibility, etc. our resource tests our side.
Define, document and quantitatively support the rationale for the
selected, enabled suppliers. This will minimize reputational risk
amongst campus constituents and serve as a basis for communications
Supplier regarding ‘how’ and ‘why’ certain vendors were selected and others We have already done this, but we need to document
Enablement 24 were not selected for enablement. our reasons for the supplier decisions.
Define and document core requirements with respect to contract
management and contract reporting at UA. Request a two-hour,
detailed demonstration of the Contract Manager tool for the entire
Arkansas core project team. As an outcome of this demonstration,
conduct a fit/gap analysis of the documented requirements and the
system’s capabilities as understood in the demonstration. Configure
Supplier the tool appropriately where there is a fit and identify alternative
Enablement 25 solutions, business processes or policies to fill the gaps. Yes, we agree this needs to be done.
Load University-specific contracts and prioritize State contracts for go-
live. Systematize the import process, if possible. Test and validate this
import and/or manual creation of contracts within Contract Manager
Supplier to ensure they appear correctly and are functioning correctly (i.e. Yes, we need to work with SciQuest to define the initial
Enablement 26 appearing in search results with correct contract ID) within the system. import process of loading data into live production.
9 11/16/2012
Section R# Recommendation UA Response & Rationale Final Outcome
Arkansas should work with SciQuest to clean-out and/or refresh the Yes, we agree. But have not been successful in our
test data in the RazorBuy test system. Test data, including supplier and requests in the past. We will strengthen our efforts and
Integrations 28 accounting data, should reflect BASIS test data. ask again. We may need Huron's help with this. WIP
Users do not have the ability to see inactive vendors in SciQuest (only
system administrators with catalog management capabilities can see
inactive vendors in the system). UA should define a process for
submitting a requisition without access or visibility to inactive vendors. Decision has been made to go with this type of process.
Typically, other Universities use a custom form for ‘new vendor setup’. We need to define the specifics. IT does not agree with
Integrations 31 The TSM integration could also support the activation of vendors. this process. This will add time to the timeline.
UA should determine how heavily users relay on this functionality to
support the business decision. Huron recommends that UA not
pre-encumber, as there are process and integration implications on
how the pre-encumbrance will be reinstituted if the requisition is We currently have this functionality and we will Done. We currently have this functionality
Integrations 33 rejected. continue to use it. and we will continue to use it.
Embed the TSM integration (and corresponding documentation
including functional specification development, unit test plans,
validation and user acceptance test plans) into the project plan to Yes, we are working on this. We are defining the process
Integrations 34 accommodate vendoring process automation. by which we will integrate TSM into BASIS.
Integrations such as Invoice Export can be batch, however Huron
recommends event-based messages for other integrations including PR We have maximized the technology we have to make
Export, PR feedback and PO Export to improve timeliness of the the batch timing as close to real time as possible. In the
requisition to purchase order process and therefore enhanced user future, we are looking at adding additional technology
experience. Account code and supplier sync batches could cause a in order to do real time in the areas it is feasible. Not in
Integrations 35 delay in accessibility of data and hinder the user experience. the scope of this phase of the project. Done. Not in the scope of Phase I.
Limit or restrict users’ ability to purchase from specific vendor
websites, namely VWR and OfficeMax. Work with these organizations’
Readiness 36 Sales staff to ensure their support of the RazorBuy system. We agree and that is our plan.
Tighten the policy on Pcard utilization. This can be done by updating
the policy from a list of unauthorized purchases to ‘emergency’ or
unique supplier one time only purchases, for example. The policy would
need to clearly define emergency and one time spend within the policy.
Distribute a direct communication regarding Pcard including the
purpose and proper use of the card in relationship with other We agree we should try to direct our spend through Done. We will monitor the P card spend to
purchasing channels, including RazorBuy, and ensure the campus Razorbuy. We will monitor the P card spend to find find opportunities for adding
Readiness 37 understands that the Pcard will not be eliminated. opportunities for adding contracts/catalog vendors. contracts/vendors to RB.
10 11/16/2012
Section R# Recommendation UA Response & Rationale Final Outcome
Develop a plan to transition away from blanket orders. This plan should
be developed and executed against immediately; Arkansas does not
need to wait until go-live to implement this plan. The plan should We are developing a plan to transition away from
consist of natural attrition but proactive closure of blanket purchase blankets. Currently we have not seen an acceptable
orders as well. Place greater monitoring controls on blanket orders by alternative to handle these needs in Razorbuy. We are
routing blanket order requests (via blanket order form in RazorBuy) at actively looking for ways to address this. If Huron has
all dollar values through purchasing. This provides Purchasing with an other alternatives we are open to discussion on this
Readiness 39 opportunity to reject incorrect use of blanket orders. topic. Needs to be part of the Forms discussion.
Schedule formal knowledge transfer sessions with the SciQuest
Solution Manager. These should be recurring standing meetings to
understand system configuration including topics such as workflow
administration, forms creation and maintenance, requisition issue
Readiness 43 resolution, PO distribution issue resolution, Contract Manager, etc. Yes, we agree. We will schedule these sessions.
Request Arkansas-specific configuration documentation and/or
develop this documentation along with the SciQuest team. This
documentation should reflect various nuances to the Arkansas
configuration that is unique to their site and where administration
guidance would not be found in standard SciQuest system We will do so. We appreciate the insight. We may wish
Readiness 44 administration manuals. to have further communication on this subject.
Develop a list of requirements for reporting to the State, internal audit
or other auditing bodies, Arkansas senior executives, etc. and
determine how to satisfy those requirements through SciQuest or
BASIS reporting. See subsequent slides for metrics that should be We agree. We will define our reporting requirements.
monitored on a recurring basis to assess and measure the success of We do not believe we have de-graded our reporting
Readiness 45 the implementation. capabilities out of BASIS.
11 11/16/2012
Implementation Execution Business
Priority Owner Term Timeline Complexity Impact Notes
1 Short Long 3 5 This will be a lot of work.
2 Short Mid 3 3
3 Mid Mid 3 5 Priority given dependency 30.
4 Short Mid 3 5
Determine how many requisitions get rejected in financial approvals.
Considerations:
Audit: purchasing to not be in BASIS (records) – is this okay?
Put in SQ on the frontend? Or backend? Backend process ties into where the PO is issued. If PO is
being sent out of BASIS, put to backend. How does this affect sourcing? Are we going to do the
bid event before financial approval? How will specialty approvals be handled if Purchasing is on
5 Short Mid 3 5 the frontend (as they are manually forwarded today)?
6 Short Long 1 3
7 Short Short 1 3
12 11/16/2012
Implementation Execution Business
Priority Owner Term Timeline Complexity Impact Notes
8 Short Mid 3 5
10
Business rationale: critical business analysis of spend. BASIS is system of record so audit risk
should be minimized. How do attachments impact this when they are in SQ? Attachment
* solutions: link to attachments are stored in BASIS
*
*
13 11/16/2012
Implementation Execution Business
Priority Owner Term Timeline Complexity Impact Notes
*
*
14 11/16/2012
Implementation Execution Business
Priority Owner Term Timeline Complexity Impact Notes
15 11/16/2012
Implementation Execution Business
Priority Owner Term Timeline Complexity Impact Notes
Catalog from Bookstore: this is a wasted enablement if you're enabling Dell or GovConnect, etc.
but don't have bookstore intercept requsitions.
Standing order for their stockroom. Loss of eInvoice capability. No itemized invoice against a
blanket order because it causes a match exception because the blanket only has one line. VWR
1 could go into the portal and create a summary invoice. PO line matching fails.
16 11/16/2012
Implementation Execution Business
Priority Owner Term Timeline Complexity Impact Notes
17 11/16/2012
Implementation Execution Business
Priority Owner Term Timeline Complexity Impact Notes
Given some new information, vendoring needs to think through this more and Paul needs to look
at some coding. We will discuss this topic in next Thurs meeting, 3/29, to finish this discussion and
Short Mid 3 3 finalize our approach.
18 11/16/2012
Implementation Execution Business
Priority Owner Term Timeline Complexity Impact Notes
19 11/16/2012
Date Discussed
Action Item/Decisions To Make Owner Needed By Comments
/Requested
Vendor validations - compile a list of required and
Denise Reynolds April 3, 2012
desired validations for vendor maintenance.
Modify nightly vendor job to stop inactivating vendors. Paul Bixby April 3, 2012
Modify DISB to update address type to R Paul Bixby April 3, 2012
Modify POH and auto PO job to update address type to O Paul Bixby April 3, 2012
Analyze newly proposed vendor integration - only send
Paul Bixby prior to May 1st April 3, 2012
active vendors with TIN source code of T
Review PO information to determine if any additional
? prior to May 1st April 5, 2012
decisions or discussion is needed
HF tested again on 4/13/12, only the Sales Tax
checkbox at the line is removing tax. Cannot
Heather
Test Sales Tax ID field and Sales Tax checkbox prior to May 1st April 5, 2012 fully test until cart validations are corrected
Frankenberger
and in place. Appears fix will not happen until
after 5/1/12.
e-invoices - Will we have the ability to reject it and send
Jim Hashbarger prior to May 1st April 5, 2012
it back to the vendor via RB in Phase I?
Cart validations need to be reviewed and documented. ? prior to May 1st April 5, 2012
Can we feed invoice images back to SciQuest or have a
link so the end user can view the invoice/entire Jim Hashbarger TBD April 5, 2012 After re-engagement.
transaction?
Could this be handled via a link from BASIS to
Do we need a record of the RB comments tab in BASIS? Jim Hashbarger prior to May 1st April 5, 2012
RB?
Do we need a record of documents attached to RB forms Could this be handled via a link from BASIS to
Jim Hashbarger prior to May 1st April 5, 2012
in BASIS? RB?
Need to test attachments. Do documents attached to Heather
prior to May 1st April 17, 2012 If not, do we need a record of these in BASIS?
forms show up on the attachments tab? Frankenberger
Will no accounting info at the header, but accounting Created RB Req #758009, flowed through
Heather/Paul Complete 4/23 April 17, 2012
info at the line cause an error in BASIS? BASIS with no errors Req #002657.
Discuss Forms and all that encompasses. Business Affairs TBD April 17, 2012 After re-engagement.
Develop workflow associated with UNSPSC codes flagged
Tina Lester TBD April 17, 2012 After re-engagement.
‘H’.
Heather Frankenberger Page 20 11/16/2012
Test workflow associated with UNSPSC codes flagged ‘H’. Business Affairs TBD April 17, 2012 After re-engagement.
Test Comments tab. Who can see the Comments? Who Heather
prior to May 1st April 17, 2012
gets notification? Frankenberger
Need to make sure SQ tells us all the field names on the
Forms so each field can be mapped/managed Tina Lester TBD April 17, 2012 After re-engagement.
appropriately.
Do External Notes duplicate on each PO if multiple
Heather HF will address notes, comments and
vendors are in the RB Cart? Do the Internal Notes act the prior to May 1st April 17, 2012
Frankenberger attachments in training.
same as external?
Need to test and document, what will Buyers vs. RB
Tina/Heather TBD April 17, 2012 After re-engagement.
Approvers vs. BASIS Approvers see on the RB Req?
The final copy of SciQuest to BASIS field mapping is After mapping is Note: Screen name may be different than
BASIS Team April 17, 2012
needed by Business Affairs. complete system field name.
If the commodity code is a 1099 reportable item and a
substitution occurs on that item, how does Business Jim Hashbarger ? April 19, 2012
Affairs want to handle those commodity code changes?
What questions/issues do we need to resolve prior to re- Implementation
April 24, 2012 April 19, 2012
engagement with SQ? Team
Does any data come from BASIS on the initial data
Paul Bixby ? April 19, 2012
upload to RazorBuy?
The vendor information in BASIS Test needs to be
completed (fill in as much information for each vendor as ? ? April 19, 2012
possible).
Who has vendor access to BASIS test? Need to test the
following scenarios: 1) No T in source code, 2) T in source
Denise Reynolds prior to May 1st April 20, 2012
code with R, 3) T in source code with O, 4) T in source
code with R and O, and 5) T in source code with no type.
Heather Frankenberger Page 21 11/16/2012
