When migrating from OpenERP we converted the party ‘ref’ field to a simple anonymous tryton party identifier (that is we only set .code = partner.ref, .type was not set) which seemed to work fine for party selection. BTW ‘ref’ is actually quite heavily used, much like the code is for products.
Prior to the push of http://bugs.tryton.org/issue7906, we already notice for example on parties where the vat id comes after the migrated ‘ref’ in the identifier list, that vat id is not picked up in invoices.
Changing the order manually seems to fix that.
Will 7906 fix this? Hopefully it will not cause any other side-effects, any known caveats?
Also, briefly mentioned elsewhere, there are identifiers that are on the tuple party/address and not only the party, still no indication on how to manage those? (Addresses with several parties (occupants))
Then you should probably migrate it as party code. Tryton won’t set an autogenerated code if you set one when creating the records
For me the expected behaviour is that the tax identifier is used when the type is applicable despite having identifier of other types. Could you please fill a bug with some simple steps to reproduce on an empty database?
Yes, I know… code is set as such … from the OpenERP code.
I’m talking about the ‘ref’ field which was a legacy field set from the previous SAGE migration,
still used for things such as importation from payroll (which is SAGE).