Read-only fields are meant for informative purpose only, so they're not saved by the OpenERP client-side when persisting records, this is a known limitation [1].

It's a design decision, and it has not been decided to change it so far, so developers must not rely on them for persisting field values.

The usual cases where developers request this feature are the following:

1. For default values that are read-only and have side-effects when computed twice, typically sequence numbers
2. For on_change results that are displayed read-only to the user and not otherwise computed via function fields

Both cases may seem good on first sight but they're based on a logic that is a bit flawed:

1. If the code that computes the _default has side-effects, those effects will be produced eventually, e.g. when someone discards a new record without saving it. The usual solution is to only compute the function with the side-effects when the record is finally saved, or when the record goes through a certain workflow transition (similarly to account.invoice).
2. on_change calls are meant to assist the user during the data input, but should not be used as a replacement for computed fields on the business logic side. Look at sale.order or account.invoice for example, the line subtotal is updated only after saving, making sure everything is properly taken into account. An update of the value could be done via an on_change, but that would only provide a visual hint for the user, not become the reference value.

There are many workarounds for accomplishing this (e.g. using a second invisible field to transmit the actual value), but it is probably better to avoid those cases altogether. As a rule of thumb, try to only use the read-only flag for:

• functional fields (it is the default anyway)
• fields that are changed by the business logic/workflow but not the UI (typically, the state field)
• fields that are disabled/ignored

It's still fine to update them via on_change calls, but don't rely on this mechanism for storing the value.

Also note that the proposal for a new OpenERP API includes merging the _defaults, the on_change and the fields.function into a generic "derived value" concept with a common implementation [2], which should make this whole mess a lot more straightforward.

[1] see bug 378824 and probably some other related ones
[2] see this slide and this presentation about the new API