14001-CHANGE ORDER 4 12-13-17.PDF

THOMSON REUTERS
PROJECT IMPLEMENTATION CHANGE REQUEST
MANATRON, INC. — A THOMSON REUTERS BUSINESS
("Thomson Reuters Tax & Accounting, Government" or "TRTA Gov")
Customer Name: Maricopa County Treasurer's Office
Change Request No.: 14001-RFP-CR004 Date Submitted: 9/7/2017 (updated 8/31117 per request of MCTO)
Project Name: Maricopa County Treasurer Information Module NameNersion: Dynamics AX
Systems — ULTIS project
Original Contract No.: 14001-RFP TRTA Gov Program Manager: Lisa Redding
Summary of Change:
Incorporation of the increased scope into the In-Scope functionality of the original contract. These additional
requirements are segregated by feature into the following categories and further broken out in the Description section:
1. ADRIP / Non ADRIP
2. GL Export
3. GL Import
4. Low Speed Warrant Import to Warrant Master
Priority: 11 Urgent or Lii Normal Required by: 0 UAT 0 Go-Live LI Final Acceptance
E Other: County's desired date
Window of delivery date and business process calendar/phase justification:
Functionality will be planned into an upcoming Dynamics AX code build with dates to be confirmed with MCTO once
Functional Design Documents (FDDs) are approved.
Requested by: I Customer or El TRTA Gov Requestor(s): Maricopa County Treasurer's Office
Fixed Fee (not including travel expenses): $484,900
Any travel expenses associated with this change request will be billed as incurred and approved with a minimum 15-day
advance notice.
Request Type (mark all that apply):
Professional Services Application Software LI Third-Party Software E Other:
This change request impacts (mark all that apply):
Product/Scope El Schedule El Other:
TRTA Gov TFS No.: Refer to section below El Eng. TFS and/or El PS TFS (Aumentum only)
Description Provided By:
Lisa Redding, TRTA Gov Program Manager 8/10/2017
Madhu Nekkalapudi, Microsoft Project Manager 8/10/2017
William Cook, Microsoft Engagement Manager 8/10/2017
Name & Title Date
CR No. 14001-RFP-CR004 1 Confidential

THOMSON REUTERS
PROJECT IMPLEMENTATION CHANGE REQUEST
Description of Change Being Requested (describe here or attach document if needed)
Incorporation of the increased scope into the In-Scope functionality of the original contract. These additional
requirements are segregated by feature into the following categories:
1. ADRIP/Non ADRIP
2. GL Export
3. GL Import
4. Low Speed Warrant Import into Warrant Master
Excess Proceeds functionality as described in previous versions of this CR remains out of scope and will be priced in the
future at the request of the County.
As the functionality provided with this CR is separate from the existing contract deliverables, a separate Deliverable
Acceptance Statement (DAS) will be provided for this effort.
1. ADRIP / Non — ADRIP Requirements:
Conclusion: TRTA Gov has implemented the stated contract requirements in the build already deployed. However,
during our Analysis and Design phases, MCTO requested additional scope for expanded automation, beyond that which
was contemplated or discussed as part of the contracting process. The additional scope is unique to MCTO and beyond
the industry standard for automation of these types of processes.
fillAr] HEM
5523 Manual: The system must allow an Agency A user (non-Drip) to link one or more posted Agency A transmittal
journals to one or more posted bank clearing account GL transactions (note: can be different GL clearing
accounts).
5522 Manual: The system must allow a MCT user to create a template journal with lines in a journal which can be
used to create future journal entries.
5521 Manual: For unposted transmittal journals it must be possible for MCT users to delete the journal through the
AX client.
5520 Manual: For unposted transmittal journals it must be possible for MCT users to modify the journals, including
Account Strings, Amount, Posting date, description (e.g. ULID) and number of lines.
5519 Manual: The system must allow a MCT user to link one or more posted transmittal journals to one or more
pu6Lt:ci LIdiIClduIj aut..uui L.)L ii 1:›44G1,1(...)1 i Iiuui. Lu Lt thiiei bin GL deal in9 aGcounis).
5478 Recon: The system must be able to accept debits and credits from the Bank statement and make the
necessary adjustments on the New bank transaction
5477 imp: The system will return a log of successful or unsuccessful imported transmittals to a configurable path
on MCTO server (e.g. AgencyWeb folder)
6476 Gen: The system must allow a MCT user to upload an import file to the standard import path for ADRIP or
Non-ADRIP processing.
5466 Imp: When the system matches a transmittal from an Agency with a Bank transaction clearing account, the
posted treasurer receipt will be settled with the bank clearing transaction.
5465 Imp: Agency users MAY have the ability to edit/delete submitted transmittals or create new transmittals in the
AX Client
5463 Imp: Imported transmittals that have more than 1 ULID number will be rejected
CR No. 14001-RFP-CR004 2 Confidential

