Submit Button Disabled After CLIC Recalculation

Purpose

Use this guide when the Submit button becomes disabled after Quote, Agreement/Promotion or Rebate Agreement recalculation, or after opening or selecting a line item, without any user-triggered change having been made.

This behavior usually indicates that the application considers the document state to be different from the state used for the latest calculation. This difference may have a legitimate cause, or it may be caused by configuration or by a product defect that incorrectly marks the document as changed.

Background

CLIC documents track all changes. When an input changes, the calculation results may no longer represent the latest document state, so the user is expected to recalculate before submitting. The interface is designed to make this state visible and prevent submission based on outdated results.

The most common implementation problem is that header logic and configurator logic do not produce an identical state. The application then detects a change after recalculation even though the user made no meaningful change. In other cases, a dynamically generated value or identifier changes on every execution and repeatedly makes the document appear modified.

Root Causes

1. Inconsistent state between header logic and configurator logic

An input may be created or updated by header logic but not represented consistently in the corresponding configurator logic. The same business value can therefore be interpreted as a new or changed value after recalculation.

Typical causes include:

• An input exists on one side but not the other.

• The input name or data type differs.

• A value is added, removed, or converted between a null value and an empty string.

2. Unstable generated inputs or values

Some configurations create a new input name or value on every execution. Common examples are timestamps, UUIDs, random values, or other run-specific data. If such an input is not of type hidden, it will participate in change detection and make the document appear outdated after every recalculation or configurator display.

3. Technically different representations of the same value

Two values may look identical to a user but differ at the technical level. Examples include:

• Additional or missing whitespace.

• Different capitalization.

• Different date, time, number, or locale formatting.

• Different precision or rounding.

• Different identifier formatting.

• Null versus empty string.

The comparison must be made using the actual serialized values returned by the logic, not only the rendered screen text.

4. Dynamic inputs are not handled consistently

Complex configurators may create inputs dynamically. If the set of inputs differs between initial load, recalculation, or line item selection, the document may be marked as modified or may report missing fields.

Every dynamic input should have a stable name, a deterministic value, and a clearly defined type.

Troubleshooting Flow

1. Recalculate the document and check whether Submit is enabled immediately afterwards.

2. Repeat the scenario with the browser console open. Watch for the following error message:

   

3. Determine when the state changes:

   • immediately after recalculation;

   • after selecting a line item; or

   • only after a user edits a value.

4. Capture the input set before and after the action, including exact names, types, and serialized values. You can use the following Groovy code to exclude specific inputs and their values from the old-value/new-value comparison.

   Groovy

   def hiddenInputs = [ "office", "customer", "distributionChannel", "sku", "targetDateLineItem" ]
   
   def ce = api.createConfiguratorEntry()
   for (name in hiddenInputs) {
     api.inputBuilderFactory()
       .createHiddenEntry(name)
       .addToConfiguratorEntry(ce)
   }
   
   return ce
   

5. Identify any values that were added, removed, renamed, or reformatted.

6. Check for timestamps, UUIDs, random values, generated names, whitespace differences, and null/empty conversions.

7. Compare the output of header logic, configurator logic, and any supporting logic.

8. After correcting the configuration, recalculate and save an affected document, then repeat the test several times.

Resolution Guidance for Implementation Partners

• Keep input names stable across executions.

• Ensure header logic and configurator logic use the same names, types, formats, and value conventions.

• Use shared formatting and conversion helpers where the same business value is produced in multiple places.

• Avoid persisting per-execution values as part of the normal configurator state.

• Define dynamic inputs consistently for initial load, recalculation, and line item actions.

• When the configuration is corrected, recalculate the affected documents so their persisted state matches the corrected configuration.

• Test repeated recalculation, line item selection, and all relevant dynamic input variants.

When to Escalate

Escalate to Product or Engineering when:

• Submit becomes disabled although no input name or value changed.

• The behavior reproduces with a minimal or clean configuration.

• The issue depends on a specific product version or build.

• Console errors remain after input names and values have been verified.