Point of sale wold be very welcome feature! I have some comments below... On 16 Aug 2015 15:39, "Cédric Krier" <[email protected]> wrote: > > Hi, > > I will maybe have the opportunity to start working on a simple POS module > for Tryton. As I already explained many times, I think extending the > sale object is wrong because the workflows are too much different.
The sale object would serve the purpose for data requirements, but as you say the workflow is not geared towards a retail storefront with lots of cash sales. This could be handled with wizards automating the process behind the scenes (have played with nereid web shop to do this) but a new module and classes would likely be a cleaner solution. > Also for me, a POS should work with tax included price as bases, it > should not create shipments nor invoice by default. > Stock moves are required for inventory control but full shipments are not as POS use cases rarely require collection of customer name and address. As for taxes, in North America it is actually quite unusual to work on a tax included basis. The only common exception seems to be petrol(gasoline) which is advertised per litre (or gallon in US) tax included. The exception for fuel is supposedly because when sales taxes were introduced retrofitting fuel pumps to calculate and display the tax separately would have been too expensive. In Canada is is a requirement by law to either show the price NOT including tax, unless you also have a sign that says "posted price includes x% tax". So instead of having a sign on every shelf with that message as required by law stores prefer to show prices with tax excluded (on fuel pumps you always find such a message printed on them somewhere, and in the attached garage/store all other prices are posted without tax included). Also from a marketing perspective the number without taxes is lower, so if you have a sign that says "4.99 (includes 12% HST)" and your competitor has a sign that simply says 4.46 you look more expensive at first glance. So even if tax included is more convenient retail here has gone with the custom of showing base price without tax. Regardless of how prices are displayed, invoices and till receipts by law are always required to show the base price and tax separated, preferably line by line as some items are tax exempt. Sales taxes can be a complex issue in some jurisdictions, so you cannot oversimplify. Best to keep the price list as is and just have a tax included function field with feature to allow the user to work one way or the other at the interface level. > 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. As stated above, a new list price is not convenient for many users if it requires them to work on a tax included basis. Please make that optional. > > 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 > Agreed that these are the most common POS features. > 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? Hospitality industry (hotels and restaurants) would have some special use cases, which may differ in Europe vs North America in some places. In these cases customers usually have an open bill or tab that they pay upon leaving the establishment. On restaurant tabs there are frequently cases where prices are adjusted on the fly (substituted item in a meal, price reduction for dissatisfied diner etc). Plus it is customary in many places to leave a gratuity for the serving staff which may need to be accounted for and/or paid out of the till. Such a use case could be handled if POS is extensible by specialty modules. > > Thanks, > -- > Cédric Krier - B2CK SPRL > Email/Jabber: [email protected] > Tel: +32 472 54 46 59 > Website: http://www.b2ck.com/
