Most Powerful Open Source ERP

How To Work with Person and Organisation

includes a list of country specific rules to follow
  • Last Update:2016-04-08
  • Version:001
  • Language:en

Here, we discuss several codes for Person and Organisation.

Table of Contents

Properties

The following numbers/codes are essential from legal and fiscal point of view:

Please keep in mind that there is no such thing as a "unique ID" for a Person or Organisation. The only universal concept is "a unique ID in the context of a given administration/registry/directorate in a given country"

Also, in general, a person / organisation who has multiple citizenship or is expatriated or does business in different countries can have a different ID in every country for each administration.

Social ID

  • description: a unique number given to every person or organisation by the social welfare administration (ie. this is not the ID card number, or passport number, or registration code, etc.). It is used to subscribe to welfare or benefit from welfare system.
  • refers to: Person
  • multiplicity: 1 *
  • name in ERP5: social_code
  • name in Poland: PESEL
  • name in France: No URSSAF
  • name in UK: National Insurance Number
  • name in US: Social Security Number (SSN)
  • name in Japan: 基礎年金番号

registration code

  • description: provided by the business registry for the company
  • refers to: Organisation
  • multiplicity: 1 *
  • name in ERP5: corporate_registration_code
  • name in Poland: KRS
  • name in France: SIRET
  • name in Japan: 会社法人等番号

geographic_registration

  • description: the registration code of an office vs. a company. (ie. this is another number provided by the registries of commerce).
  • refers to: Organisation
  • multiplicity: 1 *
  • name in ERP5: corporate_registration_code
  • name in Poland: (none)
  • name in France: SIREN
  • name in Japan: (none)

activity code

  • description: provided by statistics institute to produce national statistics
  • refers to: Organisation
  • multiplicity: 1 *
  • name in ERP5: activity_code
  • name in Poland: REGON
  • name in France: NAF
  • name in US: Employer Identification Number (EIN)
  • name in Japan: 法人番号

fiscal code

  • description: a unique number given to every tax payer; given to every adult citizen and to every legal entity; used for filing income tax forms, printed on invoices within the country;
  • refers to: Person and Organisation
  • multiplicity: 1 *
  • name in ERP5: (missing)
  • name in Poland: NIP
  • name in France: numéro fiscal
  • name in US: Individual Taxpayer Identification Number (ITIN)
  • name in Japan: 納税者番号 or 納税通知書番号

vat code

  • description: a unique number given to every business entity trading with other countries; printed on invoices issued for foreign clients; some countries (no only Europe) requires companies to register for VAT in their country as soon as they do business.
  • refers to: Person
  • multiplicity: 1 *
  • name in ERP5: vat_code
  • name in Poland: "Europejski numer VAT" or "NIP europejski"/li>
  • name in France: numéro de TVA intracommunautaire
  • name in UK: Value added tax registration number (VAT Reg No)
  • name in Japan: (none)

What is missing

fiscal code for both Person and Organisation

  • yes.

multiple vat_codes

  • yes. In reality, we need to have multiple codes for everything.
  • city tax, state tax This is probably required to do business in the US and implement sales tax (someone must check if the ID used in the US can be different for each sales tax)

Discussion

1. Some countries have something like "social security number", I don't know if it is an equivalent of "personal ID" or "fiscal code". I hope someone from another country joins the discussion...

=> This is social_code in ERP5.

2. I think social code and fiscal code should be catalogged - this is because (a) these codes are very important and are often used to find and identify a person or an organisation, and (b) because they are assured to be unique country-wide, so a serious application should be able to check if there are no duplicates.

=> This is questionnable. For now, we do not want to extend the default catalog by adding columns, mostly for performance reasons. (we are actually considering to reduce it)

Also, extending the main catalog is not the "definitive" solution. What we must do first:

  • 1. implement codes in such way that any person/organisation can have many codes in many context (ie. this means using predicates)
  • 2. make sure this is consistent with codes in Resource (ie. ean13 codes, references, etc.) which in this case even require variation matrices
  • 3. make sure that the codes we use can be retrieved quickly and used by the tax system in Sale Order / Purchase Order, using Predicates for example
  • 4. possibly create a table for codes (à la "subject") so that any number of codes can be catalogues without having to extend the catalog.

Performance impact must be assessed very seriously.

In my opinion, all this takes between 5 to 10 man days to be completed perfectly (1 day for a prototype).

3. If we follow the principle that a business activity of a Person is represented by a respective Organisation, what relation should link the two? I presume there should be a relation, and some properties (like fiscal code or default address) will be acquired along the relation.

=> A Person is for example the "official representative/manager" of his / her "private business".

This relation is similar to the relation between a CEO and a company, or between a stock holder and a company.

4. Maybe we could develop something like "country-based property", where one could input one value per every country defined in the region tree - that would cover all corner cases of expats with mutliple ids and fiscal codes, companies with multiple vat codes etc?

=> This is required.

Related Articles