On Sunday, August 16, 2015 at 11:39:48 PM UTC+2, Cédric Krier wrote: > > Hi, > > I will maybe have the opportunity to start working on a simple POS module > for Tryton.
As we are in process of migrating from OpenERP to Tryton, I'm talking about the pos-module which we now have. For us there are three cases: 1. direct payment 2. pay by picking up but they e.g. called or mailed to reserve the product 3. pay by invoice In all cases a shipment are automaticly made and the employee sets the products apart to be delivered or picked up. If the customer realizes that it's the wrong product, shipment will be canceled and the product is put back in stock. When a customer wants to pay by invoice, the pos-order is moved into sale-order and from that point on, it follows the standard sale-order-workflow. We did this, so we can then group sale-orders onto one invoice. > As I already explained many times, I think extending the > sale object is wrong because the workflows are too much different. > Also for me, a POS should work with tax included price as bases, I fully agree with that. > it should not create shipments nor invoice by default. > For us the pos-module creates shipments by default when the pos-order is confirmed (not payed!), so a pickinglist is created, just to get the product of the shelf. We have two steps: - confirm the pos-order - pay the pos-order or move it to sale-order > So the idea is to have a quite simple object with only: > > - order number > - employee > - shop > - lines (product, quantity, unit price (tax included), price) > The price will come from a new list price tax included on the > product. > > It will have a button to add payments registered as lines on it: > > - journal > - amount > > with change line created on cash journal. > > Once it is fully paid, the order will create: > > - an account move for the sale (on account define in the > configuration) > - stock moves from shop location to customer > > But this default workflow could be modified by requesting an invoice, if > so the party will be requested. This request should be possible on > already paid POS order. > Of course the account move generated by the POS order should be the same > as the one generated by the invoice. > > The design should be take into account such possible extension: > > - using a wizard to add lines > - allow to request a shipment (included back-order) > - support for sale_extra and sale_promotion > - fidelity card > > The design should not care about price list, nor grouping modules. > > I think it could be the foundation for more complex POS using specific > UI (like a web base). > > Did I forget something? Or do you see a use case that could not be > supported? > > Thanks, > -- > Cédric Krier - B2CK SPRL > Email/Jabber: [email protected] <javascript:> > Tel: +32 472 54 46 59 > Website: http://www.b2ck.com/ >
