On 10 Feb 15:23, Àngel Àlvarez Serra wrote: > 2015-02-09 19:37 GMT+01:00 Cédric Krier <[email protected]>: > > > > Hi, > > > > I wrote a blueprint to manage customer complaint and actions to take. > > http://code.google.com/p/tryton/wiki/CustomerComplaint > > > > The idea is to have a simple but robust basis that allow customization > > especially for actions to take. > > The action processing will be quite similar to the account_payment > > processing. > > > > It is a good Idea but i prefer it to be more general. > > Sometimes you need manage diferent complaints like purchase, invoice, > production or lot
For me, there are only 2 kinds of complaint customer or supplier. This blueprint is for customer only because the workflow for supplier complaint is completly different. The customer complaint can be linked to anything you want if it is defined. So by default I put only the models that sounds logical when you have sale module installed. > Maybe we can split in two modules. > > Complaint Module. > > complaint > reference: Char > date: Date > customer: Many2One to party.party > address: Many2One to party.address > company: Many2One to company.company > description: Text > employee: Many2One to company.employee > origin: Reference > type: Many2One to sale.complaint.type with domain on origin > state: Selection: 'draft', 'waiting', 'approved', 'done', 'cancelled' > actions: One2Many to sale.complaint.action > > I add this two fields: > cost: Float() > causer: Many2One to party.party. What are that? > complaint.type > name: Char > origin: Many2One to ir.model.model > > complaint.action.type > name: Char > > complaint.action > complaint: Many2One to sale.complaint > description: Text You could define an action which is simple a text. > type: Many2One to complaint.action.tipe Why would you duplicate the type here as it is already on the complaint. > document: reference to any object of ERP, configurable (like sale, > purchase or invoice). It is better to set an origin on the generated record. > It easy and simplier and you can manage any complaint manaually, It is already the case with the proposal. > whith > this designs you can manage refund, or give a present and let for > other modules to make automation. Idem with current proposal. > Sale Complaint Module: > > Add automation of selection with an action. > Create a sale return for the sale origin > Create a sale return for the sale line origin for an optional > quantity and an option unit price > Create a credit note for the invoice origin > Create a credit note for the invoice line origin for an optional > quantity and an So you just want to have no action per default an having an other module for each major modules like sale, account_invoice etc. I don't think it diserve that as for me, customer complaint needs a customer and such parties are in a large cases created by the sale module. Of course, you can imaging company that do only project basis business and so they don't have sale module installed but first it will be strange for such company to manage customer complaint instead of a project task; secondo they still could instal sale module without using it. -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