THOMSON REUTERS
PROJECT IMPLEMENTATION CHANGE REQUEST
5230 imp: The system must perform matching to Bank on all imported journals using the logic defined in the
description
5229 imp: The system must allow MCTO users to be able to manually create a draft depository transmittal - in -- the
AX client
5228 setup:The system must provide a mechanism to map an Agency user to 1 or more bank accounts.
5227 setup: The system must maintain the account structure used for validating the Account string in the import
file.
5226 imp: Destination Account field (main account + dimensions) in the import file will be validated using the
current COA account structure rules.
5207 setup: The system must identity a bank account as ADRIP or non ADRIP or blank
5205 imp: Prior to a depository transmittal import the system must verify that the submitting userid has authority to
transact on the provided Bank Account
6204 recon: During a ADRIP and Non-ADRIP bank reconciliation the system, the rules described in the description
must be followed.
5202 setup: The system must maintain an association between a bank account, bank statement transaction codes
and multiple depository clearing account string (ledger type)
5201 setup:The system must provide a mechanism to map a bank account, during bank recon, to a group of
unposted depository transmittal journals
5199 imp: Imported depository transmittal journals must be identifiable in the system and enable an association
with a specific bank account to facilitate reconciliation
5198 imp: In the import file, the system must accept a file with one or more lines with the following attributes: Bank
Account, Description, Credit Amount, ULID, Destination Account (main account dimensions)
5194 imp:All GL import file names will be prefixed with the AX user ID that MCT wants AX to be used for agency
dimension value mapping
5193 imp:The system shall use the AX UserlD, as provided in the prefix of the file provided by MCT, as the prefix
to log files returned to the Agency Web log folder
Backup information to address the history of the scope discussions and increases
The original SOW requirements were as follows:
Reg ID Title
3 The system shall provide capability to receive Journal entries from external entities and track the related
transactions to insure the accounts are limited to the entity's group of accounts and do not affect other
entities' actions. Arizona Revised Statutes (A.R.S) §15-996.1
85 The system shall adopt the standardized UAMACT procedure by providing capability to automate
transmissions electronically from external agencies and the servicing bank: including the date the monies
were received, the depositing entity, the type of revenue, the applicable fund, and the amount of the deposit,
which shall be compared and validated before final processing. e.g., the bank deposit slip and the
Treasurers receipt must match before posting a transaction to the Treasurer's general ledger. Exceptions
must be identified and recorded. e.g., electronic transmission files from the bank to the Treasurer's system
that provides a quick way to track a bank transaction. i.e., department, type of revenue, account code,
EULID (deposit slip #), and amount deposited for transactions in question.
Referred to as CASH - Cash Receipts in the UAMACT Section IV-C-3.
CR No. 14001-RFP-CR004 3 Confidential

PROJECT IMPLEMENTATION CHANGE REQUEST
During the contract procurement phase (prior to May 2016), the requirements were defined as follows. (Appendix 11 —
Fit Gap Report).
Reg Disposition Process Resolution Description
ID Group
3 Gap 65.40.003 — This Gap will be handled by an interface that will have to be designed and
Import General developed as part of the implementation of Microsoft Dynamics AX to receive
Ledger Entries Journal Entries from both the Thomson Reuter Aumentum and Emphasys
SymPro solutions. Microsoft will work with the Vendor Project Team and
Maricopa County Treasurer's Office Project Team to determine the specific
fields that will be sent from Aumentum and Emphasys SymPro to be posted in
Microsoft Dynamics AX. Microsoft Dynamics AX is flexible, and the file format
assumed is a flat file transfer. Microsoft assumes that the standard out-of-the-
box DIXF Ledger Journal Entity will be used.
This requirement will be met by Customization 13: Integration —
Aumentum/SymPro/Agency Journal Import as described in Section 3:
Microsoft Dynamics AX Fit-Gap Customization List.
85 Fit 35.40.075 — There is standard Microsoft Dynamics AX functionality that allows for direct
Post Receipts deposits into the system.
and Deposits
During the Analysis phase (July-August 2016), TRTA Gov (Microsoft) worked with MCTO to understand these
requirements. During the discussions, MCTO provided additional information not previously provided during the original
onsite procurement discussions. The project team made the decision to break out the discussion into separate TFS sub
requirements. The following TES items were opened during this discussion.
Reg TFS Dispositi Team Result
ID ID on Decision
3 1560 or each agency, the system must allow by Gap Closed - MCTO Closed in TFS;
bank account which deposits are matched via Rejected further broken out into
ADRIP or accepted as submitted ADRIP Emerging
Requirements
3 834 The system must be able to import a journal Gap Active - Delivered with FDD 2051
from an Agency Accepted code
3 835 A journal import rioi - iJLJJ only Fit Out of the. box functionality
impact the authorized accounts for that Accepted
I agency
3 836 Journals may only be imported for Agency by Gap Active - Delivered with EDO 2051
a user authorized to import a journal for that Accepted code
agency
3 837 The system must be able to import a journal Gap Active - Delivered with FDD 2051
from a CSV file Accepted code
3 838 The system must be able to import a journal Gap Active - Delivered with FDD 2051
from an Excel spreadsheet Accepted code and out of the box
functionality
848 The system must provide a user interface for Gap Closed - MCTO Closed in TES;
matching of an agency journal to related bank Rejected further broken out into
deposits (I to n) before posting (ADRIP) ADRIP Emerging
Requirements
CR No 14001-RFP-CR004 4 Confidential

THOMSON REUTERS
PROJECT IMPLEMENTATION CHANGE REQUEST
Req TFS Dispositi Team Result
ID ID on Decision
3 849 Journals imported from an agency must Gap Active - Delivered with FDD 2051
permit bank transactions which post to an Accepted code
agency account that generates the balancing
transactions to the treasurer's bank account
85 779 Gen: When posting deposits to an agency, Gap Closed MCTO Closed in TFS;
the ADRIP process should be followed Rejected further broken out into
ADRIP Emerging
Requirements
85 886 When posting a deposit the system must Fit Active - Out of the box functionality
track both the beneficiary agency and the Accepted
submitting agency
In further discussions (Aug 2016-Mar 2017), Microsoft offered to include TFS 1560 and 779 within scope if Maricopa
would remove the requirement for TFS 848; however, this was not accepted and these three TFS items were instead
closed and the TFS sub requirements listed at the beginning of this section were added. In addition a new process group
was added that was not part of the contract in-scope process groups: 30.25.10 — Process Depository Transmittals
(ADRIP and non ADRIP).
2. GL Export
Conclusion: TRTA Gov has provided steps to MCTO to export GL data in a standard output file, using out-of-the-box
(00B) functionality as stated in the contract. The 00B report uses the posting date; however, MCTO desires the activity
date on which the journal was posted. This CR will modify the 00B report to provide an option to report on the activity
date. The change is unique to MCTO and beyond that which was contemplated or discussed as part of the contracting
process.
ID Title Reason for increased scope
5868 GL Export File process is incorrectly using the Custom code change to the out-of-the-box functionality.
journal posting date as the selection
parameter
Backup information to address the history of the scope discussions and increases
In a letter dated May 8, 2017, MCTO provided SOW references to requirements 657, 659 and a portion of 753 as in-scope
for the GL Export; however, upon further review and discussion in a meeting on May 10, the full audience agreed that
these were Aumentum requirements and outside the scope of Dynamics.
Also in this meeting MCTO clarified that "a report exported in batch mode" would indeed satisfy their GL EXPORT
requirements, provided that the following three criteria were met:
a. The export was performed via a scheduled batch process set to run daily (once per day).
b. The export output file was in an Excel or .csv format.
c. The desired data was present in the output file.
The simplified requirement above can be satisfied with out-of-the-box Microsoft Dynamics AX capabilities and Microsoft
provided step-by-step instructions for how this can be configured within the Dynamics deployment. We asked that MCTO
configure and test this functionality and determine if this was sufficient.
MCTO responded on June 27th by opening a TFS work item to document the need for the output to be based on
ACTIVITY Date (the date the records are loaded into the system) and not on POSTING date (Transaction date). Since
this change would be a code change to the out-of-the-box functionality, it is out of scope of the contract.
CR No. 14001-RFF-CR004 5 Confidential

THOMSON REUTERS
PROJECT IMPLEMENTATION CHANGE REQUEST
Upon signing this CR, MCTO will close the following GL Export-related requirements in TFS that were created after the
project start. These TFS items will not be pursued as part of this CR: 5176, 5177, 5178, 5179, 5180, 5182, and 5183.
3. GL Import
Conclusion: There is no requirement in the SOW to provide a solution other than the manual import of a GL file. This
requirement was discussed in February 2017 and labeled as an enhancement outside the scope of the original contract.
MCTO is now asking for this functionality to be added to the scope of this contract.
TRTA Gov will include this scope as it is currently defined in TFS 5184 into CR004 at no additional cost. If the
requirements change at a later date, it will be managed by the formal change management process defined for this project.
MCTO requests the addition of a GL Import button into Dynamics functionality. This feature would allow the end user to
import a file from within Dynamics, instead of a separate manual process.
ID Title
5184 The system must provide the capability for an authenticated AX Agency user to upload a GL import file from
the Dynamics AX Client, and place into the GL import folder with a file name of 1) prefix of the authenticated
AX userid, 2) datetime.
This upload is an alternative to uploading GL import files via Agency web. While an agency user may use the
AX client to create journals and post them directly, there may be scenarios where a user has a property
formatted file and they want to upload.
File name will have the following naming convention:
Userld_FileType_Source_YYYYMMDDHHMMSS.csv
The userld is the DynamicsUserld
FileType will be: GL
Source: AX
4. Low Speed Warrant Import to Warrant Master:
Conclusion: TRTA Gov has implemented the stated contract requirements in the build already deployed. However,
MCTO iequesiod clldlles whili would addiLional ousiomizukuil uiquo Lu MG W uitd buyolid diaL wliiuli wus
contemplated or discussed as part of the contracting process.
ID Title Reason for increased scope
5859 Low Speed Warrant process incorrectly Additional requirement not previously documented in the
creates a Positive Pay File scope.
Backup information to address the history of the scope discussions and increases
Because there is no requirement in the SOW to provide a separate interface for Low Speed warrant, Microsoft designed
the ability to process Low Speed Warrants in the same fashion as High Speed Warrants. As discussed in the May 10
meeting, the existing deployment of Microsoft Dynamics AX at MCTO already meets the contracted requirements.
Microsoft provided a document with step-by-step instructions for how this can be performed. We asked that MCTO test
this functionality and determine if this was sufficient.
CR No. 14001-RFP-CR004 6 Confidential

