You are here:
Considerations and Limitations
Review the system limits, feature boundaries, and operational requirements before you design and configure Penny Perfect Pricing.
Required Editions
| Available in: Lightning Experience |
| Available in: Enterprise and Unlimited Editions in Manufacturing Cloud, Automotive Cloud, and Consumer Goods Cloud, with required add-ons. |
System Limits and Scalability
Review the supported system thresholds and limits to ensure optimal calculation performance.
| Dimension | Supported Limit | Operational Recommendation |
|---|---|---|
| Line Items per Order | Up to 1,000 line items | Split orders with more than 1,000 line items into multiple transactions to prevent execution timeouts. |
| Pricing Condition Master Records | Up to 40 million records per Sales Organization | Archive expired condition records by marking Status as Deleted (for records with Valid To in the past) to optimize consolidated lookup performance. |
| Calculation Schema Steps | Up to 28 steps supported in production | Keep calculation schemas under 20 steps whenever possible to maximize processing speed. |
| Search Strategy Hierarchy Depth | Up to 7 Account hierarchy levels / 5 Product hierarchy levels | Limit hierarchy lookup steps to 3-4 levels for faster runtime condition evaluation. |
| Decimal Precision and Rounding | 2, 4, or 6 decimal places | Commercial rounding, round up, and round down modes are supported. |
Feature Capabilities and Integration Support
Understand product capabilities and functional boundaries prior to implementation.
- Financial Scope: Penny Perfect Pricing determines net order and item prices. It does not post General Ledger (GL) accounting entries or generate tax invoice documents.
- Salesforce Promotions: Integration with standard Salesforce Commerce or Loyalty promotions is not supported in this release.
- ERP Synchronization: Pricing accuracy depends directly on maintaining valid condition data, validity dates, sales organization scopes, and account/product hierarchies aligned with your external ERP system.
Operational and Configuration Requirements
Follow these mandatory prerequisites to ensure successful price calculation:
- Initial Job Execution Required: The External Pricing Key Value Consolidation data pipeline job must complete successfully at least once before the system can calculate prices on orders.
- Data Load Requirement: Always re-run the External Pricing Key Value Consolidation job immediately after loading or updating condition master records in External Pricing Key Value or tier records in External Pricing Key Value Tier.
- Deleting External Pricing Key Value Records: The External Pricing Key Value Consolidation job builds the External Pricing Key Value Consolidated View from each record's current Status. To remove a condition record from pricing evaluation, first set its Status to Deleted and run the Consolidation job so the removal is reflected in the consolidated view — then hard-delete the underlying External Pricing Key Value record if needed. Don't hard-delete a record before the job has run against its Deleted status; the job never gets the chance to process the removal, and the consolidated view can be left out of sync.
- Activation Requirement: All expression set components (Pricing Key Types, Search Strategies, Pricing Specifications, and Calculation Schemas) and the Procedure Plan definition must be activated before they can evaluate calculations.
- Sandbox Testing: Always validate custom calculation schemas, scale tier behavior, and procedures in a sandbox environment. Verify Salesforce calculated prices against reference ERP output invoices prior to deploying to production.
- Pricing Key Type Changes Aren't Retroactive: Editing a Pricing Key Type's key attributes after External Pricing Key Value records already reference it isn't tracked, and users aren't blocked from making the change. Any subsequent edit to an existing External Pricing Key Value record — even to an unrelated field such as Valid To — revalidates the record against the Pricing Key Type's current configuration, and fails with "at least one key field required by the associated Pricing Key Type must have a value" if the record has no value for a newly required key. Treat Pricing Key Type changes as forward-looking only: they apply to new pricing condition records, not to ones created under the prior configuration.
Did this article solve your issue?
Let us know so we can improve!
