Skip to main content
If something isn’t working with your Opportunities or Orders, find the symptom below. Most problems trace back to a prerequisite or a setting on a record, not to a bug. Work through the matching section.

​
Opportunities

What you see. Clicking Convert To Order on an Opportunity errors out instead of creating an Order.Why. The conversion checks several prerequisites first and stops at the first one that isn’t met. The Opportunity must have an Account, a Billing Contact, and a Customer Type; it must have at least one product; it must not already be converted; and Used By fusionCore must be checked.Fix. Open the Opportunity and confirm each item: set the Account, Billing Contact, and Customer Type (Organization or Individual), add at least one product, check Used By fusionCore, and make sure it hasn’t already been converted. Then convert again. See Opportunity to Order Conversion.
What you see. You converted an Opportunity to an Order, but the Opportunity’s stage is still open rather than Closed Won.Why. Conversion alone does not close the Opportunity. Its stage only flips to Closed Won once the linked Order reaches Payment Received status — that is, when the full balance has been paid.Fix. Take payment on the Order until it is fully paid and reaches Payment Received; the Opportunity’s stage updates then. See Opportunity to Order Conversion.

​
Orders

What you see. The Create Order action doesn’t appear on the record you’re working from.Why. Usually one of two things: the Create Order quick action isn’t on the page layout, or the user is missing the FC Commerce - Create Order permission set.Fix. Confirm the Create Order quick action is on the Account or Contact page layout, then ask your administrator to assign the FC Commerce - Create Order permission set. See Orders.
What you see. You try to add or remove products on an Order, but the option is unavailable or blocked.Why. Products can only be added while an Order is in Draft or Open status. Once it has progressed past that, its products are locked.Fix. Add products while the Order is in Draft or Open. Once it has progressed, you cannot change its products. See Adding a Product to an Order.
What you see. You posted an Order but no Accounts Receivable entry appeared.Why. An Accounts Receivable Financial Event is created only for Invoice-type Orders, and only once per Order. Paying an Order in full upfront creates no A/R because there’s no remaining balance, and re-posting an already-posted Order does not create a duplicate.Fix. Confirm the Order is an Invoice with a balance still owed. If it was paid in full upfront, no A/R is expected. See Posting an A/R.
What you see. An Order shows a status you don’t recognize, or you’re unsure which values are valid.Why. fusionCore tracks an Order with its own status field, and the valid values are a fixed set: Draft, Open, Pending Payment, Partial Payment Received, Payment Received, Voided, and Written Off. Each reflects where the Order is in its lifecycle.Fix. Match the status against this list to understand what the Order can and can’t do next. Voided and Written Off are final and can’t be reversed. See Order Statuses.

​
Paying and Refunding

What you see. When you try to pay an Invoice Order, you get an error that it can’t be paid.Why. An Invoice must be posted (Activated) before it can be paid. Paying an Invoice that hasn’t been posted yet is blocked with a “cannot pay an unposted invoice” error.Fix. Post (activate) the Invoice first, then take the payment. See Paying on an Order.
What you see. A payment method (Payment Type) you expected to use doesn’t show up on the pay screen.Why. The pay modal only shows Payment Types that match the Order. A Payment Type is filtered out by its display visibility, its payment method, or because it doesn’t support the Order’s currency. This is a configuration issue on the Payment Type, not on the Order.Fix. Open the Payment Type and check its display visibility, payment method, and supported currencies against the Order. See Paying on an Order.
What you see. You took a payment, but its Financial Event sits in Pending and never moves to Succeeded on its own.Why. Whether a payment auto-approves to Succeeded is controlled by the Payment Type’s Auto-Update Payment FE To Succeeded setting. When that is unchecked, the payment’s Financial Event stays Pending until someone approves it manually.Fix. Either approve the Pending payment manually, or — if you want payments of this type to auto-approve — turn on Auto-Update Payment FE To Succeeded on the Payment Type. See Paying on an Order.
What you see. You want to refund a payment, but there’s no Refund action where you expect it.Why. A refund is started from the original Payment Financial Event, not from the Order, and only a Succeeded payment can be refunded. If the original payment is still Pending, there’s nothing to refund yet.Fix. Open the Succeeded Payment Financial Event and use its Refund action. Enter the refund quantity as a negative number, or the refund won’t process correctly. If the original payment is still Pending, approve it first. See Refunding an Order.

​
Adjustments, Write-Offs, and Voids

