Morning Ced, Am Sonntag, 16. August 2015, 23:39:09 schrieb Cédric Krier: > > 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. > Also for me, a POS should work with tax included price as bases, it > should not create shipments nor invoice by default.
Not invoice, but we need a sales slip. > 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. Why a new/different price list? As we need to show the tax amount (by tax category) on a sales slip, and for the keeping it simple, why not reuse the existing sales price list? > 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 I think in general the goods issue is sufficient, a delivery process is not required. We just may need the address of the customer, e.g. for a food delivery service or similar, when the customer does not pick it up in the shop, but it is being delivered. > 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? As said, I think we need a sales slip in any case, with the legally required info: Selling party, Tax number, items, VAT amount per category (full/reduced VAT). For the rest: LGTM! Cheers Axel
