Tryton - Issues

 

Issue3797

Title Unify purchase description and use the one of supplier if exists
Priority feature Status resolved
Superseder Purchase requisition should not set description, Use on_change_product to fill purchase line
View: 6822, 6823
Nosy List bvo, ced, jesteve, kstenger, nblock, resteve, reviewbot, risto3, roundup-bot
Type behavior Components purchase, stock_supply
Assigned To ced Keywords review
Reviews 40731002
View: 40731002

Created on 2014-03-26.08:31:27 by resteve, last changed by roundup-bot.

Files
File name Uploaded Type Edit Remove
Screenshot-Ligne d'achat-1.png risto3, 2014-12-06.18:59:04 image/png
Messages
New changeset a4a420f9d50f by C├ędric Krier in branch 'default':
Add product supplier on purchase line
http://hg.tryton.org/modules/purchase/rev/a4a420f9d50f
msg36596 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-28.19:21:43
Please report it as new issue as it is not directly linked to this one.
msg36595 (view) Author: [hidden] (risto3) Date: 2017-10-28.18:35:01
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'
review40731002 updated at https://codereview.tryton.org/40731002/#ps60001
msg36131 (view) Author: [hidden] (risto3) Date: 2017-10-07.07:55:05
>> 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)
msg36127 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-07.00:40:06
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.
msg36124 (view) Author: [hidden] (risto3) Date: 2017-10-06.21:40:44
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
review40731002 updated at https://codereview.tryton.org/40731002/#ps40001
msg36121 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-06.20:05:05
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.
msg36120 (view) Author: [hidden] (risto3) Date: 2017-10-06.19:20:47
>> 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!
review40731002 updated at https://codereview.tryton.org/40731002/#ps20001
msg36117 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-06.18:35:07
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
msg36113 (view) Author: [hidden] (risto3) Date: 2017-10-06.17:34:52
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)
review40731002 updated at https://codereview.tryton.org/40731002/#ps1
msg36090 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-05.22:27:51
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.
msg22202 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2015-08-24.22:54:54
Not I don't have the time to implement msg19147. Feel free to work on it.
msg22201 (view) Author: [hidden] (risto3) Date: 2015-08-24.19:59:03
Is there any further progress on this issue?
msg19176 (view) Author: [hidden] (resteve) Date: 2014-12-10.11:12:36
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.
msg19147 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2014-12-06.19:14:59
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.
msg19146 (view) Author: [hidden] (risto3) Date: 2014-12-06.18:59:04
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.
msg19139 (view) Author: [hidden] (risto3) Date: 2014-12-06.18:13:53
Okay, I'm testing now... seems that download [raw] didn't pick up the two updated diffs... perhaps an anomalie of sorts
msg19138 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2014-12-06.17:31:05
Are you sure to test the last patch because the code is there: http://codereview.tryton.org/10671002/diff/20001/product.py#newcode172
msg19137 (view) Author: [hidden] (risto3) Date: 2014-12-06.17:01:38
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.
msg19136 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2014-12-06.16:21:56
Done last review
msg19131 (view) Author: [hidden] (risto3) Date: 2014-12-05.18:33:58
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.
msg19071 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2014-12-03.13:41:20
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.
msg16317 (view) Author: [hidden] (resteve) Date: 2014-03-27.08:52:06
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 "[1234] Product A". When
you send your purchase order to supplier, don't know what product is "[1234]
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
msg16314 (view) Author: [hidden] (resteve) Date: 2014-03-26.08:31:26
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
History
Date User Action Args
2017-12-18 17:56:46roundup-botsetstatus: testing -> resolved
nosy: + roundup-bot
messages: + msg37348
2017-10-28 19:21:44cedsetmessages: + msg36596
2017-10-28 18:35:02risto3setmessages: + msg36595
2017-10-07 11:16:06reviewbotsetmessages: + msg36132
2017-10-07 07:55:05risto3setmessages: + msg36131
2017-10-07 00:40:06cedsetmessages: + msg36127
2017-10-06 21:40:44risto3setmessages: + msg36124
2017-10-06 20:16:23reviewbotsetmessages: + msg36122
2017-10-06 20:05:06cedsetmessages: + msg36121
2017-10-06 19:20:47risto3setmessages: + msg36120

Showing 10 items. Show all history (warning: this could be VERY long)