On 2015-08-18 06:58, Mark Hayden wrote: > 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.
Whoaw! That's kind of stupid to show tax excluded price for customer who will have to pay it anyway. But it can be managed by convention that the list price is correctly set according to the net price (a check could even be added). > 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. No, we will not adapt the design of the POS just because Americans are the only one to show tax exclude price to the customers. We will not repeat the history of the %m/%d/%y date format. The Americans will have to adapt the solution to there needs so as far as I see it only requires to store the tax excluded price on the product. > > 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. No, there are more users which works the other way. > > 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. So what you leave the order open. Or not use at all the POS but just the sale. > 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). That just a UI things. > 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. For me, it is out of the scope of a basic module. But I don't see any reason why it should not be possible. > Such a use case could be handled if POS is extensible by specialty modules. Hey, it is Tryton. -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
