Merge lp:~numerigraphe-team/openobject-addons/trunk-l10n-fr-siret into lp:openobject-addons

[Numérigraphe]

Please let me propose another enhancement to the French localization.
Most users in France like to keep track of the French official id number (SIRET) and registry of commerce (RCS) of their customers and suppliers.
This branch contains a new module "l10n_fr_siret" to let users enter the SIREN and NIC on the partner form. It will check the control key in those numbers, and record the corresponding SIRET (concatenation of the 2).
This module is a rewrite of a custom module of ours, and now takes into account remarks and other similar modules reported on the OpenERP French Forum and in the Sistheo project.
A previous version was submitted in 2011, and another version in in 2012 that I think addressed the objections that were raised.
I never got any feedback so please allow me to resubmit now.

[Numérigraphe (numerigraphe)]

Aurélien D. emailed me in private to warn that the length of the SIREN and NIC numbers was not checked. Now They are.

[risto3 (risto3)]

Evaluating using l10n_fr_siret to get CFONB-conforming SEPA support into account_pain which, for France, seems to require the use of the SIRET.

Although I agree that the SIREN should be on the partner object, I believe that the NIC/SIRET should perhaps find itself more appropriately on the res_partner_location objects (probably with a constraint to avoid duplicates).

This is to avoid unnecessary partner objects for multiple establishments...

Has anybody already attempted this?

[risto3 (risto3)]

btw, it seems tryton puts the SIREN on the party object and the SIRET on the address object which seems to confirm my comments above.

[Numérigraphe (numerigraphe)]

Thanks for your feedback risto3.
The current proposal implied that each partner is an office with its own SIRET ("Etablissement" in the SIRENE jargon), and I expect the main office / branch office relationship to be described by the partner/parent partner relationship, not the partner/address relationship.
However, that was suited for v6.x but in v7.0 the partner's hierarchical model has changed, so this proposal may be unfit.
I'd be glad if you can make a proposal based upon ours.
Thanks anyway.
Lionel

[Numérigraphe (numerigraphe)]

I've added the RCS as suggested by risto3 in https://answers.launchpad.net/openobject-server/+question/205409.
I've also improved the view to fit well in the future v7.

With regards to the partner/address changes in v7, I do think res.partner is the right place to hold the SIRET+RCS - actually it's clearer now than it was in v6-.

[Alexis de Lattre (alexis-via)]

I do not have the use of SIRET on res.partner ; only SIREN is usefull.

In the third comment, risto3 says :
<<
Evaluating using l10n_fr_siret to get CFONB-conforming SEPA support into account_pain which, for France, seems to require the use of the SIRET.
>>

Could you be more specific and give more details about this ? If you do SEPA Credit Transfer, with PAIN 001.001.02/03/04, you don't need SIRET nor SIREN.

If you look at my module "account_banking_sepa_credit_transfer" (part of the "banking-addons" framework) in the branch
https://code.launchpad.net/~akretion-team/banking-addons/trunk-banking-addons-sepa, you will see that the code doesn't require SIREN nor SIRET.

What is the "account_pain" module you are referring to ? Is it the one from Noviat located in their own branch (I just discovered it). I understand that this module is an alternative to mine, and that it's not part of the banking-addons framework. Is it right ?

[Numérigraphe (numerigraphe)]

Le 27/08/2012 22:43, Alexis de Lattre a écrit :
> I do not have the use of SIRET on res.partner ; only SIREN is usefull.
That's fine, the SIRET is only computed if both the SIREN and NIC are
recorded, so you may use the SIREN on its own.
Lionel.

[risto3 (risto3)]

I believe the use of SIRET is a remnant of CFONB ETEBAC, and that (in our case) the tests with FIDUCIAL and the Banque Populaire expect the SIRET in CFONB SEPA messages in their Cyberplus platform which accepts both formats (xml or cfonb).

Strictly speaking I notice that since 1 jan 2011 it is not stricto-senso required:

From the CFONB's Guide ISO20022 Virements V2.0-1.pdf
==============================
A noter : à partir du 1er janvier 2011 les virements intra zone SEPA ne feront plus l‟objet de déclaration à la balance des paiements.
 Remarque : Les modalités concernant la balance de paiements sont susceptibles d‟évoluer, de ce fait, il est fortement recommandé de se renseigner auprès de sa banque ou sur le site de la Banque de France.
==============================

In our case, the following is used in <InitgPty> </InitgPty> :
<Nm>Mr XXXXXX</Nm>  Nom du donneur d‟ordre initial
<Id>
<OrgId>
<Othr>
<Id>12345678901234</Id>  N° SIRET du donneur d‟ordre initial
<SchmeNm>
<Prtry>SIRET</Prtry>  renseigner ici le fait qu‟il s‟agit d‟un N° SIRET
</SchmeNm>
</Othr>
</OrgId>
</Id>

For the meanwhile we will continue with SIRET, but in the future, in theory anyway, I understand that either the SIRET, SIREN or VAT ID should be given for companies, and title, birth date and location for individuals in addition to the name(s).

(btw, according to the "Inventory of External Code Lists - Required by (but external to) the ISO 20022 XML Message Schemas" Publication date 16 July, 2012 - 2Q2012 Source ISO20022.org pain.001.001.04 subtly defines respectfully SRET/SREN/TXID)

The banque apparently will control the IBAN with the party details such as the following:
01000 = IBAN valide et existant + FAUX (000) = IBAN invalide ou inexistant

01001 = IBAN valide et existant + VRAI (001) = IBAN valide et existant

02000 = type de compte correct + FAUX (000) = type de compte incorrect

02001 = type de compte correct + VRAI (001) = type de compte correct

03000 = SIREN fourni et OK + FAUX (000) = SIREN incorrect

03001 = SIREN fourni et OK + VRAI (001) = SIREN correct

03002 = SIREN fourni KO mais repli sur SIRET OK + FAUX = SIRET sur SIREN incorrect

03003 = SIREN fourni KO mais repli sur SIRET OK + VRAI = SIRET sur SIREN correct

03020 = SIREN non fourni

04000 = SIRET fourni et OK + FAUX (000) = SIRET incorrect

04001 = SIRET fourni et OK + VRAI (001) = SIRET correct

04020 = SIRET non fourni

05000 = N° TVA Intracommunautaire fournie et FAUX (000) = N° TVA intracommunautaire incorrecte

05001 = N° TVA Intracommunautaire fournie et VRAI (001) = N° TVA intracommunautaire correcte

05020 = N° TVA Intracommunautaire non fournie

06000 = date de naissance fournie et FAUX (000) = Date de naissance incorrecte

06001 = date de naissance fournie et VRAI (001) = Date de naissance correcte

06003 = date de naissance fournie KO mais année OK + FAUX = année de naissance correcte

06004 = date de naissance fournie KO mais année OK + VRAI = année de naissance incorrecte

06020 = date de naissance non fournie

07000 = ville de naissance fournie correcte + FAUX (000) = ville de naissance incorrecte

07001 = ville de naissance fournie correcte + VRAI (001) = ville de naissanc...

[Alexis de Lattre (alexis-via)]

@risto3 :
Thanks for your interesting explainations. In my module "account_banking_sepa_credit_transfer" which is part of the "banking-addons" framework, I generate the InitgPty as :

<InitgPty>
     <Nm>Company name</Nm>
</InitgPty>

and it is accepted fine by the CIC. I was not aware that we could/should use sub-blocks to give more information about the company.

By the way, are you connected to the author of the module 'account_pain' ?

[risto3 (risto3)]

No, our first pass is based upon account_pain but migration is underway to banking-addons where akretion seems to have been doing some work, already at pain.001.001.04, but have not heard back on my request to collaborate (that is, putting support in for .03)...

Back to the subject of the merge, and the discussion of res.partner where the proposal is to have VAT, SIREN and NIC, I'm concerned about the constraints needed.

VAT is company wide, as is SIREN, but SIRET (SIREN + NIC) is unique (to the establishments address), but what about temporary agencies and depots? No SIRET (SIREN + NIC) is sure, but VAT? It seems that VAT should only be valid if SIREN and NIC are non null.

How to consider e.g. a depot as other than an address, it has no 'personality'.

Sorry, I am at a loss as to the benefits of deprecating res.partner.address, with the existing structure, res.partner if a company, has a unique SIREN and VAT, and unique NICs to make certain addresses legal establishments (SIRET), other addresses are just that, work sites, depots, temporary agencies and the like.

[risto3 (risto3)]

Another question
I presume when SIREN != null then the partner is considered a company (and not an individual)
but has there been any consideration on how to indicate which SIRET(NIC) is the company headquarters (siège social)?

[Numérigraphe (numerigraphe)]

> I presume when SIREN != null then the partner is considered a company (and not
> an individual)
I didn't think about that, but now we have a boolean to indicate if the partner is a company: would you like the SIRET fields hidden when it's not a company?

