Comment 10 for bug 1111298

There should be nothing specific to fear when defining custom multi-company rules, as long as you keep them consistent.

The error we saw here results from mixing records with inconsistent multi-company rules in the *same* browse_record context/cache. This must never happen in normal situations: first, because we re-browse records all the time when we switch methods or logical context, so there are little side-effects; secondly, because the record rules are normally consistent, so the cache should only ever contain a consistent set of records.
Here the inconsistency was rather large: users were not allowed to see companies they didn't belong to, but they were allowed to see currencies that belonged to other companies; it was quite easy to obtain a mess of mixed records that did not belong with each other.

Fixing the inconsistent default settings is really all there is to it (point 1 and 2 in comment #8) - and it only concerns currencies because it's the only case where we detected an obvious inconsistency.
Point 3. is an extra nice-to-have to smoothly cover existing databases that can live with the inconsistency but need to be able to validate invoices for a company that is not the main/first company.

Finally, keep in mind that the issue could be fixed quite easily in the database by correcting the inconsistent rules and/or the incorrect company assignation on currencies... That will always be possible if someone happens to configure an inconsistent multi-company environment.