Skip to main content
If something isn’t working in the Product section, find the symptom below.

Product Set Up and Pricing

What you see. A product shows a price in your default currency, but in another currency it has no price (or a buyer in that currency can’t be charged).Why. A product’s price lives in a separate Price Book entry for each currency. Filling in Standard Price on the product creates the standard entry for the product’s own currency only — it does not create entries for any other currency.Fix. Add a Price Book entry for each additional currency the product should sell in. Other currencies and custom Price Books each need their own entry. See Price Books.
What you see. Products have a Standard Price filled in, but pricing fails across the board.Why. All standard pricing flows through the standard Price Book. If that Price Book is inactive, no standard prices apply.Fix. Make sure the standard Price Book is active. See Price Books.
What you see. You created a subscription product, but it can’t be added to an order or sold.Why. A subscription product can’t be sold until it is fully set up: it must be linked to a Subscription Plan and that plan’s price book, it must have Is Subscription checked, and the standard Active field must be checked. Missing any one of these stops the sale.Fix. On the product, confirm it is linked to a Subscription Plan and that plan’s price book, check Is Subscription yourself (nothing sets it for you), and check Active after the rest is in place. See Subscription Products.
What you see. Saving a product errors when you set its A/R or Revenue GL Accounts.Why. The Business Unit on the chosen GL Accounts must match the product’s Business Unit. A mismatch blocks the save.Fix. Set the product’s Business Unit and its GL Accounts to the same Business Unit, then save. See Subscription Products.
What you see. You try to add an image to a product and it doesn’t take, or it doesn’t show in the portal.Why. The image is added through the product’s Upload Image action, which walks you through uploading, cropping, and saving the file. Skipping a step (for example, not saving after the crop) leaves the image unset.Fix. Open the product, click Upload Image, choose the file, crop it, and click Save. See Product Image Upload.

Conditions

What you see. You added several Product condition lines expecting them all to be required (AND), but the condition matches when only one is true.Why. Product condition lines are always combined with OR. The Record Logic setting (AND / OR / Custom) applies only to Record condition lines, not Product lines.Fix. If you need true AND logic across items, model it with Record condition lines, which honor Record Logic. Product lines will always behave as “any one matches.” See Condition Lines.
What you see. You change the connection between the Record group and the Product group and the result doesn’t change.Why. The AND vs OR connection between the two groups only affects the outcome when you have configured both Record lines and Product lines. With only one kind of line, there is nothing for it to combine.Fix. This is expected. The setting only matters once both a Record group and a Product group exist. See Condition Lines.
What you see. You enter a class name in Apex Class on a condition and the save is rejected.Why. The class must be a valid condition evaluator class. A missing class, a typo in the name, or a class that isn’t a condition evaluator is rejected on save.Fix. Confirm the class exists and is a proper condition evaluator, then re-enter the exact class name. See Apex Conditions.

Taxes

What you see. A product that should be taxed has no tax on the order.Why. Tax requires three things to line up: the product must be marked taxable; there must be a tax product in the same Business Unit; and either a tax product’s condition must match the item or that Business Unit must have a default tax product. If nothing matches and there’s no default, tax calculation errors and blocks the order.Fix. Mark the product taxable, make sure there is a tax product in the same Business Unit, and set a default tax product for that Business Unit so items with no condition match are still covered. See Marking a Product as Taxable and Setting up the Default Tax Product.
What you see. An order for a tax-exempt customer still lists a tax line.Why. For an exempt customer, fusionCore does not remove the tax line — it writes the line at a $0 amount.Fix. This is expected. The customer is charged nothing; the line stays for record-keeping at $0. See Marking a Product as Taxable.
What you see. A tax product errors on save, or the percentage and flat amount don’t behave the way you expected.Why. A percentage tax and a flat tax are mutually exclusive. A non-zero Tax Rate makes the tax a percentage; leaving the Tax Rate at zero uses the tax product’s standard price as a flat amount, which requires a standard Price Book entry in the order’s currency.Fix. Pick one model. For a percentage, set the Tax Rate. For a flat amount, leave the Tax Rate at zero and create a standard Price Book entry in the order’s currency. See Tax Products.
What you see. You attach a condition to a tax product and it isn’t accepted.Why. Tax products support only Simple conditions. An Apex condition on a tax product is rejected.Fix. Use a Simple condition on the tax product. See Tax Products.
What you see. You try to mark a tax product inactive but can’t, or removing it breaks tax calculation.Why. Once a tax product is set as the Business Unit’s default, it must stay active and condition-free so every taxable item has something to fall back on. Without a default, an item with no matching tax product throws an error and blocks the order.Fix. Keep the default tax product active and without a condition. To retire it, set a different active tax product as the default first. See Setting up the Default Tax Product.

Discount Codes

What you see. A buyer enters a discount code and it isn’t accepted.Why. A code is rejected when any of these is true: it isn’t active; the order date is outside the code’s date range; it has hit a usage limit (an Overall Usage Limit of 0 blocks it entirely, since zero is treated as fully used up); or the products on the order aren’t in the code’s eligible product list.Fix. Confirm the code is active and within its date range, check it hasn’t reached its usage limits (and isn’t set to an Overall Usage Limit of 0), and make sure the order’s products are on the code’s eligible list. See Creating a Discount Code.
What you see. Editing the discount percentage or deleting the code is blocked.Why. Once a code has been applied to any order, it is locked — you can’t change its percentage or delete it.Fix. Leave the used code as is and create a new code for the new value. See Creating a Discount Code.
What you see. You removed a product from a discount code’s eligible list, but it’s still eligible, or re-adding the same product brings back its old settings.Why. Removing a product is a soft delete — it deactivates the eligibility record rather than deleting it. Re-adding the same product reactivates that existing record instead of creating a new one.Fix. Expect the existing record to be reused when you re-add a product. If the eligibility looks wrong after a remove-and-re-add, check the reactivated record’s settings rather than assuming a fresh one was created. See Removing Products from Discount Codes.

Benefit Allocations

What you see. Adding a beneficiary is blocked with a validation error.Why. The Purchase Activity is already at its Maximum Allocations. The maximum is a static cap and is never decremented — when an allocation ends, the count that changes is Active Beneficiaries, not the maximum.Fix. Free up a slot (see the transfer and restore notes below) or raise Maximum Allocations if appropriate. Also confirm the person is eligible: the selector shows only active Contacts on the Account that don’t already have an active allocation for the same Purchase Activity, and the benefit start and end dates must match the subscription’s. See Creating Benefit Allocations.
What you see. You try to transfer a benefit allocation at (or near) the Maximum Allocations and it’s blocked, or the transfer consumes one more slot than expected.Why. A transfer expires the original allocation and creates a new active one. When the product’s Restore Allocation to Purchase Activity is unchecked, the expired original keeps counting toward active beneficiaries, so the transfer takes an extra slot — and at capacity it’s blocked. Only when Restore is on is a transfer slot-neutral.Fix. Turn on Restore Allocation to Purchase Activity on the product so transfers are slot-neutral, or free up a slot before transferring. See Transferring Benefit Allocations and Setting up Benefit Allocation on a Product.
What you see. An allocation has ended or expired, but the Purchase Activity still treats its slot as used.Why. When Restore Allocation to Purchase Activity is unchecked, an ended or expired allocation keeps consuming its slot permanently.Fix. Turn on Restore Allocation to Purchase Activity on the product so a freed allocation returns its slot. See Setting up Benefit Allocation on a Product.
What you see. A subscription renewed, but one or more benefit allocations didn’t come across to the renewed subscription.Why. Carry-over is automatic but selective. An allocation only carries to the renewed subscription when its end date matches the prior Purchase Activity’s grace-period end date. Off-cycle or mid-term allocations aren’t carried over.Fix. For an allocation to carry over, align its end date with the Purchase Activity’s grace-period end date. Re-add any off-cycle allocations on the renewed subscription manually. See Carrying Over Benefit Allocations on Renewal.