Quick-Start Data Specification
This page is designed to be a rapid reference guide, to help you understand which data structures are commonly required for pricing software, and how best to provide that data to Pricefx in order to enable rapid on-boarding.
- 1 Data Sample Template:
- 2 Data Dictionaries
- 3 Data Tables
- 3.1 Transactions (Invoice Line Items)
- 3.1.1 Criticality: REQUIRED
- 3.1.2 Legend
- 3.1.3 Sample
- 3.2 Customer Master
- 3.2.1 Criticality: REQUIRED
- 3.2.2 Legend
- 3.2.3 Sample
- 3.3 Product Master
- 3.3.1 Criticality: REQUIRED
- 3.3.2 Legend
- 3.4 Currency Conversion
- 3.5 UOM Conversion
- 3.6 Quote Line Items
- 3.6.1 Criticality: OPTIONAL
- 3.7 List Price History
- 3.7.1 Criticality: RECOMMENDED
- 3.8 Cost Price History
- 3.8.1 Criticality: RECOMMENDED
- 3.1 Transactions (Invoice Line Items)
- 4 Accelerator Requirements Matrix
Data Sample Template:
Pricefx Internal Template Link (PRIVATE)
Data Dictionaries
If there are documents like this available, this is ideal. A “data dictionary” is a document that defines the fields in your tables and what they’re used for. These are often maintained by vended system providers that have standard data models or by an enterprise data team.
Note, if you do not have a data dictionary, the template linked above allows a scaled down definition of key fields for your business. Please provide one of the two for your Pricefx implementation.
Data dictionaries help us:
Understand and validate the data ourselves
Map your key/dimension columns easily to PricingAI modules
Inform Agents features about your data context
We request, for each below table you provide, you also provide a dictionary like below:
Column Name | Data Type | Business Context |
|---|---|---|
Customer ID | Text | The “ship-to” unique identifier of my customer on this sale |
Product ID | Text | The unique sku of the product that was sold |
Invoice Price | Number | The total revenue of the transaction line item |
Quantity | Number | The total number of units the customer purchased |
Product Family | Text | Key attribute for filtering along product lines |
Customer Tier | Text | Key attribute for filtering and grouping customers |
Country | Text | Primary regional division |
Example
Data Tables
Below, are a list of standard data tables. For each, you will find:
A criticality, indicating the importance of this table to our process and the PricingAI solution
A legend, which outlines the columns we typically require and a description of each column
Columns marked with “MSCW” prioritization:
M = MUST have
S = SHOULD have
C = COULD have
W = WON'T have
There is sample data, showing a theoretical sample data set indicative of what you might provide to Pricefx, in the accompanying Excel spreadsheet (linked above).
Transactions (Invoice Line Items)
Criticality: REQUIRED
Typically, this should be invoice data, but sales order data might work as alternative. The key is how you as a customer recognize your sales (on order vs. invoice) and how you’ll use this data for analysis and the optimization process.
The data should have:
One customer / one product in a single invoice line item
Allows data to be filtered and managed at the most granular level
One row per transaction line item
One customer / buying group per invoice / order
Recommendations:
Additional business-specific fields are useful in assisting filtering & classifying sales. Provide any fields that you would use in your pricing processes and might want to sort or filter analytics by. If these are already contained in your product or customer data, they can be joined together in the Pricefx Datamart, but any values not related to those or not on those tables can accompany the transaction data.
Legend
Column | MSCW | Description |
Product ID | M | Corresponds to the IDs used in the products data |
Customer ID | M | Corresponds to the IDs used in the customers data; typically this would be the most granular customer ID (i.e. - ship-to vs. sold-to), but should be oriented around how the ERP defines a "unique customer" |
Line Item ID | M | Unique ID for each transaction line item - more granular than invoice or order ID |
Pricing Date | M | Date that the transaction should be recognized for - consider filtering for revenue / turnover by dates; could be invoice date, delivery date or order date |
Invoice Price | M | Revenue (either total or per unit) for the transaction line item - typically total gross revenue (which may actually be a net price for your business) for the line item |
Net Price | C | The final revenue net of any relevant factors that are not typically considered - "net price" often has different definitions in different organizations, but often something like this might include off invoice “discounts” like rebates |
Margin | M | Margin (either total or per unit) for the transaction line item - should represent the margin metric that's most useful |
Quantity | M | The number of units sold in the transaction line item |
Currency | C | The currency used to transact the line item |
UOM | C | The unit of measure that the "Quantity" field is expressed in |
Geography 1 | S | Geographical hierarchy of the transaction (could be in customer instead) - something like State / Country or Country / Region - up to 2 levels |
Geography 2 | C | Geographical hierarchy of the transaction (could be in customer instead) - something like State / Country or Country / Region - up to 2 levels |
Business Unit Structure 1 | S | Sales Org (SAP) / Business Unit / Division - essentially the company entity structure - up to 3 fields |
Business Unit Structure 2 | C | Sales Org (SAP) / Business Unit / Division - essentially the company entity structure - up to 3 fields |
Business Unit Structure 3 | C | Sales Org (SAP) / Business Unit / Division - essentially the company entity structure - up to 3 fields |
Sales Manager | C | Sales leadership - this can be an individual or an org structure |
Seller | C | Sales Executive or sales person who is credited with the sale |
List Price | C | List price at the time of the transaction if list pricing is used |
Transaction Type | S | Provides specificity to the medium of the transaction - can be a price type or sale type |
Generic Attribute 1 | C | Additional attribute / dimension at the transaction level that is important to filtering and aggregating data |
Generic Attribute 2 | C | Additional attribute / dimension at the transaction level that is important to filtering and aggregating data |
Generic Attribute 3 | C | Additional attribute / dimension at the transaction level that is important to filtering and aggregating data |
Generic Attribute 4 | C | Additional attribute / dimension at the transaction level that is important to filtering and aggregating data |
Generic Attribute 5 | C | Additional attribute / dimension at the transaction level that is important to filtering and aggregating data |
Sample
See the downloadable Excel file.
Customer Master
Criticality: REQUIRED
This data will identify your customers. The definition of a “customer” can vary - often it’s easiest to provide customers at the most granular level - each customer ID as a ship-to or location of a customer. There should be only one table row per customer ID and the associated customer hierarchy context (bill-to, sold-to, ship-to, etc.) when relevant.
Typically however this is oriented on your ERP system will be how to provide the data, as that will typically match the invoice data.
Legend
Column | MSCW | Comments |
Customer ID | M | Usually a ship-to or bill-to level ID - depending on your business’s perspective |
Customer Name | M | Name of the customer or customer location |
Customer Hierarchy 1 | M | Customer classification structure - eg. Group, Class, Segment etc. - up to 4 levels |
Customer Hierarchy 2 | C | Customer classification structure - eg. Group, Class, Segment etc. - up to 4 levels |
Customer Hierarchy 3 | C | Customer classification structure - eg. Group, Class, Segment etc. - up to 4 levels |
Customer Hierarchy 4 | C | Customer classification structure - eg. Group, Class, Segment etc. - up to 4 levels |
Bill-To Customer | C | Relationships to parent/child company info - whichever level is not used in the primary customer ID |
Ship-To Customer | C |
|
Customer Geography 1 | M | Geographical hierarchy of the customer (could be in transactions instead) - something like State / Country or Country / Region - up to 2 levels |
Customer Geography 2 | C | Geographical hierarchy of the customer (could be in transactions instead) - something like State / Country or Country / Region - up to 2 levels |
Customer Status | S | Indicates whether the customer is active or inactive |
Generic Customer Attribute 1 | C | Additional attribute / dimension at the customer level that is important to filtering and aggregating data |
Generic Customer Attribute 2 | C | Additional attribute / dimension at the customer level that is important to filtering and aggregating data |
Generic Customer Attribute 3 | C | Additional attribute / dimension at the customer level that is important to filtering and aggregating data |
Sample
See the downloadable Excel file.
Product Master
Criticality: REQUIRED
This is your product data at the level of granularity typically used for invoices. Most often this will be a sold finished good or sku, but in some situations, particularly for customizable products, it might be at a component level. Again, how this is oriented on your ERP will typically be sufficient.
Legend
Column | MSCW | Comments |
Product ID | M | Usually a sku, or a configurable base product, depending on business |
Product Name | M | Name or label for the product |
Product Hierarchy 1 | M | Product classification structure - eg. Group, Class, Segment etc. - up to 4 levels |
Product Hierarchy 2 | C | Product classification structure - eg. Group, Class, Segment etc. - up to 4 levels |
Product Hierarchy 3 | C | Product classification structure - eg. Group, Class, Segment etc. - up to 4 levels |
Product Hierarchy 4 | C | Product classification structure - eg. Group, Class, Segment etc. - up to 4 levels |
Product Type 1 | S | Product use case structure - this might be something like an industry or a vertical - up to 2 categories |
Product Type 2 | C | Product use case structure - this might be something like an industry or a vertical - up to 2 categories |
Base UOM | S | Product sku's unit of measure - disregard if skus are not at package level |
Product Costs | S | Costs can be bypassed if margin information is available in transactions |
Product Status | S | Indicates whether the product is active or inactive |
Generic Product Attribute 1 | C | Additional attribute / dimension at the product level that is important to filtering and aggregating data |
Generic Product Attribute 2 | C | Additional attribute / dimension at the product level that is important to filtering and aggregating data |
Generic Product Attribute 3 | C | Additional attribute / dimension at the product level that is important to filtering and aggregating data |
Currency Conversion
Criticality: REQUIRED IF multiple currencies are used in TRANSACTION data
Pricefx will convert all prices and data to the user’s currency of choice and can standardize on a currency if multiple currencies are used in pricing operations and analytics.
Recommendations:
If transaction data only uses one currency, this can be skipped entirely.
If this data isn’t available, a simple version that uses a single, common conversion rate per currency can be used instead. Choose the rates you’d like to use for each currency conversion and set the valid from and valid to dates to something like 1/1/2025 and 12/31/2100 (or 31/12/2100) for simplicity
Legend
Column | MSCW | Comments |
Currency Valid From | M | The starting date for this particular exchange rate. Since currencies fluctuate over time, these can be set to change as frequently as daily (but any timeframe shorter than this is also fine). |
Currency Valid To | M | The end date for this particular exchange rate. |
Currency From | M | The currency that will be converted from. |
Currency To | M | The currency that will be converted to. |
Exchange Rate | M | The exchange rate that should be used to convert from the “Currency From” to the “Currency To” for the validity dates selected. |
UOM Conversion
Criticality: REQUIRED IF multiple units of measure are used in TRANSACTION data
Analytics and prices can be managed at a UOM or a higher level in Pricefx and then standardized if conversion data is available. The standard UOM conversion is not product specific, to this is typically most applicable when going from metric to imperial rather than from something like volume to weight (this can be used, though, if it’s standardized). It’s best to provide any non-standard UOM conversions in your data.
Legend
Column | MSCW | Comments |
UOM From | M | Unit of measure to convert from. |
UOM To | M | Unit of measure to convert to. |
UOM Conversion Factor | M | The conversion factor to use to convert from the “UOM From” to the “UOM To.” |
Quote Line Items
Criticality: OPTIONAL
To add quote-time context to transaction detail information.
If pricing decisions are made based on quote context (eg, quote volume), then this is highly recommended.
Must provide columns needed to link back to Transactions table.
List Price History
Criticality: RECOMMENDED
For deriving list-price at the time of any invoice
Must provide columns needed to link back to Transactions table
May commonly be location/region specific
Cost Price History
Criticality: RECOMMENDED
For deriving cost-price at the time of any invoice
Must provide columns needed to link back to Transactions table
May commonly be location/plant specific
Accelerator Requirements Matrix
The below matrix is a rapid reference on which of the above data tables are leveraged/useful to each of the Pricefx Core & Accelerator capabilities.
Each is prioritised as above with MSCW (Must, Should, Could, Won't) Priority.
Pricefx Capability | ||||||
|---|---|---|---|---|---|---|
Sales & Customer Insights | M | M | M | W | C | C |
Negotiation Guidance | M | M | M | C | S |
Found an issue in documentation? Write to us.