[Erp5-dev] Proposal of improvement for reference handling in Organisation

[bartek]

Jean-Paul Smets wrote:
> Hi,
> 
> The form Organisation_viewDetails (wrong naming BTW, should be
> Organisation_viewDetail), displays different values related to the
> company. Some values such as the registration code or the birth date are
> definitely singleton values. Others may not be: VAT registration code
> (there can be more than one), social code, etc.
> 
> The idea in the original design was that a single company may have
> different offices. Each office should be represented in ERP5 as an
> Organisation instance. This is fine and is enough to handle for example
> multiple social registration codes (ie. 1 per office). Based on this
> idea, we thought that VAT registration code is only one per company.
> 
> However, we found this not always to be the case. Some companies which
> are doing export need in certain cases to register to foreign tax
> authorities and obtain a VAT code in each country they operate in
> (without subsidiary in that country). This is for example the case with
> e-commerce between US and EU.
> 
> To handle this, I am thinking of 2 ways to improve the current design:
> 
>     1- Create a generic code contact information portal type which works
> in the same way as phone, address, email, etc. This means that the
> couple ("code type", "code value") is stored in subobjects of
> Organisation.  In the case of VAT, it would be ('vat_code',
> 'FR3847483836'). Compatibility with current implementation would be
> provided through adequate propertysheet definition. By adding some
> predicate behaviour to the generic code subbject, "automatic selection"
> feature would become also possible in order to guess for example which
> code to use for VAT in which case (ex. if we ship to country C and the
> client has a local VAT code then use our local VAT else use the one we
> obtained in that country if any....). This approach is quite
> straightforward. It is only a bit boring to configure because we have to
> add codes one by one for each case.
> 
>     2- Create a generic reference matrix which can be configured in a
> similar way as we do with codes in products with variations (ex. EAN13
> for each color, size of cloth). For example, the VAT reference matrix
> could define  a value for a combination of region X activities (ie. the
> VAT code depends on where we sell and to which kind of client).
> Compatibility with current implementation is a bit harder to get because
> the reference is stored here in a subobject of a subobject rather than
> in a subobject as in case 1.
> 
> Unless someone tells me this is wrong, I think we will go towards 1- and
> reuse the same code, classes and types as the ones which are used in
> Products to define product codes, but without the matrix. The main
> reason for me is that I see no "natural variation dimensions" in
> Organisation. However, if someone finds that there are natural variation
> dimensons in Organisation which are not covered by creating multiple
> Organisations (which is the right way in most cases in ERP5), then I
> could think about 2-.

This new feature for sure will improve address handling too, in case 
when an Organisation has multiple addresses for various purposes - for 
example we have only one office, but the company is registered 
elsewhere, so we have an "official" address which should be printed on 
invoices, and "real" addres which should be printed on letterheads. Same 
can happen for phone numbers and anything else. I think predicates would 
be a good solution for this - I don't know if "purpose" is a "natural 
variation dimension" or not.

Bartek

> 
> Regards,
> 
> JPS.
> 
> PS. If a company has 2 offices, create 2 organisations, not 2 addresses
> in the same organisation.
> 
> 
> 


-- 
"feelings affect productivity. (...) unhappy people write worse 
software, and less of it."
Karl Fogel, "Producing Open Source Software"