Am Montag, 17. August 2015, 10:05:17 schrieb Cédric Krier: > > > 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.
And whats the point in adding up the tax internally? It has to be collected anyway, as confirmed by Korbinian > > > - 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. I feel for a POS it would be overengineered to have a shipment process. Usually the customer walks away with the goods. > > > 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.
