When I create a Purchase I need to select the Party which is the vendor I’m going to purchase from, but the Party selector will show me all the Parties, including Company, Employee and Parties that are Customers
Proposal
Categorize the Parties in Suppliers and Customer
Implementation
Add a Couple of check boxes in Parties, one for Customer and other one for Supplier. If the third party is a Supplier check the Supplier Box, if it is a Customer check the Customer box, if it is both select both boxes.
In this way we can filter out the selector in Purhcases and Sales documents to show the corresponding Parties, the Suppliers for purchases and the Customer for the Sales
We did not want to have this behavior on supplier because of the danger to create duplicates. The usual failure scenario is when a user needs to fill a purchase. On the purchase form, he searches for the supplier, he does not find it (because it is not checked) so he creates the supplier thinking that it is missing. So now we have twice the supplier defined.
But I can see that they may have some grand control that could be needed for large companies. Often they want to have a validation from some department before allowing to purchase to a supplier. In this case, I think it would make sense to have a validation checkbox (maybe limited to a period). If the supplier has not been validated we could raise a warning. I think only some companies will have such needs so it should be in separate module than purchase.
There is also the case where companies want to enforce to buy only specific products from a supplier. In this case it is about making the product supplier field on the line required.
For the sale, I think it is wrong. Anybody can purchase from a company so we should never filter there. What makes a party a customer, it is because he has purchased something. That the idea behind the “Parties associated to sales” menu entry.
But again we could have some checks to ensure the party is complete to be able to validate the sale order. Ex: complete address or validate VAT number etc. I also think this depends highly on the company rules and so it should be in separated modules and I guess each checks should be discussed within a blueprint.
On the scenario you are pointing, we can prevent users to duplicate parties by implementing mechanisms of name pattern recognition when they try to create from the Party selector.
We filter by default the Party selector depending on where it is being launched, for example, if it is a Purchase order we can filter Party by Category = Supplier and we can expose the filter in the user interface so the user knows what he/she is seeing.
Say they are tempted to create a new Party because they don’t see the one they are looking for, and it is not shown because it was incorrectly categorized as Customer and the Party selector is just showing Suppliers, by the time they type the name of the new Party, Tryton can warn the user stating there is an existing Party with the same/similar name, then user can remove the filter from the selector and show all the Parties, then they can realize that the Party already exists, its just it was categorized as Customer.
Categorizing Parties can bring more valuable functionalities, like create mailing lists to send specific messages to Suppliers, or Customers. This will enable the Parties module to behave more like a CRM
In general , from my point of view, a Party is an entity that interacts somehow with the Company and it could be a Supplier, Vendor, Employee or Bank, so the abstract concept as Party should be instantiated as any of the entities mentioned,
I see no benefit for the user except that he has now much more options and worries to care of.
As we agree that supplier may be wrongly configured. And so they may not be found on the filtered purchase form. I think it is a pretty good reason to not filter but as I said there could be warnings about using an unknown/not validated supplier.
And it is already the case for employee and bank.
The supplier case is more complex because a party become a supplier once the company has buy him something.