On 2015-08-17 09:09, Axel Braun wrote: > 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.
Yes that's just a report. > > 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? I'm not sure about what you are talking but if it is about the "list price" field on the product, we can not use this one because it is tax excluded. > > 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. If there is a delivery then it is a shipment. > > 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). I'm not sure about the Taxes, I just get one sale slip in front and I have no tax information at all. And that sounds logical for me otherwise it will be exactly like an invoice. -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
