Known Issues Across All Services
The following items represent known issues that you might encountered when using REST web services with Unifier.
- When updating a Date Only Picker value using the REST API, the system validates that the combination of month, day, and year forms a valid date. However, unlike the UI, the API does not enforce the rule requiring the date to be later than 12/31/999. If a year with fewer than four digits is submitted, it is accepted as entered. For example, a value of 01-01-25 is saved as 01-Jan-0025.
- The
createWBSservice is case insensitive, meaning it treats CBS codes like A-B-C-D and a-b-c-d as equivalent. - Any transaction against an inactive Fund Breakdown Structure (FBS) code is not rejected.
- Auto-population of the Amount field on the header form (from Line Items) is only supported if it is included in the form during the form design in uDesigner. For more information, refer to the following guides:
- Unifier uDesigner User Guide
- Unifier General Administration Guide
- Unifier Modules Setup Administration Guide
- Shells can have the same name under different parent shells. If you attempt to create a business process (BP) record and provide a value for a shell picker data element (DE), the system will display an error if multiple shells share the same name (indicating that more than one shell matches the provided name).
- When numeric fields—such as float, double, currency, or decimal—contain values longer than seven digits, REST responses may serialize these numbers using scientific notation (for example, 12345678 may appear as 1.2345678E7). This behavior is expected and aligns with standard practices for JSON serialization and number formatting.
Some downstream systems and tools do not automatically interpret scientific notation, which can result in incorrect processing if not properly managed. Systems that do not natively support scientific notation may:
- Reject the entire payload.
- Unexpectedly truncate or round numeric values.
- Interpret numeric values as strings rather than numbers.
To address this issue:
- Use data types and libraries that can parse scientific notation and maintain numeric precision.
- If your downstream system does not support scientific notation, convert values to plain (non-scientific) string format before transmitting them, and then configure the downstream system to parse these values as fixed-precision numeric types.
Last Published Wednesday, December 10, 2025