-
Notifications
You must be signed in to change notification settings - Fork 25.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
9.0 poscertif lpe #20581
9.0 poscertif lpe #20581
Conversation
Main resource document to be found at https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf This document states that only business operations with partners not being subject to VAT should be inalterable and secure. We adpat the module by differentiating between b2c and b2b journals and apply hashing on the former's moves Protection against account_cancel is not necessary anymore By default, this module considers a sales journal being a b2c, thus activating hashing on its move. Since we can't afford to lose information, when a b2c journal contains hashed moves, its b2c characteristic cannot be changed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found a nice way to tackle everything that was bothering me in account.sale.closure:
- remove the m2m on account.move.line
- don't use the account.move's write_date (or the account.move's date)
- instead, each time you insert a record in that table, save the last (max) l10n_fr_secure_sequence_number found in the system. That field actually gives you chronologically the set of account move you're looking for: you're sure it's unalterable and it allows you to select easily all the move included in the perpetual and periodic totals, without a m2m join (moves having a l10n_fr_secure_sequence_number lesser or equal to that value).
FYI: I checked l10n_fr_pos_cert and it looks OK to me |
@qdp-odoo |
@@ -6,7 +6,8 @@ | |||
from openerp.tools.translate import _ | |||
from openerp.exceptions import UserError | |||
|
|||
ERR_MSG = _("According to the french law, you cannot modify a %s in order for its posted data to be updated or deleted. Field: %s") | |||
|
|||
ERR_MSG = _("According to the French law, you cannot modify a %s in order for its posted data to be updated or deleted. Unauthorized field: %s.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The translation here doesn't work. The _()
marker will let the system detect a term to include in our translation terms, but it won't actually be able to translate it, because there is no context to do it when the Python file is loaded.
You would need to translate it also at runtime wherever ERR_MSG is used, e.g. _(ERR_MSG)
.
Additionally, the use of "%s" placeholders here will make translating the sentence awkward. And same thing for the terms that will fill the placeholders, that will be out of context for the translator.
As we only have a couple of variations, it would be both more robust and translator-friendly to just duplicate the whole sentence for every variation. And if the code using the messages is duplicated in many places, you can keep them as "constants", but remember you will need to translate them twice!
Same comments goes for all other occurrences of this pattern, for example BKN_NO_TOUCH
(which has even worse placeholders IMO ;-))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@odony interesting, I didn't know the pitfall of translating global variables... but I have to back up @kebeclibre for the %s placeholders: it's a common usage we do all over the code. :-s
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few unsorted comments after a quick scan..
values['frequency'] = frequency | ||
values['company_id'] = company.id | ||
values['sequence_number'] = new_sequence_number | ||
values['name'] = _('%s Closing - ') % (get_selection_value(self._fields['frequency'], value=frequency),) + values['date_closure_stop'][:10] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Translators will have a hard time guessing what "%s" refers to here ;-)
@@ -0,0 +1,2 @@ | |||
id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink | |||
access_l10n_fr_sale_closure_account_sale_closure_user,l10n_fr_sale_closure.account.sale.closure.user,l10n_fr_sale_closure.model_account_sale_closure,,1,0,0,0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You probably want to restrict this to group_user
or some appropriate accounting group.
How about multi-company rules?
from openerp.tools.translate import _ | ||
from openerp.exceptions import UserError | ||
|
||
WRITE_MSG = _('Sale Closings are not meant to be written or deleted under any circumstances.') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aml.id as line_id | ||
FROM account_move_line aml | ||
JOIN account_journal j ON aml.journal_id = j.id | ||
JOIN (SELECT acc.id FROM account_account acc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here you can do a plain INNER JOIN without the subselect
raise UserError(WRITE_MSG) | ||
|
||
@api.model | ||
def automated_closure(self, frequency='daily'): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please make this method private, as it is not meant to be called through RPC.
<p class="oe_view_nocontent_nocreate"> | ||
The closings are created by Odoo | ||
</p><p> | ||
Sales closings run automatically on a daily, monthly and annual basis. It computes both period and cumulative totals from all the sales entries posted in the system after the previous closing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
closing/closure?
<field name="code"> | ||
db_uuid = env['ir.config_parameter'].sudo().get_param('database.uuid') | ||
action = {"type": "ir.actions.act_url", | ||
"url": "http://accounts.odoo.com/my/contract/certification-french-accounting/db/" + db_uuid, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make this HTTPS, and use www.odoo.com as the hostname?
NOT_SAME_DAY_ERROR = _("This session has been opened another day. To comply with the French law, you should close sessions on a daily basis. Please close session %s and open a new one.") | ||
|
||
|
||
def ctx_tz(record, field): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks overly complicated on top of fields.Datetime.context_timestamp
. Not sure it's necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am afraid it is (considering the current crappy implementation of the reporting and user friendliness of the output): context_timestamp doesn't format the date to the locale
But it is not crucial to keep that code....
frequencies are literal (daily means 24 hours and so on) | ||
@return {recordset} all the objects created for the given frequency | ||
""" | ||
def get_selection_value(field, value=''): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you change the value for the selection field from 'annually' to 'annual', you can probably get rid of this ugly function, and replace its calls with simply _(value.capitalize())
(to be tested) ;-)
@qdp-odoo I suggest to rename modules this way to be improve their visibility (SEO, inside the software) and better meet the competition: |
Main resource document to be found at https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf This document states that only business operations with partners not being subject to VAT should be inalterable and secure. We adpat the module by differentiating between b2c and b2b journals and apply hashing on the former's moves Protection against account_cancel is not necessary anymore By default, this module considers a sales journal being a b2c, thus activating hashing on its move. Since we can't afford to lose information, when a b2c journal contains hashed moves, its b2c characteristic cannot be changed [ADD] l10n_fr_pos_cert: module to adapt the POS to the recent French regulation CGI art. 286, I. 3° bis. The module adds following features: - Inalterability: deactivation of all the ways to cancel or modify key data of POS orders, invoices and journal entries - Security: chaining algorithm to verify the inalterability - Access to download the mandatory Certificate of Conformity delivered by Odoo SA (only for Odoo Enterprise users) [ADD] l10n_fr_sale_closing: module to store automatically the total of daily/monthly/annualy sales. (both of the period and cumulative). This fulfills another requirement brought by the recent French regulation CGI art. 286, I. 3° bis related to the storage of data Was PR #20581. Was task 29922
landed in v9 at revision b75927f Will soon be forward ported to newer versions. Also the link to get the certificate is temporary down, since the internal PR is still under process. |
[FIX] l10n_fr_certification: main module Main resource document to be found at https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf This document states that only business operations with partners not being subject to VAT should be inalterable and secure. We adpat the module by differentiating between b2c and b2b journals and apply hashing on the former's moves Protection against account_cancel is not necessary anymore By default, this module considers a sales journal being a b2c, thus activating hashing on its move. Since we can't afford to lose information, when a b2c journal contains hashed moves, its b2c characteristic cannot be changed [ADD] l10n_fr_pos_cert: module to adapt the POS to the recent French regulation CGI art. 286, I. 3° bis. The module adds following features: - Inalterability: deactivation of all the ways to cancel or modify key data of POS orders, invoices and journal entries - Security: chaining algorithm to verify the inalterability - Access to download the mandatory Certificate of Conformity delivered by Odoo SA (only for Odoo Enterprise users) [ADD] l10n_fr_sale_closing: module to store automatically the total of daily/monthly/annualy sales. (both of the period and cumulative). This fulfills another requirement brought by the recent French regulation CGI art. 286, I. 3° bis related to the storage of data Adaptation of #20581 for version 11.0.
Main resource document to be found at https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf This document states that only business operations with partners not being subject to VAT should be inalterable and secure. We adpat the module by differentiating between b2c and b2b journals and apply hashing on the former's moves Protection against account_cancel is not necessary anymore By default, this module considers a sales journal being a b2c, thus activating hashing on its move. Since we can't afford to lose information, when a b2c journal contains hashed moves, its b2c characteristic cannot be changed [ADD] l10n_fr_pos_cert: module to adapt the POS to the recent French regulation CGI art. 286, I. 3° bis. The module adds following features: - Inalterability: deactivation of all the ways to cancel or modify key data of POS orders, invoices and journal entries - Security: chaining algorithm to verify the inalterability - Access to download the mandatory Certificate of Conformity delivered by Odoo SA (only for Odoo Enterprise users) [ADD] l10n_fr_sale_closing: module to store automatically the total of daily/monthly/annualy sales. (both of the period and cumulative). This fulfills another requirement brought by the recent French regulation CGI art. 286, I. 3° bis related to the storage of data Was PR odoo#20581. Was task 29922
Main resource document to be found at https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf This document states that only business operations with partners not being subject to VAT should be inalterable and secure. We adpat the module by differentiating between b2c and b2b journals and apply hashing on the former's moves Protection against account_cancel is not necessary anymore By default, this module considers a sales journal being a b2c, thus activating hashing on its move. Since we can't afford to lose information, when a b2c journal contains hashed moves, its b2c characteristic cannot be changed [ADD] l10n_fr_pos_cert: module to adapt the POS to the recent French regulation CGI art. 286, I. 3° bis. The module adds following features: - Inalterability: deactivation of all the ways to cancel or modify key data of POS orders, invoices and journal entries - Security: chaining algorithm to verify the inalterability - Access to download the mandatory Certificate of Conformity delivered by Odoo SA (only for Odoo Enterprise users) [ADD] l10n_fr_sale_closing: module to store automatically the total of daily/monthly/annualy sales. (both of the period and cumulative). This fulfills another requirement brought by the recent French regulation CGI art. 286, I. 3° bis related to the storage of data Was PR odoo#20581. Was task 29922
Main resource document to be found at https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf This document states that only business operations with partners not being subject to VAT should be inalterable and secure. We adpat the module by differentiating between b2c and b2b journals and apply hashing on the former's moves Protection against account_cancel is not necessary anymore By default, this module considers a sales journal being a b2c, thus activating hashing on its move. Since we can't afford to lose information, when a b2c journal contains hashed moves, its b2c characteristic cannot be changed [ADD] l10n_fr_pos_cert: module to adapt the POS to the recent French regulation CGI art. 286, I. 3° bis. The module adds following features: - Inalterability: deactivation of all the ways to cancel or modify key data of POS orders, invoices and journal entries - Security: chaining algorithm to verify the inalterability - Access to download the mandatory Certificate of Conformity delivered by Odoo SA (only for Odoo Enterprise users) [ADD] l10n_fr_sale_closing: module to store automatically the total of daily/monthly/annualy sales. (both of the period and cumulative). This fulfills another requirement brought by the recent French regulation CGI art. 286, I. 3° bis related to the storage of data Was PR #20581. Was task 29922
TASK 29922 (yes, again)
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr