Overview
In Framework Agreement Management (FAM), the Negotiated Recurring numeric input may display an unwanted leading zero after you clear the field and type a new value (for example, typing 230 displays as 0230, often visible as 0 → 02 → 023 → 0230). This is a product-level UI behavior in older negotiation input implementations and is not typically accompanied by an explicit error message.
The issue is not observed in FAM R38.0.4, where the negotiation input was rewritten. The recommended resolution is to upgrade/move to the FAM R38.x stream (R38.0.4 confirmed).
Solution
Issue (Symptom)
- After clearing Negotiated Recurring and typing a new value (for example,
230), the field displays0230. - The sequence may be visible as:
0 → 02 → 023 → 0230. - There is typically no pop-up error message; this is an input/UI behavior defect.
Environment / Context
- Reported on: R33 GA (33.0.4.1) (and other streams using the same legacy negotiation input component pattern).
- Browser: Chrome (also reproducible in other browsers).
- Environment type: sandbox.
- Relevant setting:
input_minmax_restriction = true.
Affected Versions
This behavior is associated with older FAM negotiation input implementations that use a legacy controlled numeric input pattern (reported in R33 GA (33.0.4.1) and other streams using the same legacy component behavior).
Root Cause (Why It Happens)
In the older implementation, Negotiated Recurring behaves as a controlled numeric input. When the field is cleared:
- The cleared value becomes an empty string (
""). - The change handler coerces that empty string to numeric
0(for example, using unary+or equivalent numeric coercion). - The component state is updated with
0, and the input is immediately re-rendered showing0. - When you type again, your digits append after the existing
0, producing02,023,0230, etc.
Note: the underlying numeric value may still evaluate correctly, but the display is misleading and disruptive during editing.
Resolution (Fixed in R38 Stream)
Upgrade/move to the FAM R38.x stream to avoid this defect.
- The issue was not reproduced in FAM R38.0.4.
- In R38, the negotiation input was rewritten to handle empty-string input explicitly and prevent the UI from forcing
0back into the field after clearing.
Verification (Post-Upgrade)
After upgrading to R38.x (R38.0.4 confirmed):
- Open a Framework Agreement in Draft status.
- Go to Products, expand a product, and open the Charges (Product) tab.
- Click into Negotiated Recurring to edit.
- Select all text and delete to clear the field.
- Type a new value (for example,
230).
Expected result: The field displays 230 (no leading 0), and the 0 → 02 → 023 → 0230 behavior does not recur.
Frequently Asked Questions
- 1. How do I know I’m hitting this specific issue?
- You’ll see the Negotiated Recurring field display a leading zero after you clear it—e.g., typing
230shows0230(often appearing as0 → 02 → 023 → 0230). There is typically no error dialog. - 2. Is this caused by my browser or org configuration?
- This is a product-level UI behavior in the older FAM negotiation input implementation and is reproducible across browsers. It is not specific to a single org configuration.
- 3. What version contains the fix?
- The behavior was not observed in FAM R38.0.4. The practical mitigation is to upgrade/move to the R38.x stream (with R38.0.4 confirmed as not exhibiting the issue).
- 4. What should I test after upgrading?
- Re-run the same edit flow: clear Negotiated Recurring, then type a new value. Confirm the field remains empty when cleared and displays exactly what you type (e.g.,
230, not0230). - 5. What if I still see 0230 after upgrading?
- Confirm the installed FAM package version is on the R38.x stream in the affected environment, then retest in a fresh session. If the symptom persists, capture a short screen recording of the steps and raise a new support request including your installed package version and exact reproduction steps.
Matej Storga
Comments