Decisions report

This page lists all the decisions made during the design workshops :

Title	Decisions
WKS 1 - Catalogue and Product Hierarchy	As data related product is already stored in SAP or PM, No locally managed data should be managed in the CPQ System Use Price Manager as a source of product list to create product catalog in CPQ system
WKS 2 - System Architecture and Interfaces	Until the topic regarding CRM integration is discussed further, and specifically the use of CPQ CRM, any additional data regarding customers will be managed locally within the CPQ system Additional output tables will need to be created in Price Manager to receive new conditions. Additional lookup tables (Locally Managed Data) will/might need to created in Price Manager to maintain inputs to CPQ Sales team to be required to fill in contact information manually in CPQ Zilliant Price Manager project team will act as ‘internal Valio IT team’ - for collaboration on system interfaces, given their deep knowledge and unavailability of Valio IT team.
WKS 3 - CRM Integration: Part 1	Addresses and contact details to be manually managed by sales representatives in system
WKS 5 - CRM Integration: Part 2	Implement system in English initially with prepared translation mapping No integration with C4C for now - key CRM features will be implemented in the Zilliant CPQ (CRM functionality), as much as possible incorporating features required in the future C4C system.
WKS 4 - ERP Integration	No integration between CPQ and ERP. All typical data exchanges between CPQ and ERP will be done via Price Manager Rebates directly downloaded from CPQ
WKS 7 - Roles and User Management	Sales rep manually selects approver, instead of automation from the system.
WKS 8 - Customer Management	Linking of Quotes to Opportunities is not mandatory (but recommended) Keep Customer information as simple and lean as possible, only the necessary to enable an efficient quoting process
WKS 10 - Quote Pricing and Discount Structure	Currency does not need to be shown to the user, as all quotes are in EUR
WKS 11a - Quote Model and Structure Part 1	Develop one universal quote structure supporting multiple business cases Deal Potential information will not be in the main quote overview screen, a specific tab will be created for it Users to download/upload multiple Excel templates to update quote line item relevant information and, as a workaround for lack of ‘multiple views’ and ‘complex mass update’ capabilities Implement 2 quote line item types: 1) product net price and 2) product group discount, since we can only have a single ‘Items’ screen. Head-Office fees to be managed alongside the product group discounts
WKS 11b - Quote Model and Structure Part 2	Since we cannot have multiple ‘Items' tabs according to where the products are sourced from, this can be managed by adding a column 'Product Source’ to the quote line item. Data processing of customer data from Zilliant is still something worth exploring, as it could bring a lot of value. Let’s define the use-cases/complexity and define a plan/estimate with Zilliant.
WKS 12 - Document Generation and Templates	Proceed with the proposed template ValioAimo_TUKKUSOPIMUSpohja_EN.docx as an initial framework
WKS 15 - Agreements Management	Mass price updates for agreements should be implemented in Price Manager, not CPQ. The impact calculation for agreement mass price updates will focus on net price line items using historical volume, old costs/prices versus new costs/prices. This is a simpler approach than recalculating the entire deal profitability.
WKS16 - Pricing Logic	Do not include CSP values in the CPQ tool
WKS - Parent Customer Data Aggregation	Parent Customer Master Table Creation: It was decided that a new, aggregated parent customer master table needs to be created. This table should contain only one row per parent customer with the aggregated fields.. Responsibility for Aggregation: The aggregation logic and the creation of this new parent customer master table should ideally be performed by the Zilliant team. This work will be more complex than simple API calls and may involve a "sequel script" running within a job workflow. No Address Fields in CPQ (for aggregation logic): The system should rely solely on the calculated postal code/geographical region ID for pricing rules, without needing to store or use an actual street address for the parent in this context.