Unify purchase description and use the one of supplier if exists
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
Files
| Download | Creator | Timestamp | Type |
|---|---|---|---|
| Screenshot-Ligne d'achat-1.png | @risto42 | 2014-12-06 17:59:04.271000 UTC | image/png |
Activity
added stock + 1 deleted label
assigned to @resteve
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
Thanksadded purchasing type::behavior + 1 deleted label and removed 1 deleted label
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.Are you sure to test the last patch because the code is there: http://codereview.tryton.org/10671002/diff/20001/product.py#newcode172
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.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.review40731002 updated at https://codereview.tryton.org/40731002/#ps1
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)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: #4710 (closed)review40731002 updated at https://codereview.tryton.org/40731002/#ps20001
>> 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: #4710 (closed)
cool, that should do!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.review40731002 updated at https://codereview.tryton.org/40731002/#ps40001
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 productOn 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.
> 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)review40731002 updated at https://codereview.tryton.org/40731002/#ps60001
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'New changeset a4a420f9d50f by Cédric Krier in branch 'default':
Add product supplier on purchase line
http://hg.tryton.org/modules/purchase/rev/a4a420f9d50fmentioned in issue #4251 (closed)
mentioned in issue #4873 (closed)
mentioned in issue #5670 (closed)
mentioned in issue #6822 (closed)
mentioned in issue #6823 (closed)
mentioned in issue #6824 (closed)
mentioned in issue #6836 (closed)
mentioned in issue #6860 (closed)
mentioned in issue #8081 (closed)
mentioned in issue #6885 (closed)
