Price Freeze Flag in EDI

Based on standard IFS EDI logic, what you are seeing is likely expected behavior, although the exact outcome can depend on the ORDCHG content and your customer order message setup.

An ORDCHG message is handled as a change request against an existing customer order. When the message introduces a new line, IFS may process that line as an added order line rather than as part of the original imported order. The standard ORDCHG process is intended to transfer approved changes to the customer order, including added lines and quantity/date modifications.

 

As a result:

• Original lines created by the ORDERS message retain their frozen pricing.
• New lines added through ORDCHG can be treated as newly created order lines and therefore follow normal order-line defaults.
• Normal order-line defaults generally leave Price Freeze = False, allowing IFS pricing logic to be applied
   

  I would still recommend checking:

• Whether the new ORDCHG line contains an explicit price in the EDI message.
• Whether any custom EDI mapping, event actions, BPA workflows, or integrations are updating the Price Freeze flag.
• The Customer Message Defaults and EDI setup used for ORDERS versus ORDCHG processing.
• The Order Line History for both an original ORDERS line and an ORDCHG-created line to see exactly which attributes were set during message processing
  
  BPA- Set PriceFreeze:Frozen on customer order line | IFS Community

Hi ​@B.COLAS 

Why ORDCHG-created lines likely don't inherit this:

ORDERS and ORDCHG go through different processing logic in IFS:

1. ORDERS (initial order creation) has explicit, documented logic that forces Price_Freeze_Db = TRUE on every line as part of the "create customer order from incoming EDI" routine. This is a deliberate override baked into that specific entry point, precisely so the EDI-supplied price sticks instead of being recalculated from price lists/agreements.
2. ORDCHG (order change) is primarily designed to modify an existing order — change quantities, dates, cancel lines, etc. When it adds a new line (e.g., the customer appends a line to an already-placed order), that new-line creation most likely falls through to the standard/generic "add customer order line" logic rather than the special-cased EDI-order-creation logic used by ORDERS. The generic line-add logic defaults Price Freeze to FALSE, because normally a new line is expected to get its price from standard pricing sources (price lists, agreements) unless told otherwise.

I do think this information will help you to underneath functionality.

regards,

Piyal