:,:;* THOMSON REUTERS
PROJECT IMPLEMENTATION CHANGE REQUEST
MCTO responded on June 27th by opening a TFS work item to document the following issue:
MCTO followed the MCS recommended process, however the Dynamics process created a Positive Pay file for the
low speed warrants. The requirement for low speed warrants is that a Positive Pay file is NOT created.
There is no SOW requirement that covers this change to the Low Speed Warrant import process. Since this would be a
requirement addition, it is out of scope of the contract.
Upon signing this CR, MCTO will close the following Low Speed Warrant-related requirement in TFS that was created
after the project start. This TFS item will not be pursued as part of this CR: 756.
Recommended Solution:
• Incorporation of the requirements listed above into the Microsoft Dynamics design and deployment.
Assumptions:
• The requirements presented in this CR are presented as a complete package and cannot be individually broken
out. Discounted package pricing assumes economies of scale in both resources and development that are not
available if purchased separately.
• Excess Proceeds scope increases will be moved to a separate CR and priced in the future at the request of the
County.
• The PMs will work with the project teams to encourage any new request to be resolved through a workaround
instead of adding new requirements to the project implementation.
• Without authorization to proceed in writing by way of signing this CR, design and development will not begin.
Delayed acceptance of the CR will risk the E2E and UAT testing windows.
• There is no guarantee of meeting the county's desired go-live date of February 2018 as we previously stated
delaying the decision beyond July 2017 may impact that date; however, all team members will continue working
towards the Feb 2018 go-live plan. The PMs will continually monitor progress and work with the project teams to
encourage quick decision making and timely issue resolution to mitigate the risk of delays to the go-live plan.
• Acceptance of this CR includes acceptance of Milestone 8 and the associated DAS. This acceptance authorizes
immediate payment in full for this milestone.
• Acceptance of this CR includes acceptance of Milestone 9 and the associated DAS. This acceptance authorizes
immediate payment in full for this milestone.
• MCTO will provide resources and write all test cases to test the new functionality.
• Resource support of the Extended go-live date and all associated costs will be presented in a separate CR and is
not included here.
Acceptance Criteria (describe expected acceptance criteria for changed deliverables upon completion):
• TRTA Gov (Microsoft) has provided new or updated FDDs to document design information for the listed TFS
Requirement IDs in this CR document
• MCTO has reviewed and approved FDDs for the listed TFS Requirement IDs in this CR document
o Approval of Functional Design Document(s) by MCTO SMEs will occur in TFS and will be considered
final. No further reviews, updates and approvals on the individual documents will be sought by MCTO.
• TRTA Gov (Microsoft) has provided preliminary Technical Design Documents (TDDs) to MCTO for TFS
Requirement IDs listed in this document. No MCTO review or approval is required for the TDDs.
• TRTA Gov (Microsoft) has delivered a build inclusive of TFS Requirements for the purposes of configuration, set
up and testing. P1 and/or P2 defects found in the implementation as a result of subsequent testing will be
resolved as per the standard defect resolution process within the original contract, separately from this DAS.
• This acceptance will be separate from acceptance of existing Milestones 8-9, which are not contingent on this
effort.
Risk Assessment 1 Technical and Project Impact
General Notes:
• Change as described above
CR No. 14001-RFP-CR004 7 Confidential

