None is rejected for Instrument Type fields, causing incorrect defaults (e.g., 0) and wrong pricing

[sergeiosipov]

Problem

Some Instrument Type fields do not accept None as a valid value. During Instrument creation, this causes None to be replaced with a default numeric value (commonly 0).

Why this is an issue

0 is treated as a meaningful value, not as “unset”. As a result, downstream pricing and recalculation logic may not trigger, leading to incorrect persisted values.

Example

1. Create a Bond instrument with an accrual schedule
2. A field that should be None (meaning “derive from schedule”) is set to 0
3. During pricing:
   • The engine sees a numeric value (0 or any number)
   • Recalculation is skipped
4. The system writes 0 instead of the correct calculated value

Expected behavior

• Instrument Type fields that represent “unset / derive / calculate” must allow None
• On creation, these fields should remain None unless explicitly provided
• Pricing logic should treat:
  • None → value must be calculated
  • numeric value → explicit override

Actual behavior

• Validation rejects None (“None is not a valid value for Instrument Types”)
• None is coerced into 0 (or another numeric default)
• Pricing logic does not recalculate and persists incorrect values

Impact

• Incorrect pricing results (e.g. bonds with accrual schedules)
• Silent data corruption risk: stored values look valid but are wrong

Suggested fix

• Allow None for affected Instrument Type fields at validation/schema level
• Ensure None is preserved through serialization/deserialization (no coercion to 0)
• (Optional safety) If accrual schedule exists and value was not explicitly set, force recalculation during pricing