summaryrefslogtreecommitdiff
path: root/addons/purchase_requisition_stock
AgeCommit message (Collapse)Author
2021-04-25[I18N] Update translation terms from TransifexOdoo Translation Bot
2021-03-28[I18N] Update translation terms from TransifexOdoo Translation Bot
2021-02-21[I18N] Update translation terms from TransifexOdoo Translation Bot
2021-02-14[I18N] Update translation terms from TransifexOdoo Translation Bot
2021-02-07[I18N] Update translation terms from TransifexOdoo Translation Bot
2021-01-31[I18N] Update translation terms from TransifexOdoo Translation Bot
2021-01-17[I18N] Update translation terms from TransifexOdoo Translation Bot
2021-01-10[I18N] Update translation terms from TransifexOdoo Translation Bot
2020-11-22[I18N] Update translation terms from TransifexOdoo Translation Bot
2020-11-15[I18N] Update translation terms from TransifexOdoo Translation Bot
2020-11-08[I18N] Update translation terms from TransifexOdoo Translation Bot
2020-10-27[I18N] *: Update translation terms from TransifexMartin Trigaux
Except Spanish, waiting for cleanup closes odoo/odoo#60848 Related: odoo/enterprise#14421 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2020-10-21[REV] *: revert fb7407c for spanish translationsOlivier Dony
There was a problem in the Transifex translations for Spanish and all translations were overwritten by mistake with english defaults. This commit reverts all modified es.po files to their previous version while we work to restore the translations on Transifex.
2020-10-18[I18N] Update translation terms from TransifexOdoo Translation Bot
2020-10-11[I18N] Update translation terms from TransifexOdoo Translation Bot
2020-09-27[I18N] Update translation terms from TransifexOdoo Translation Bot
2020-09-01[I18N] export saas-13.5 source termsMartin Trigaux
Without demo data closes odoo/odoo#56839 Related: odoo/enterprise#12821 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2020-03-11[FIX] purchase_requisition: allow cancellation of SO if no Purchase rightsalt-odoo
A user with no Purchase rights and only Inventory User rights should be able to cancel an SO and access requisition_line_ids field. closes odoo/odoo#47441 X-original-commit: 9a6af5ea576d7eb451fb3c4fa88880eb9edf78af Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
2020-03-05[IMP] purchase_requistion, purchase_requisition_stock: custom variantArnold Moyaux
Allow to use custom product decscription on requisition line. closes odoo/odoo#34174 Task: 1970476 Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
2020-03-05[IMP] purchase_requisition: remove useless inheritArnold Moyaux
_prepapre_tender_values in only call from purchase_requisition_stock. It's not needed to have 2 functions, everything should be in purchase_requisition_stock.
2020-03-05[IMP] base: Display searchpanel on ir.module.module viewsYannick Tivisse
Purpose ======= The current kanban view is messy. It is difficult to identify which apps are installed or not. The user can completely miss a module that might have interested him. A search panel would make things way more readable. closes odoo/odoo#44401 Taskid: 2181557 Related: odoo/enterprise#8144 Related: odoo/upgrade#879 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
2020-01-09[IMP] stock: propagate orderpoint through movesArnold Moyaux
Orderpoint reference are only set on the first object that is created from the procurement request. However sometimes we would like to access it from further object or define another behavior if we come from an orderpoint. Now that the we propagate the orderpoint_id, it's important to ignore po line with an orderpoint AND a chained stock move, else the quantities will be counted twice by the orderpoint in a 2 steps receipt scenario Task: 1849912
2019-12-16[I18N] *: export saas-13.1 source termsMartin Trigaux
Without demo data, for the odoo-master transifex project closes odoo/odoo#41935 X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b Related: odoo/enterprise#7287 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2019-11-18[IMP] * : replace with_context(force_company=c) by with_company(c)Victor Feyens
2019-10-07[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-10-01[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-09-29[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-09-25[IMP] * : manifest module categories cleanupVictor Feyens
closes odoo/odoo#35754 Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
2019-09-22[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-09-15[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-09-13[FIX] purchase_requisition: supplier infoSimon Lejeune
When a blanket order is opened, a supplier info is created and should be used in priority over a regular supplier info with the same values. That's what rev [0] tried to do but there was some mistakes: the `purchase_requisition_id` field added in the order is ignored since it isn't stored and the test didn't failed because the created blanket has a lower price unit than the regular supplier info, meaning it is used in priority. Setting the same price unit (50) result in the new purchase order line merged in the first one. Do not re-implement the same order. Adapt the test now that we know the order didn't work (see rev[1]). The user has to manually set a higher priority to the supplier info generated by the purchase requisition. [0] e85838d358c20859b37e2560c004ee0dcf405c31 [1] 2ac4f2ee0f26678b304929e3352418871ae11857 closes odoo/odoo#36840 Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
2019-09-01[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-08-16[IMP] various: Add multi company domains on viewsPrakash Prajapati
When the many2xxx field relates to a model where company_id is required, set this domain [('company_id','=',company_id.id)] When the company_id field of the related model is not required, set this domain ['|',('company_id','=',company_id.id),('company_id','=',False)] When setting the domain on a field which is in the treeview of a xxx2many field evaluate against the company_id of the 'parent'. Some constraints have been added on sereval models. Take a look at the complete specification for more details. TaskID: 2024446 Closes: #35266 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
2019-07-22[IMP] purchase_requisition: remove dead code from v11mreficent
The commit https://github.com/odoo/odoo/commit/d3dc5048e40d1aef693336d10ce582d39ce17337 from v11 should be removed, as in v12 becomes dead code because the commit https://github.com/odoo/odoo/commit/93ae1b1a041b6a36521263ff87ac980e6102551a deleted the _get_exceptions_domain method. closes odoo/odoo#35256 Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
2019-07-17[REM] *: calls to @api.multiAdrian Torres
Multi is the default api for methods, it is not necessary to explicitly decorate methods with it, adds clutter and most people use it because they see that the rest of the code uses it. Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
2019-07-04[FIX] *: sudo() -> with_user()Raphael Collet
2019-05-29[IMP] api.py: Rename company_id/company_ids into company/companiesYannick Tivisse
The goal is to be coherent with the user property. Actually, company_id and company_ids on the environment are no fields. Calling env.company_id returns a browse record, not an id.
2019-05-13[IMP] base: Contextualize the multi companyYannick Tivisse
Purpose ======= Allow the user to select the allowed companies for which he wants to see records on top of selecting his current company. It is confusing for users to see the records from the company he is connected to and the records of the children companies. Instead of using the hierarchy of companies to access records across companies, the user can now select (from his set of allowed companies) the companies for which he wants to access records. /!\ This means that the user will interact with records from company A when in company B. Example: a SO has been created and confirmed in A. When in B, I create the invoice from it. Specifications ============== 1/ Deprecate the parent/children hierarchy on the res.company model. The fields are kept on the res.company model to ensure the retro-compatibility, but won't be used accross the standard code anymore. The only functional usage for this mechanism was to allow to see records from several companies by creating a virtual parent company, which will be possible with the new mechanism. 2/ By default, a user will only see the records of the company he is connected to (or records without a company). (It is still editable by the user if needed). For that, put this information in the user context, to allow having different configurations on different browser tabs. Instead of having domains like ['|', ('company_id', '=', False), ('company_id', 'child_of', user.company_id.id)] you'll have something like ['|', ('company_id', '=', False), ('company_id', 'in', company_ids)] Note that the 'company_ids' is a value that is passed in the evaluation context on the record rule, as we already have user, or time. company_ids is a list of the ids of all the enabled companies in the user's context. 3/ Out of the generic improvements brought by this task, this will illustrate issues that could exist since several versions. For example, it should not be possible to create a scrap order for the company A with a package of the company B, or it should not be possible to create an invoice on the company A with payment terms from the company B. Before the version 12.0, it was easy to encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side effect of the fact that the SUPERUSER_ID has become an inactive user was to make it more difficult to introduce mismatch on the records, but haven't solved the issue, as it was still possible to do it with parent companies configuration. Some of these issues have been fixed in this commit, but all the business flows should be re-tested to check if an ir.rule should be introduced (eg: a multi company rule for stock.quand.package), if the company of a record is correctly transfered to another record created from the first record (eg: From a SO, create an invoice and a payment, the company of the sales order should be transfered on the invoice and the payment, even if the company of the sales order is A and I'm logged into the company B with the company A enabled. 4/ Currently, if I click on a button on a notification email (example 'View Task'), I face a traceback if I'm not logged into the company of the record. Now, if you click on a button and if you have access to the record, the correct company will be automatically set. 5/ If I display a kanban view with several records from several companies (and an image), all the images should be displayed. 6/ Currently if you copy paste an url, this will crash if you're not in the correct company. This won't be fixed because it's quite impossible to do it in a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into the correct company, re-copy/paste -> Ok. 7/ 2 property methods have been added on the environment to retrieve the company on which the user is logged in and the companies the user enabled, on a specific tab. That way, when creating a record, instead of doing default=lambda self: self.env.user.company_id do default=lambda self: self.env.company_id On the other hand, to retrieve the enabled companies, do companies = self.env.company_ids 8/ Modify the Company Switcher widget to allow to log into another company WITHOUT writing on the res.users (and thus bringing cache invalidation issues and so on). Also allow to enable several companies and see records from several companies, and independantly of the other browser's tabs. 9/ When focusing on a tab, save the current company configuration on the local storage. That way, when doing 'CTRL+T' or a middle click, the context is propagated to the new tab. 10/ Improve the error message in case of multi company access errors. Now, when the user is in debug mode, display the related names of the records and the name of the user who brings the issue. 11/ Remove the context erasing when writing on a res.users This is probably coming from the migration to new API of the base module. The context was not propagated at this moment, which was a common mistake at that time. When migrating the module, probably by using the 'black box' method, as the context was not propagated, it was erased on the new version. This is now an issue because the context (i.e. the enabled companies) was erased when writing on a res.users, leading to tracebacks. See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624 12/ Fix the crash manager on redirect warnings. The issue is the following - Create an invoice on a company without a configured CoA. - Set a partner - On the onchange_partner_id, a redirect warning is raised to propose you to configure a CoA - Click on 'Go to the configuration panel' - A generic warning says something like 'Do you want to discard your changes?' - Click on yes, the page refreshes, but not on the redirect action. Now, set correctly the action on the hash, and reload instead. The breadcrumb is lost for example, but you reach the correct action at least. 13/ Introduce a res.group to enable/disable the multi company per tab feature. 14/ To help the users to know which tab is in which company, add the possibility to have a favicon per company. When creating a company, the classical 'O' icon is colored by default in a random color. 15/ Remove the company switcher on the frontend. This was mainly there to allow a user to swicth to the company linked to the website. This behavior is now transparent to the user. If the website A is activated, then the company set on the context is the company of the website. 16/ Deprecated the _company_default_get method on the res.company model. Remove the method _get_company on the res.users model. 17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval context. You can now use those variables on domains in the views to access directly to the activated company.ies on the current tab. TaskID: 1960971 closes odoo/odoo#32341 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
2019-03-20[I18N] export saas-12.2 source termsMartin Trigaux
closes odoo/odoo#31985 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2019-02-14[REF] stock, stock_*: procurement batch by rules's actionsArnold Moyaux
Improve the procurement requests performance. Instead of processing procurement request one by one, search rules that apply for each of them and group them by rule's actions. The main technical change is the record creation order. E.g. 2 SO lines with pick ship delivery. -Before this commit: line1 -> LAUNCH_RULE -> PICK MOVE1 -> MOVE1 CONFIRM -> OUT MOVE1 line2 -> LAUNCH RULE -> PICK MOVE2 -> MOVE2 CONFIRM -> OUT MOVE2 -After this commit: line1/2 -> LAUNCH RULE -> PICK MOVE1/2 -> MOVE1/2 CONFIRM -> OUT MOVE1/2 Also there is one batch creation by company_id. It implies that values are group by company_id. Since company_id are passed by previous procurement or by the rule, it become a required value and it's added to the procurement arguments (it was already always passed in the values, no functional modification). _run_buy is reworked. It receives a bathc of procurements, those procurements could be merged in the same PO or the same PO lines. However the PO/PO lines are created (if procurement couldn't be merged in an existing one) at the end of the method. It implies that 2 procurements creating a PO and merged inside, would now create 2 distinct PO (same for po lines). _run_buy in order to fix this issue: - group procurements by PO search domain. If the PO doesn't exist, create only one. - Inside the same PO: merge quantities, move_dest_ids for procurements with the same product and UoM. Other _run_ methods are just adjusted in order to process batch. For a pick pack ship scenario, without procurment_jit confirm a SO containing 500 lines will take 40s instead of 15 minutes.
2019-02-01[FIX] purchase_requisition_stock: onchange and picking typePrakash Prajapati
Issue: - Create a RFQ for a stockable product - Try to validate - A required field "deliver to" (picking_type_id) is not set Rev [1] moved the stock related part of purchase_requisition to purchase_requisition_stock. It implements an onchange on the purchase order setting the picking_type_id of the one of the requisition. When no requisition is set, it wiped the default one. We fix the issue by only using the picking type of the requisition if a requisition is actually set. [1] 826f927a1ed54f6e2468e8f3b8649c1b7cfdf04b Task: 1935077 closes odoo/odoo#30685
2019-01-17[IMP] purchase_requisition: improve testHaresh Shyara
Create data for all tests in order to speed data test creation. We don't want the test to be demo data dependent What we are testing in this test case. -> Check that procurement is creating requisition with correct details or not. -> Check that purchase order created is consistent when we create it with supplier info. -> Two blanket orders on different 'make to order' products must generate two different purchase orders. Task ID : 1851286 closes odoo/odoo#30187
2019-01-17[MOV] purchase_requisition: make requisition services friendlyHaresh Shyara
The purpose of this commit is to make requisition usable with only services. Stock part is extracted in a new module `purchase_requisition_stock` which allows to create requisition based on product availbility or demand, also we have moved all security access related stock in this bridge module. Task ID : 1851286