THOMSON REUTERS
PROJECT IMPLEMENTATION CHANGE REQUEST
Project Impacts:
• Additional Dynamics AX scope and costs as described. Any change to Aumentum as a result of this new
functionality is not included in this CR.
• Design and Development efforts will proceed upon written authorization of this CR. Delays to finalizing this CR
will risk the current E2E and UAT Testing windows and will impact the go-live date.
• No customizations related to functionality identified in this CR will be delivered until the DAS 1 (design approval)
for this CR is signed.
Development:
• These requirements will be developed, tested and released upon the written approval of the CR. Functionality will
be planned into an Dynamics AX code build with dates to be confirmed with MCTO once Functional Design
Documents (FDDs) are approved.
• P1 and P2 defects during the implementation testing period will be triaged and any associated code changes will
be provided in future code builds. Schedule to be agreed with the PM project team.
Configuration:
• N/A
Testing:
• MCTO will develop requirement gap test scripts
• MCTO will provide expertise to test the functionality per the agreed schedule
Documentation:
• Functional design documents (FDDs) be updated, reviewed and approved with MCTO SMEs who are authorized
to sign off on such design documentation.
• MCTO SME's will review and approve the design documents within three (3) business days after the design is
updated basing on the feedback received in the design review session and submitted for approval
• Approval of Functional Design Document(s) by MCTO SMEs in TES will be considered final and no further
reviews, updates and approvals will be sought by MCTO.
• A DAS will be submitted upon document approval in TES and serves as authorization to bill for this CR phase.
• Technical Design Documents (TDDs) will be provided for reference only, as there will be no formal review or
approval expected of these documents.
• Entity Relationship Diagrams (ERDs) will not be updated or provided for customizations identified in this CR.
Training:
• N/A
TRTA Gov Required Resources:
• Dynamics AX Project Manager
Dyiiiiiiu AX Solution Ai Iuo Cui itAilitai it
• Microsoft Dynamics Design/Development Team
• TRTA Gov Project and/or Program Manager
Customer Responsibilities:
• Any change in requirements will go through the formal change request process defined for this project
• MCTO will be responsible for reviewing and providing timely approval of the Functional Design Document(s) so as
to not impact the start of the development cycle and agreed project schedule. Any such delays will go through the
formal change request process defined for this project.
• MCTO will complete at least one round of requirements testing for the functionality associated with this CR within
two weeks of the build being released.
• MCTO will be responsible for testing the new functionality in a timely manner so as to not impact the agreed
project schedule.
• Upon signing this CR, MCTO will close the following requirements in IFS that were created after the project start.
These TES items will not be pursued as part of this CR:
o GL Export: 5176, 5177, 5178, 5179, 5180, 5182, 5183
o Low Speed Warrant: 756
CR No. 14001-RFP-CR004 8 Confidential

TRTA Gov Program Manager 9-7-2017
Managing Director, Government 9-8-2017

.*
• THOMSON REUTERS
PROJECT IMPLEMENTATION CHANGE REQUEST
DELIVERABLE ACCEPTANCE STATEMENT ("DAS") #1
FOR CHANGE REQUEST NO. 14001-RFP-CR004
Purpose:
The purpose of this acceptance form is for the Customer to sign off on the design of the services described in this change
request and agree that TRTA Gov should proceed to the next phase of the project and accept billing for this phase.
Summary of Change Request:
Incorporation of the following Emerging Requirements (as described in the Change Request) into the In-Scope
functionality of the original contract:
1. ADRIP
2. GI_ Export
3. GL Import
4. Low Speed Warrants
Acceptance Criteria:
• TRTA Gov (Microsoft) has provided new or updated FDDs to document design information for the listed TFS
Requirement IDs in this CR document
• MCTO has reviewed and approved FDDs for the listed TFS Requirement IDs in this CR document
o Approval of Functional Design Document(s) by MCTO SMEs will occur in TFS and will be considered
final. No further reviews, updates and approvals on the individual documents will be sought by MCTO.
These items were completed on
Client response period is ten (10) business days. After that time, this deliverable will be considered accepted and ready
for billing unless otherwise documented in a formal response to TRTA Gov with detailed rationale for rejecting this
milestone. Rejection of a milestone will result in immediate escalation and halt the project for further review. See
Appendix 2-A: Deliverable Acceptance Process for guidelines related to deliverable acceptance.
We, the undersigned, agree that these items are complete and that under the conditions of this change request, the
County will be billed $160,017.00 (33% of the total fee) upon signing this acceptance.
['Accepted ['Rejected
Jurisdiction: Maricopa County Thomson Reuters:
Signature: Signature:
Printed Name: Printed Name:
Title: Title:
Date: Date:
Signature:
Printed Name:
Title:
Date:
CR No. 14001-RFP-CR004 10 Confidential

THOMSON REUTERS
PROJECT IMPLEMENTATION CHANGE REQUEST
DELIVERABLE ACCEPTANCE STATEMENT ("DAS") #2
FOR CHANGE REQUEST NO. 14001-RFP-CR004
Purpose:
The purpose of this acceptance form is for the Customer to sign off on the completion of the services described in this
change request and agree that TRTA Gov should proceed to the next phase of the project and accept billing for this
phase.
Summary of Change Request:
Incorporation of the following Emerging Requirements (as described in the Change Request) into the In-Scope
functionality of the original contract:
1. ADRIP
2. GL Export
3. GL import
4. Low Speed Warrants
Acceptance Criteria:
• TRTA Gov (Microsoft) has provided preliminary Technical Design Documents (TDDs) to MCTO for IFS
Requirement IDs listed in this document. No MCTO review or approval is required for the TDDs.
• TRTA Gov (Microsoft) has delivered a build inclusive of TFS Requirements for the purposes of configuration, set
up and testing. P1 and/or P2 defects found in the implementation as a result of subsequent testing will be
resolved as per the standard defect resolution process within the original contract, separately from this DAS.
These items were completed on
Client response period is ten (10) business days. After that time, this deliverable will be considered accepted and ready
for billing unless otherwise documented in a formal response to TRTA Gov with detailed rationale for rejecting this
milestone. Rejection of a milestone will result in immediate escalation and halt the project for further review. See
Appendix 2-A: Deliverable Acceptance Process for guidelines related to deliverable acceptance.
We, the undersigned, agree that these items are complete and that under the conditions of this change request, the
County will be billed $164,866.00 (34% of the total fee) upon signing this acceptance. It is agreed that this functionality
delivery is complete.
El Accepted EIRejected
Jurisdiction: Maricopa County Thomson Reuters:
Signature: Signature:
—Printed Name: Printed Name:
Title:
Date: Date:
Signature:
Printed Name:
Title:
Date:
CR No. 14001-RFP-CR004 11 Confidential