Created on 2014-03-26.08:31:27 by resteve, last changed 36 months ago by roundup-bot.
|Screenshot-Ligne d'achat-1.png||risto3, 2014-12-06.18:59:04||image/png||view|
New changeset a4a420f9d50f by Cédric Krier in branch 'default': Add product supplier on purchase line http://hg.tryton.org/modules/purchase/rev/a4a420f9d50f
Please report it as new issue as it is not directly linked to this one.
I have been testing this a bit (thanks for rev4) For some reason, (at least on py36), I need the following patch @@ -105,7 +103,7 @@ @classmethod def get_purchase_price_uom(cls, products, name): quantity = Transaction().context.get('quantity', 0) - return cls.get_purchase_price(products, quantity=quantity) + return cls.get_purchase_price(products, quantity=quantity or 0) @classmethod def get_purchase_price(cls, products, quantity=0): to avoid the following when immediately trying to search/select (F2) a product but not when search/select on a supplier's product: Traceback (most recent call last): File "/opt/trytond/trytond/protocols/dispatcher.py", line 165, in _dispatch result = rpc.result(meth(*c_args, **c_kwargs)) File "/opt/trytond/trytond/model/modelsql.py", line 778, in read getter_results = field.get(ids, cls, field_list, values=result) File "/opt/trytond/trytond/model/fields/function.py", line 102, in get return dict((name, call(name)) for name in names) File "/opt/trytond/trytond/model/fields/function.py", line 102, in <genexpr> return dict((name, call(name)) for name in names) File "/opt/trytond/trytond/model/fields/function.py", line 94, in call return method(records, name) File "/opt/trytond/trytond/modules/purchase/product.py", line 106, in get_purchase_price_uom return cls.get_purchase_price(products, quantity=quantity) File "/opt/trytond/trytond/modules/purchase_price_list/product.py", line 22, in get_purchase_price quantity=quantity) File "/opt/trytond/trytond/modules/purchase/product.py", line 159, in get_purchase_price if price.match(quantity, product_uom, pattern): File "/opt/trytond/trytond/modules/purchase/product.py", line 366, in match if test_quantity > quantity: TypeError: '>' not supported between instances of 'float' and 'NoneType'
>> Unfortunately it's rather important that the supplier code be displayed. >> see https://bugs.tryton.org/msg19146 >> >> It's every bit as important as the "name' or even description. > But only in this specific context. Yes, but currently this is in the critical path of the daily workflow. It is the most intensive and time-consuming part and it *must* be correct. Besides, as already stated, it is quite disturbing to type in a code and not get the code part in the [partial] results. The supplier's code must simply be evident somehow. During selection (in the dropdown) and after. All the supplier references (invoices, delivery notes, quotations, catalogues/price-lists and so on) revolve around their product codes. Perhaps there is a different way to do this? (I'm trying not to be overly psycho-rigid)
On 2017-10-06 21:40, richard wrote: > Unfortunately it's rather important that the supplier code be displayed. > see https://bugs.tryton.org/msg19146 > > It's every bit as important as the "name' or even description. But only in this specific context.
Unfortunately it's rather important that the supplier code be displayed. see https://bugs.tryton.org/msg19146 It's every bit as important as the "name' or even description. The company naturally purchases the suppliers products, and it is the code that is the unambiguous identifier for the supplier's product. Guess I don't see what is different than [code]+product for a company's product
On 2017-10-06 19:20, richard wrote: > >> It does need to permit the suppliers code to be entered, though, > >> as that is by far the typical case. The "Product" field supports that now. > > > Fixed in last patchset. > > much better, but it could add the missing code in the drop down list as: > "[<supplier's code>] supplier's name Can not change the record name because it is used globally and the rule is to name things from the company point of view.
>> It does need to permit the suppliers code to be entered, though, >> as that is by far the typical case. The "Product" field supports that now. > Fixed in last patchset. much better, but it could add the missing code in the drop down list as: "[<supplier's code>] supplier's name >> BTW, the field should probably be called "Supplier's Product" >> instead of "Product Suppliers" (which implies a list of suppliers) > There is no ending "s". well, IMHO: 'Product' is a *noun* as indication for what is searched for the in first field in 'Product Supplier', the noun is now 'supplier' for the second, which is unintuitive and rather confusing. Therefore, by using 'Supplier's Product', the noun remains 'Product'. >> Thinking ahead, is it possible to enhance the searcher on the Supplier's >> product field? For things like attributes/variants, manufacturers, and what not. > Searching on Dict field is another topic: issue4710 cool, that should do!
On 2017-10-06 17:34, richard wrote: > gave this a try... not so bad. > it's still seems weird to need an additional field. It is needed to be flexible. There are many small business that will not enter product supplier informations. And other who may even enter multiple (even from the same supplier). > It does need to permit the suppliers code to be entered, though, > as that is by far the typical case. The "Product" field supports that now. Fixed in last patchset. > BTW, the field should probably be called "Supplier's Product" > instead of "Product Suppliers" (which implies a list of suppliers) There is no ending "s". > Thinking ahead, is it possible to enhance the searcher on the Supplier's > product field? For things like attributes/variants, manufacturers, and what not. Searching on Dict field is another topic: issue4710
gave this a try... not so bad. it's still seems weird to need an additional field. It does need to permit the suppliers code to be entered, though, as that is by far the typical case. The "Product" field supports that now. BTW, the field should probably be called "Supplier's Product" instead of "Product Suppliers" (which implies a list of suppliers) Thinking ahead, is it possible to enhance the searcher on the Supplier's product field? For things like attributes/variants, manufacturers, and what not. (yes, I remember being told that currently the product/variant/supplier relations are foobar, but we hope to rapidly address that for our needs as there can be a better way to manage ~18K articles)
Here is a new review40731002 which adds product supplier on the purchase line. I think it is the more flexible solution for user who does not use product supplier and for those who use it intensively.
Not I don't have the time to implement msg19147. Feel free to work on it.
Is there any further progress on this issue?
If in product.line we have a new m2o field to purchase.product.supplier, I think we could obtain information different to show in reports: * Internal company reports: use product field * Supplier reports: use product_supplier field to obtain codes and name from supplier.
OK, I think we should change the logic of the patch. We could add a new field "product supplier" on purchase line. If a value is set on this new field, the product is filled with the linked product if only one exist or limited by a domain. I think it is cleaner design because it lets the user decide which kind of search he wants.
Well, I do have an observation (and a screenshot to demonstrate) While typing the supplier code, the tips still display the non-supplier code/description. This is a bit disturbing in reality. The initial example provided below with 1234 or S1234 is relatively simple, but to demonstrate I have supplier specific codes such as 6001A12 and 6001A14 for company codes 1ACU12 and 1ACU14 respectfully. Typing '6001' should display all the supplier specific codes for '6001...' not the company codes. PM: the product database including suppliers codes is many thousands of entries. Do I understand the patch correctly that the supplier-specific codes are searched in the 'OR' domain statement after the company-specific codes/description? (notwithstanding database sql optimisation) If so, this can be quite brutal, perhaps some additional logic should be put in. For example, a button to "limit" searches to supplier codes (probably on by default or at least configurable). That is, in absence of a supplier code for a quote, the supplier response typically includes their specific code allowing it to be added prior to confirming the PO for action. Also, perhaps it would help to configure a minimal number of characters typed in prior to the tip search to avoid sluggish response (we suffered this already in oerp). Perhaps this last one should have a new issue created.
Okay, I'm testing now... seems that download [raw] didn't pick up the two updated diffs... perhaps an anomalie of sorts
Are you sure to test the last patch because the code is there: http://codereview.tryton.org/10671002/diff/20001/product.py#newcode172
I confirm that patch works setting the PO to "display" the supplier code/description, but I still am not able to select the product with the suppliers code during entry.
Done last review
jumping in here... this is great so far. There is one more use case, when we enter an existing [paper] purchase order. Frequently we recreating manual PO's from supplier delivery orders with a reference and attachment of the paper PO. It should be possible to enter the supplier code to select the product as well. This case happens quite frequently, notably when at the suppliers counter for various parts and materials for construction.
I reworked this issue into a better behaviour of the description of purchase line. It should be the one from the supplier if possible. The review13761002 and review10671002 implement this.
I like to explain what is wrong to add "name" in description line and not "rec name". Scenario: 1- Create a purchase order 2- Create a new line. 3- Select a product. When select a product on change description line: "[code] product name" It's same a sale order, etc... Scenario purchase request: 1- Select purchase request and do a purchase order. 2- Wizard generate a purchase order with selected purchase request. Lines in purchase order, description value is "product name". No add "[code] product name". It's missign code field (generated with rec_name) IMHO, when generate purchase order manual or purchase request, two ways to generate a purchase is different info about description line. My first codereview was fix description line on purchase order lines: "[code] product name" (rec_name) Albert comment about description line from supplier product. I'm agree because some companies don't have same product name that supplier product. An example: My product: * Code: 1234 * Name: Product A My product suplier: * Code: S1234 * Name: Supplier Product A If you generate purchase request, description line is " Product A". When you send your purchase order to supplier, don't know what product is " Product A". It's better add in description line supplier product: "[S1234] Supplier Product A" I hope you now understand about need to fix about description line Thanks
Product name in stock supply use name and not rec_name attribute. Default product name is "code + name". It's necessary use rec_name attribute. review4681002
|2017-12-18 17:56:46||roundup-bot||set||status: testing -> resolved|
nosy: + roundup-bot
messages: + msg37348
|2017-10-28 19:21:44||ced||set||messages: + msg36596|
|2017-10-28 18:35:02||risto3||set||messages: + msg36595|
|2017-10-07 11:16:06||reviewbot||set||messages: + msg36132|
|2017-10-07 07:55:05||risto3||set||messages: + msg36131|
|2017-10-07 00:40:06||ced||set||messages: + msg36127|
|2017-10-06 21:40:44||risto3||set||messages: + msg36124|
|2017-10-06 20:16:23||reviewbot||set||messages: + msg36122|
|2017-10-06 20:05:06||ced||set||messages: + msg36121|
|2017-10-06 19:20:47||risto3||set||messages: + msg36120|
Showing 10 items. Show all history (warning: this could be VERY long)