What you see. The void is blocked or unavailable on an Order.Why. Voiding has strict conditions. The Order must be a posted (Activated) Invoice, and the void is blocked if there is any Succeeded payment on the Order or any pending (non-installment) Financial Event.Fix. Confirm the Order is an activated Invoice with no Succeeded payment and no pending Financial Events, then void it. If a payment has already succeeded, void is no longer an option. See Voiding an Order.
What you see. The adjustment is blocked, or a specific line can’t be adjusted.Why. Adjusting requires an Activated Invoice with a positive balance, and each line you adjust must already have a prior Accounts Receivable Financial Event Line. A line without an A/R Financial Event Line can’t be adjusted.Fix. Confirm the Invoice is activated and still has a positive balance, and that each line you’re adjusting has an A/R Financial Event Line behind it. Note that only negative adjustments are supported. See Adjusting an Order.
What you see. You submitted a write-off, but the Order’s status hasn’t changed to Written Off.Why. The Write-Off Financial Event is created as Pending and the Order status only changes to Written Off when that event is approved (reaches Succeeded). With the Business Unit’s auto-approve turned off, the status won’t change until someone approves it.Fix. Approve the Write-Off Financial Event so it reaches Succeeded; the Order status updates then. See Writing Off an Order.
What you see. Submitting a write-off fails with an error.Why. Each Order Product’s Business Unit must have a Default Write-Off Account set. The check runs against the Business Unit on each order item, so a single item whose Business Unit has no Default Write-Off Account is enough to stop the write-off.Fix. Open each Business Unit used by the Order’s products and set a Default Write-Off Account, then write off again. See Writing Off an Order.
What you see. The product-search dropdown on the Order Entry screen returns fewer or more products than you want.Why. The number of results is controlled by a Custom Metadata record. When its value is blank, 0, or negative, the search falls back to showing 10 results.Fix. Set a positive number in the Integer Value of the FC Max No Of Results In Product Search Constant record to control how many products appear. See Configuring Max Number of Products in Search.

​
Account Credit

What you see. An Account Credit can’t be applied to an Order, or the payment is rejected.Why. The Order and the Credit must match on both the Customer Type and the specific customer — the Contact for an Individual, or the Account for an Organization. A Credit tied to one customer can’t pay another customer’s Order even when the Customer Type is the same. The payment also can’t exceed the Credit’s Available Credit.Fix. Use a Credit that belongs to the same customer and Customer Type as the Order, and keep the payment at or below the Available Credit — apply another method for any remainder. See Paying with Account Credit.
What you see. You processed a refund but no Account Credit record appeared on the customer.Why. A Credit record is created automatically only when the refund is paid with the Account Credit method and that Refund Financial Event is approved so it reaches Succeeded. A refund using another method, or one still pending approval, produces no Credit.Fix. Process the refund using the Account Credit method and approve it so it reaches Succeeded; the Credit record is created then. See Refunding to Account Credit.

​
Installments

What you see. Generating an installment plan is blocked or errors instead of creating installments.Why. Generation is blocked for certain Order states: an Order that is both a quote and already activated, an invoice with a zero balance, or an Order whose status is Payment Received, Written Off, or Voided. An unsupported frequency value also fails.Fix. Confirm the Order is in a state that allows generation and use a supported frequency. Always check the preview before generating — the calculator can quietly produce nothing for an invalid request rather than raising an error. See Creating Installments.
What you see. A product you expected to include in an installment plan doesn’t appear as a selectable line.Why. Only products that allow installments appear. Allow Installments ships checked, so the product was likely unchecked deliberately to exclude it.Fix. Open the product and confirm Allow Installments is checked. See Enabling Installments.
What you see. After revising the plan, edits you’d made to pending installments are gone.Why. Revising deletes the current pending installments and replaces them — this is by design. Failed installments are cancelled in the process; only succeeded ones carry over.Fix. Make your adjustments through the revise itself rather than editing pending installments by hand, since a later revise will replace them. See Revising Installments.
What you see. The Pay Financial Event action is unavailable or blocked on an installment.Why. Manual payment requires several conditions: the Financial Event must be an installment in Pending status, the Order must have a positive balance due and a Bill To Contact, and the sum of the Order’s pending installments must still equal its balance due. If the plan has drifted out of sync, payment is blocked.Fix. Confirm the installment is Pending, the Order has a Bill To Contact and a positive balance, and the plan is in sync. If it isn’t, revise the installment plan to realign it, then pay. See Manually Paying for an Installment.

​
Auto-Charge

What you see. The auto-charge job ran but an installment you expected to be charged wasn’t.Why. Auto-Charge silently skips an installment that has no Wallet Item, is cancelled, is in the wrong Order status, doesn’t have its price and tax calculated, or has hit the retry cap. The most common cause is a missing Wallet Item — without one, the installment is never charged and no error is raised.Fix. Open the installment and confirm it has a Wallet Item, the right status, and calculated amounts. After replacing a payment method, verify the installments you expect to be charged carry the new Wallet Item. See Updating the Auto-Charge Payment Method.
What you see. A scheduled run was missed, and the installments that were due on that day were never charged afterward.Why. Auto-Charge charges only installments due exactly today. It does not back-fill past-due installments on a later run.Fix. Charge the missed installments manually, or revise the plan so the outstanding amounts fall on a future date the batch will pick up. See Configuring Auto-Charge.
What you see. A charge failed and the job never tried again.Why. Retries are governed by a Constant record. The number you may have seen described as a default of 3 is the shipped record value — when that record is missing, the code default is 0, meaning no retries.Fix. Have your administrator confirm the retry-count Constant record exists and is set to the value you want. See Configuring Auto-Charge.
What you see. The product’s auto-charge setting is on, yet the daily batch doesn’t charge its installments.Why. The product’s auto-charge checkbox governs renewal behavior only — it does not drive the daily installment batch. The batch charges installment Financial Events based on their own setup (a Wallet Item, the right status, a date of today, and calculated amounts).Fix. To get installments charged, make sure each installment has a Wallet Item and meets the batch’s conditions, rather than relying on the product flag. See Configuring Auto-Charge.