> but has there been any consideration on how to indicate which SIRET(NIC) is
> the company headquarters (siège social)?
I suppose you could find the HQ by going upward the partner tree. I don't yet see a practical value for that however.

>It seems that VAT should only be valid if SIREN and NIC are non null.
VAT is still independent from SIRET, so you can use the same VAT for several establishments.
We can't link SIRET and VAT because non-French partners don't have a SIRET.

> How to consider e.g. a depot as other than an address, it has no 'personality'.
Just don't enter a VAT or SIRET - or am I missing something?

[risto3 (risto3)]

Well, perhaps both SIREN and SIRET (NIC) are N/A when not a company.
I'm not sure what you mean by going up the partner tree.. parent_id is not appropriate
(and parent_left is immediate parent up, parent_right is first child)
as they are all the same company, forcibly it's simply a list, ideally an ordered list.
Where is the sibling res.partner list?

Hmm, another complexity with the 'new' structure would be to determine upon which partner (or all of them!) the mother company (companies) need to be indicated, the same for subsidiaries and the like...

By the way, the unique establishment identifier (SIRET) does exist elsewhere in Europe
(I believe all Europe is supposed to follow at some point or another the EU guidelines):
in Holland => vestigingsnummer (old system before july 2011 was n°KvK + subdossiernummer)
in Belgium => idem (or unité d'établissement )

[Alexis de Lattre (alexis-via)]

@risto3

I am glad to hear that you would like to collaborate on my work for SEPA Credit Transfer on banking-addons. You talk about your "request to collaborate"... where did you send it ? I probably missed it.

You can contact me on : alexis dot delattre _at_ akretion dot com

[Fabien (Open ERP) (fp-tinyerp)]

can someone from France approve of disapprove this merge proposal. I am thinking about merging it but I want to be sure that it fits France's requirement.

I have a question:
  - de we need the company_registry? Isn't it the partner name? Because I am afraid that a lot of users will not fill in this field. Is it a problem if we don't fill it (it fault back to the real name ?)

[Numérigraphe (numerigraphe)]

Dear Fabien,
"Company registry" is the name of the local registry kept by the tribunal of commerce.
For example Numérigraphe SARL is registered in the "RCS Le Mans".
I hope this makes it clearer.
Lionel.

[Numérigraphe (numerigraphe)]

I forgot to write: it's ok to not fill company_registry, it's only informational.

[Arnaud Pineux (OpenERP) (api-openerp)]

Dear all,

Before merging anything we need clarification and/or correction. The module l10n_fr_siret is a dependancy of l10n_fr, so it means that l10n_fr_siret is mandatory to use l10n_fr. If we always need l10n_fr_siret to use l10n_fr, why imrpovement of siret don't belong to l10n_fr as it was before?
If l10n_fr_siret is a new addons which is not mandatory for the french accounting, why is it a dependency of l10n_fr when it should be the opposite (l10n_fr is a dependency of l10n_fr_siret)?

Thank you

[Numérigraphe (numerigraphe)]

Dear Arnaud Pineux,
I made this as a module to be consistent with what was advised for l10n_fr_rib (French bank details) - just for the sake of not making l10n_fr too big.
Would you rather this and l10n_fr_rib be made installable options ? Any pointer so I can make the proper changes quickly ?
Lionel.

[Arnaud Pineux (OpenERP) (api-openerp)]

If it is an option (not manadatory in every french accounting) then it will be nice to have that as an option. Therefore it must depend on l10n_fr and not in the opposite way.

Thanks, we will merge your changes asap.

API

[Alexandre Fayolle - camptocamp (alexandre-fayolle-c2c)]

The MP should be updated to have a target on lp:openobject-addons/7.0 (which does not prevent from also merging in trunk).

[Alexandre Fayolle - camptocamp (alexandre-fayolle-c2c)]

Is someone working on the MP? Lionel, can I help you with this?

[Numérigraphe (numerigraphe)]

Dear Alexandre Fayolle and followers,
I'm grateful for your help.
I' merge Alexandre's branch as a first step, but as I commented there[1] I'd still like to make this a "check the box to install" option, but I need guidance.
[1] https://code.launchpad.net/~camptocamp/openobject-addons/7.0-l10n-fr-siret/+merge/144524/comments/313437
Lionel.

[Numérigraphe (numerigraphe)]

Hi all,
I've removed all the dependencies between l10n_fr and l10n_fr_* altogether. l10n_fr_siret and l10n_fr_rib work fine without l10n_fr.

This is not perfect - but I've been delaying this too long, and I came to think it would be better to merge this now, and make other proposals to improve later.

Lionel

[Lionel Sausin - Initiatives/Numérigraphe (ls-initiatives)]

Had to change the URL of this proposal : it now sits at https://code.launchpad.net/~numerigraphe-team/openobject-addons/trunk-l10n-fr-siret/+merge/210096 .
Sorry about that.

[Lionel Sausin - Initiatives/Numérigraphe (ls-initiatives)]

The branch runs red in runbot, sorry. I'll fix it and resubmit

[Alexis de Lattre (alexis-via)]

Lionel,

I think we should maintain this module l10n_fr_siret outside of lp:openobject-addons, so that we don't bother OpenERP S.A. everytime we have to make a change in this France-specific code. OpenERP S.A. already has so many pending merge proposals on important modules such as account/stock/sale/purchase/procurement/mrp that I fear that this merge proposal won't be considered anytime soon.

Your module l10n_fr_siret has already been accepted in the OCA project lp:account-financial-tools, so it now has a good visibility and it would be a bad idea to duplicate it between openobject-addons and account-financial-tools. We are resurecting lp:openerp-french-localization, so that we can have all France-specific modules in one place ; maybe one day we could move l10n_fr_siret to that project. lp:openerp-french-localization already has one module l10n_fr_fec (for the Fichiers Echanges Comptables), and others are coming soon.

[Lionel Sausin - Initiatives/Numérigraphe (ls-initiatives)]

Thanks for your review Alexis, you make a good point.
TLDR: I'm removing this proposal for now, and will propose again some time later if I get feedback from French users wanting this in the core.

Indeed my plan was initially to push this to the trunk and remove it from OCA's branches, because:
1/ same fields were already added to res.company
2/ eventually I wanted to let users check a box to install the module, which to my knowledge can only be done through an already-installed module (l10n_fr in this case)
But thinking again, I found a solution to handle 1/ in the community module, and 2/ is not so important.
So there is no pressing need to push this to the core, and I'm OK to migrate to lp:openerp-french-localization instead, as soon as the following improvements are accepted:
    https://code.launchpad.net/~numerigraphe-team/account-financial-tools/7.0-l10n_fr_siret-view+company/+merge/212920

review: Disapprove

[Olivier Dony (Odoo) (odo-openerp)]

(Just rejected the MP as requested by Lionel)

=== modified file 'account/account_invoice.py'
=== modified file 'l10n_fr/__openerp__.py'
--- l10n_fr/__openerp__.py	2013-10-27 12:31:04 +0000
+++ l10n_fr/__openerp__.py	2014-03-09 20:16:20 +0000
@@ -51,13 +51,15 @@
 in l10n_fr; companies that sell services to DOM-based companies should update the
 configuration of their taxes and fiscal positions manually.
 
+Users wanting to store the NAF/APE codes should look into the module l10n_fr_naf_ape
+from https://launchpad.net/openerp-nomenclatures
+
 **Credits:** Sistheo, Zeekom, CrysaLEAD, Akretion and Camptocamp.
 """,
-    'depends': ['base_iban', 'account', 'account_chart', 'base_vat', 'l10n_fr_rib'],
+    'depends': ['base_iban', 'account', 'account_chart', 'base_vat'],
     'data': [
         'fr_report.xml',
         'plan_comptable_general.xml',
-        'l10n_fr_view.xml',
         'l10n_fr_wizard.xml',
         'fr_pcg_taxes.xml',
         'fr_tax.xml',

=== modified file 'l10n_fr/l10n_fr.py'
--- l10n_fr/l10n_fr.py	2013-10-27 12:31:04 +0000
+++ l10n_fr/l10n_fr.py	2014-03-09 20:16:20 +0000
@@ -48,6 +48,7 @@
     ]
 
 
+<<<<<<< TREE
 class res_company(osv.osv):
     _inherit = 'res.company'
 
@@ -57,4 +58,6 @@
     }
 
 
+=======
+>>>>>>> MERGE-SOURCE
 # vim:expandtab:smartindent:tabstop=4:softtabstop=4:shiftwidth=4:

=== removed file 'l10n_fr/l10n_fr_view.xml'
--- l10n_fr/l10n_fr_view.xml	2013-10-27 12:31:04 +0000
+++ l10n_fr/l10n_fr_view.xml	1970-01-01 00:00:00 +0000
@@ -1,21 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<openerp>
-    <data>
-
-        <record id="res_company_form_l10n_fr" model="ir.ui.view">
-            <field name="name">res.company.form.l10n.fr</field>
-            <field name="model">res.company</field>
-            <field name="priority">20</field>
-            <field name="inherit_id" ref="base.view_company_form"/>
-            <field name="arch" type="xml">
-            <data>
-                 <xpath expr="//field[@name='company_registry']" position="after">
-                    <field name="siret"/>
-                    <field name="ape"/>
-                 </xpath>
-            </data>
-            </field>
-        </record>
-       
-    </data>
-</openerp>

=== modified file 'l10n_fr_rib/__openerp__.py'
--- l10n_fr_rib/__openerp__.py	2012-11-29 22:26:45 +0000
+++ l10n_fr_rib/__openerp__.py	2014-03-09 20:16:20 +0000
@@ -27,6 +27,7 @@
 This module lets users enter the banking details of Partners in the RIB format (French standard for bank accounts details).
 ===========================================================================================================================
 
+This can help any company doing business with French Banks.
 RIB Bank Accounts can be entered in the "Accounting" tab of the Partner form by specifying the account type "RIB". 
 
 The four standard RIB fields will then become mandatory:

=== added directory 'l10n_fr_siret'
=== added file 'l10n_fr_siret/__init__.py'
--- l10n_fr_siret/__init__.py	1970-01-01 00:00:00 +0000
+++ l10n_fr_siret/__init__.py	2014-03-09 20:16:20 +0000
@@ -0,0 +1,25 @@
+# -*- encoding: utf-8 -*-
+##############################################################################
+#
+#    OpenERP, Open Source Management Solution
+#    Copyright (C) 2011 Numérigraphe SARL.
+#
+#    This program is free software: you can redistribute it and/or modify
+#    it under the terms of the GNU Affero General Public License as
+#    published by the Free Software Foundation, either version 3 of the
+#    License, or (at your option) any later version.
+#
+#    This program is distributed in the hope that it will be useful,
+#    but WITHOUT ANY WARRANTY; without even the implied warranty of
+#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#    GNU Affero General Public License for more details.
+#
+#    You should have received a copy of the GNU Affero General Public License
+#    along with this program.  If not, see <http://www.gnu.org/licenses/>.
+#
+##############################################################################
+
+import partner
+
+# vim:expandtab:smartindent:tabstop=4:softtabstop=4:shiftwidth=4:
+

=== added file 'l10n_fr_siret/__openerp__.py'
--- l10n_fr_siret/__openerp__.py	1970-01-01 00:00:00 +0000
+++ l10n_fr_siret/__openerp__.py	2014-03-09 20:16:20 +0000
@@ -0,0 +1,50 @@
+# -*- encoding: utf-8 -*-
+##############################################################################
+#
+#    OpenERP, Open Source Management Solution
+#    Copyright (C) 2011 Numérigraphe SARL.
+#
+#    This program is free software: you can redistribute it and/or modify
+#    it under the terms of the GNU Affero General Public License as
+#    published by the Free Software Foundation, either version 3 of the
+#    License, or (at your option) any later version.
+#
+#    This program is distributed in the hope that it will be useful,
+#    but WITHOUT ANY WARRANTY; without even the implied warranty of
+#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#    GNU Affero General Public License for more details.
+#
+#    You should have received a copy of the GNU Affero General Public License
+#    along with this program.  If not, see <http://www.gnu.org/licenses/>.
+#
+##############################################################################
+
+{
+    'name': 'French company identity numbers SIRET/SIREN/NIC',
+    'version': '1.0',
+    "category": 'Hidden',
+    'description': '''
+This module add the French company identity numbers.
+====================================================
+
+This can help any company doing business with French companies
+by letting users track the partners' unique identification
+numbers from the official SIRENE registry in France: SIRET, SIREN and NIC.
+These numbers identify each company and their subsidiaries, and are
+often required for administrative tasks.
+
+At the top of the Partner form, users will be able to enter the SIREN
+and NIC numbers, and the SIRET number will be calculated automatically.
+The last digits of the SIREN and NIC are control keys: OpenERP will check their
+validity when partners are recorded.
+''',
+    'author' : u'Numérigraphe SARL',
+    'depends': ['base'],
+    'data': [
+        'partner_view.xml',
+    ],
+    'installable': True,
+    'active': False,
+}
+
+# vim:expandtab:smartindent:tabstop=4:softtabstop=4:shiftwidth=4:

=== added directory 'l10n_fr_siret/i18n'
=== added file 'l10n_fr_siret/i18n/fr.po'
--- l10n_fr_siret/i18n/fr.po	1970-01-01 00:00:00 +0000
+++ l10n_fr_siret/i18n/fr.po	2014-03-09 20:16:20 +0000
@@ -0,0 +1,57 @@
+# Translation of OpenERP Server.
+# This file contains the translation of the following modules:
+#	* l10n_fr_siret
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: OpenERP Server 6.1beta\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2011-12-08 14:04+0000\n"
+"PO-Revision-Date: 2011-12-08 14:04+0000\n"
+"Last-Translator: <>\n"
+"Language-Team: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: \n"
+"Plural-Forms: \n"
+
+#. module: l10n_fr_siret
+#: field:res.partner,siren:0
+msgid "SIREN"
+msgstr "SIREN"
+
+#. module: l10n_fr_siret
+#: field:res.partner,nic:0
+msgid "NIC"
+msgstr "NIC"
+
+#. module: l10n_fr_siret
+#: constraint:res.partner:0
+msgid "The SIREN or NIC number is incorrect."
+msgstr "Le numéro SIREN ou NIC est incorrect."
+
+#. module: l10n_fr_siret
+#: help:res.partner,siret:0
+msgid "The SIRET number is the official identity number of this company's office in France. It is composed of the 9 digits of the SIREN number and the 5 digits of the NIC number, ie. 14 digits."
+msgstr "Le numéro SIRET est l'identifiant officiel de l'établissement en France. Il est composé des 9 chiffres du numéro SIREN et des 5 chiffres du numéro NIC, soit 14 chiffres."
+
+#. module: l10n_fr_siret
+#: help:res.partner,siren:0
+msgid "The SIREN number is the official identity number of the company in France. It makes the first 9 digits of the SIRET number."
+msgstr "Le numéro SIREN est l'identifiant officiel de la société en France. Il compose les 9 premiers chiffres du numéro SIRET."
+
+#. module: l10n_fr_siret
+#: help:res.partner,nic:0
+msgid "The NIC number is the official rank number of this office in the company in France. It makes the last 5 digits of the SIRET number."
+msgstr "Le numéro NIC est le numéro de rang officiel de cet établissement dans sa société en France. Il compose les 5 derniers chiffres du numéro SIRET."
+
+#. module: l10n_fr_siret
+#: field:res.partner,siret:0
+msgid "SIRET"
+msgstr "SIRET"
+
+#. module: l10n_fr_siret
+#: model:ir.model,name:l10n_fr_siret.model_res_partner
+msgid "Partner"
+msgstr "Partenaire"
+

=== added file 'l10n_fr_siret/i18n/l10n_fr_siret.po'
--- l10n_fr_siret/i18n/l10n_fr_siret.po	1970-01-01 00:00:00 +0000
+++ l10n_fr_siret/i18n/l10n_fr_siret.po	2014-03-09 20:16:20 +0000
@@ -0,0 +1,57 @@
+# Translation of OpenERP Server.
+# This file contains the translation of the following modules:
+#	* l10n_fr_siret
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: OpenERP Server 6.1beta\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2011-12-08 14:03+0000\n"
+"PO-Revision-Date: 2011-12-08 14:03+0000\n"
+"Last-Translator: <>\n"
+"Language-Team: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: \n"
+"Plural-Forms: \n"
+
+#. module: l10n_fr_siret
+#: field:res.partner,siren:0
+msgid "SIREN"
+msgstr ""
+
+#. module: l10n_fr_siret
+#: field:res.partner,nic:0
+msgid "NIC"
+msgstr ""
+
+#. module: l10n_fr_siret
+#: constraint:res.partner:0
+msgid "The SIREN or NIC number is incorrect."
+msgstr ""
+
+#. module: l10n_fr_siret
+#: help:res.partner,siret:0
+msgid "The SIRET number is the official identity number of this company's office in France. It is composed of the 9 digits of the SIREN number and the 5 digits of the NIC number, ie. 14 digits."
+msgstr ""
+
+#. module: l10n_fr_siret
+#: help:res.partner,siren:0
+msgid "The SIREN number is the official identity number of the company in France. It makes the first 9 digits of the SIRET number."
+msgstr ""
+
+#. module: l10n_fr_siret
+#: help:res.partner,nic:0
+msgid "The NIC number is the official rank number of this office in the company in France. It makes the last 5 digits of the SIRET number."
+msgstr ""
+
+#. module: l10n_fr_siret
+#: field:res.partner,siret:0
+msgid "SIRET"
+msgstr ""
+
+#. module: l10n_fr_siret
+#: model:ir.model,name:l10n_fr_siret.model_res_partner
+msgid "Partner"
+msgstr ""
+

=== added file 'l10n_fr_siret/partner.py'
--- l10n_fr_siret/partner.py	1970-01-01 00:00:00 +0000
+++ l10n_fr_siret/partner.py	2014-03-09 20:16:20 +0000
@@ -0,0 +1,98 @@
+# -*- encoding: utf-8 -*-
+##############################################################################
+#
+#    OpenERP, Open Source Management Solution
+#    Copyright (C) 2011 Numérigraphe SARL.
+#
+#    This program is free software: you can redistribute it and/or modify
+#    it under the terms of the GNU Affero General Public License as
+#    published by the Free Software Foundation, either version 3 of the
+#    License, or (at your option) any later version.
+#
+#    This program is distributed in the hope that it will be useful,
+#    but WITHOUT ANY WARRANTY; without even the implied warranty of
+#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#    GNU Affero General Public License for more details.
+#
+#    You should have received a copy of the GNU Affero General Public License
+#    along with this program.  If not, see <http://www.gnu.org/licenses/>.
+#
+##############################################################################
+
+from openerp.osv import fields, orm
+
+    
+# XXX: this is used for checking various codes such as credit card numbers: should it be moved to tools.py?
+def _check_luhn(string):
+    """Luhn test to check control keys
+    
+    Credits: http://rosettacode.org/wiki/Luhn_test_of_credit_card_numbers#Python
+    """
+    r = [int(ch) for ch in string][::-1]
+    return (sum(r[0::2]) + sum(sum(divmod(d*2,10)) for d in r[1::2])) % 10 == 0
+
+class Partner(orm.Model):
+    """Add the French official company identity numbers SIREN, NIC and SIRET"""
+    _inherit = 'res.partner'
+    
+    def _get_siret(self, cr, uid, ids, field_name, arg, context=None):
+        """Concatenate the SIREN and NIC to form the SIRET"""
+        sirets = {}
+        for partner in self.browse(cr, uid, ids, context=context):
+            if partner.siren and partner.nic:
+                sirets[partner.id] = '%s%s' % (partner.siren, partner.nic)
+            else:
+                sirets[partner.id] = ''
+        return sirets
+    
+    def _check_siret(self, cr, uid, ids):
+        """Check the SIREN's and NIC's keys (last digits)"""
+        for partner in self.browse(cr, uid, ids, context=None):
+            if partner.nic:
+                # Check the NIC type and length
+                if not partner.nic.isdecimal() or len(partner.nic)!=5:
+                    return False
+            if partner.siren:
+                # Check the SIREN type, length and key
+                if (not partner.siren.isdecimal()
+                    or len(partner.siren)!=9
+                    or not _check_luhn(partner.siren) ):
+                    return False
+                # Check the NIC key (you need both SIREN and NIC to check it)
+                if partner.nic and not _check_luhn(partner.siren + partner.nic):
+                    return False
+        return True
+     
+    _columns = {
+        'siren': fields.char('SIREN', size=9,
+                             help="The SIREN number is the official identity "
+                                  "number of the company in France. It makes "
+                                  "the first 9 digits of the SIRET number."),
+        'nic': fields.char('NIC', size=5,
+                           help="The NIC number is the official rank number "
+                                "of this office in the company in France. It "
+                                "makes the last 5 digits of the SIRET "
+                                "number."),
+        'siret': fields.function(_get_siret, type="char", string='SIRET',
+            method=True, size=14,
+            store = {
+                'res.partner': [lambda self, cr, uid, ids, context=None: ids,
+                ['siren', 'nic'],
+                10]},
+            help="The SIRET number is the official identity number of this "
+                 "company's office in France. It is composed of the 9 digits "
+                 "of the SIREN number and the 5 digits of the NIC number, ie. "
+                 "14 digits."),
+        'company_registry': fields.char('Company Registry', size=64,
+                           help="The name of official registry where this "
+                                "company was declared."),
+    }
+    
+    _constraints = [
+                    (_check_siret,
+                     "The SIREN or NIC number is incorrect.",
+                     ["siren", "nic"]),
+    ]
+
+
+# vim:expandtab:smartindent:tabstop=4:softtabstop=4:shiftwidth=4:

=== added file 'l10n_fr_siret/partner_view.xml'
--- l10n_fr_siret/partner_view.xml	1970-01-01 00:00:00 +0000
+++ l10n_fr_siret/partner_view.xml	2014-03-09 20:16:20 +0000
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="utf-8"?>
+<openerp>
+	<data>
+		<!-- Add the SIREN, NIC and SIRET numbers -->
+		<record model="ir.ui.view" id="view_partner_add">
+			<field name="name">res.partner.form.siret</field>
+			<field name="model">res.partner</field>
+			<field name="inherit_id" ref="account.view_partner_property_form" />
+			<field name="arch" type="xml">
+				<page string="Accounting" position="inside">
+					<group>
+						<group>
+							<field name="siren" />
+							<field name="nic" />
+							<field name="siret" />
+						</group>
+						<group>
+							<field name="company_registry" />
+						</group>
+					</group>
+				</page>
+			</field>
+		</record>
+	</data>
+</openerp>

=== modified file 'product/product.py'
--- product/product.py	2014-01-27 10:19:57 +0000
+++ product/product.py	2014-03-09 20:16:20 +0000
@@ -358,14 +358,25 @@
     _columns = {
         'name': fields.char('Name', required=True, translate=True, select=True),
         'product_manager': fields.many2one('res.users','Product Manager'),
-        'description': fields.text('Description',translate=True,
-            help="A precise description of the Product, used only for internal information purposes."),
-        'description_purchase': fields.text('Purchase Description',translate=True,
-            help="A description of the Product that you want to communicate to your suppliers. "
-                 "This description will be copied to every Purchase Order, Reception and Supplier Invoice/Refund."),
-        'description_sale': fields.text('Sale Description',translate=True,
-            help="A description of the Product that you want to communicate to your customers. "
-                 "This description will be copied to every Sale Order, Delivery Order and Customer Invoice/Refund"),
+<<<<<<< TREE
+        'description': fields.text('Description',translate=True,
+            help="A precise description of the Product, used only for internal information purposes."),
+        'description_purchase': fields.text('Purchase Description',translate=True,
+            help="A description of the Product that you want to communicate to your suppliers. "
+                 "This description will be copied to every Purchase Order, Reception and Supplier Invoice/Refund."),
+        'description_sale': fields.text('Sale Description',translate=True,
+            help="A description of the Product that you want to communicate to your customers. "
+                 "This description will be copied to every Sale Order, Delivery Order and Customer Invoice/Refund"),
+=======
+        'description': fields.text('Description',translate=True,
+            help="A precise description of the Product, used only for internal information purposes."),
+        'description_purchase': fields.text('Purchase Description',translate=True,
+            help="A description of the Product that you want to communicate to your customers. "
+                 "This description will be copied to every Sale Order, Delivery Order and Customer Invoice/Refund"),
+        'description_sale': fields.text('Sale Description',translate=True,
+            help="A description of the Product that you want to communicate to your suppliers. "
+                 "This description will be copied to every Purchase Order, Reception and Supplier Invoice/Refund."),
+>>>>>>> MERGE-SOURCE
         'type': fields.selection([('consu', 'Consumable'),('service','Service')], 'Product Type', required=True, help="Consumable are product where you don't manage stock, a service is a non-material product provided by a company or an individual."),
         'produce_delay': fields.float('Manufacturing Lead Time', help="Average delay in days to produce this product. In the case of multi-level BOM, the manufacturing lead times of the components will be added."),
         'rental': fields.boolean('Can be Rent'),

=== modified file 'stock/stock.py'
--- stock/stock.py	2014-01-29 18:47:03 +0000
+++ stock/stock.py	2014-03-09 20:16:20 +0000
@@ -722,8 +722,9 @@
         if ('name' not in default) or (picking_obj.name == '/'):
             seq_obj_name = 'stock.picking.' + picking_obj.type
             default['name'] = self.pool.get('ir.sequence').get(cr, uid, seq_obj_name)
+            default['backorder_id'] = False
+        if 'origin' not in default:
             default['origin'] = ''
-            default['backorder_id'] = False
         if 'invoice_state' not in default and picking_obj.invoice_state == 'invoiced':
             default['invoice_state'] = '2binvoiced'
         res = super(stock_picking, self).copy(cr, uid, id, default, context)