Master pos back2basic jcb - #51624
Conversation
7763aee to
556c402
Compare
556c402 to
d26cd3b
Compare
d26cd3b to
6f3a8e3
Compare
acdf1d7 to
ecf44cc
Compare
ecf44cc to
45c50ed
Compare
45c50ed to
cfea2ab
Compare
cfea2ab to
06080c9
Compare
06080c9 to
f9cd359
Compare
f9cd359 to
38eef7d
Compare
38eef7d to
6879fe0
Compare
There was a problem hiding this comment.
do we really want one shop by company? When we are in multi company, they already know how to create a shop, and we are not in onboarding anymore
There was a problem hiding this comment.
You are right. I now removed that part.
95c4ca7 to
cdbdf51
Compare
cdbdf51 to
48f9b98
Compare
There was a problem hiding this comment.
I am not sure that creating a pricelist in the default is a good idea, because, if you have a company in euro, a default pricelist in euro already exists. And if you want to create a POS in another currency, you probably want to set a real pricelist (the prices won't be the same in euro than in dolars), so creating one is not necessary
There was a problem hiding this comment.
I put that because I have failing tests in enterprise. I'll try again without this default pricelist.
There was a problem hiding this comment.
I removed the calculation of default pricelist and the error is not there anymore.
7fe467c to
edb933e
Compare
edb933e to
6ee980b
Compare
6ee980b to
191c526
Compare
There was a problem hiding this comment.
Do you think that all changes made here still needed? I also think that "setup_invoice_journal" is not really needed anymore.
There was a problem hiding this comment.
Because of this refactoring, we are able to 1) remove the extensions we made in _create_bank_journals and generate_journals and move them in more centralized location (setup_defaults). (Perhaps I should name it setup_accounting_defaults.) Another benefit is that, 2) we can now easily define a method that loops thru all the pos.config of a given company and setup anything by default when a localisation is installed by hooking it in the setup_defaults method. This includes the setup_invoice_journal.
setup_invoice_journal function is created because the specs require the invoicing capability to be active by default. Without it, even if the module_account is set to default to True, there will be no assigned Invoice Journal in the existing pos.config after installing a fiscal localisation.
There was a problem hiding this comment.
Note that the behavior of the old code didn't change after the refactoring. Except the addition of setup_invoice_journal which you can see in this commit, was very easy to integrate after the refactoring: 3dad52a
|
@caburj Could you just resolve the conflict of this branch, and then I'll merge it. |
Floors associated to the pos.config are deleted when is_table_management is set to False from the backend interface because the backend issues a delete request to the server. So instead of setting the [(5,0,0)] command during onchange, we set it in write method to avoid unintended deletion of the floors.
When adding floor_ids in pos.config, we show only the restaurant.floor records that are not linked to any pos.config. We do this so that one pos.config doesn't steal floors from other pos.config.
Validating the cash register is not needed at this point because it is already validated in _reconcile_account_move_lines.
Refactoring this method to make it extensible. After this refactoring, we can now define methods that can apply defaults to the company's pos.config records during the installation of a localisation. To do so, we hook methods to the setup_defaults method. The hooked methods take pos.config records (self) and a company. The pos.config records belong to the given company.
|
Hi @pimodoo. This is now rebased. |
|
@robodoo r+ rebase-ff |
|
Merge method set to rebase and fast-forward |
Improve usability and first steps
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr