Starting a POS module

[Cédric Krier]

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.
Also for me, a POS should work with tax included price as bases, it
should not create shipments nor invoice by default.

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.

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

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?

Thanks,
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Axel Braun]

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

[Cédric Krier]

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.

[Korbinian Preisler]

There is indeed a requirement for taxes on the sale slip. It is similar
to the invoice but not the same as you do not need to provide the name
and the address of the customer on the sale slip.

In Germany you do not need to provide the taxes on sale slips with an
amount lower than 200 EUR. Maybe your country does have a similar rule.

[Christophe (net)]

Le 16/08/2015 23:39, Cédric Krier a écrit :
> 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.
> Also for me, a POS should work with tax included price as bases, it
> should not create shipments nor invoice by default.
>
> 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.
>
> It will have a button to add payments registered as lines on it:
>
> - journal
> - amount
>
> with change line created on cash journal.

may be able to differentiate the types of payment: cash, credit card,
check ...

>
> 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
>
> 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?
>
> Thanks,
>

--

Christophe
http://adiczion.com

[Axel Braun]

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.

[Cédric Krier]

On 2015-08-17 10:52, Axel Braun wrote:
> 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

Because you are saling tax included and marketing wants nice price.

> > > > - 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.

That's why I put it as an extra feature (re-read my email).

[Cédric Krier]

On 2015-08-17 10:44, Christophe (net) wrote:
> Le 16/08/2015 23:39, Cédric Krier a écrit :
> >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.
> >Also for me, a POS should work with tax included price as bases, it
> >should not create shipments nor invoice by default.
> >
> >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.
> >
> >It will have a button to add payments registered as lines on it:
> >
> > - journal
> > - amount
> >
> >with change line created on cash journal.
>
> may be able to differentiate the types of payment: cash, credit card, check
> ...

That's the journal.

[ferr...@gmail.com]

Is there a way I can help?

[Cédric Krier]

On 2015-08-17 10:29, ferr...@gmail.com wrote:
> Is there a way I can help?

For now, I'm just in the information collection and design phase.
Later there will be the need to have testers.

[ferr...@gmail.com]

For now, I'm just in the information collection and design phase.
Later there will be the need to have testers.

It would be nice if
(1) It prints directly to an installed printer, instead of generating a document (PDF, ODT, etc.),
(2) it reads and finds barcodes (generating and printing would be a plus).

[Axel Braun]

Am Montag, 17. August 2015, 11:19:43 schrieb Cédric Krier:

> > > > 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
>
> Because you are saling tax included and marketing wants nice price.

You always want nice price, if you sell via Web, catalog or POS.
If it costs 2,99 RRP, its 2,99, even if you write 2,51 + 19% VAT (0,48). Just
need to make sure the tax amount can be shown.

> > > > > - 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.
>
> That's why I put it as an extra feature (re-read my email).

The option to have it as feature does not change the fact that a shipment from
POS is overengineerd at that point.

- Are you picking up your Pizza or shall we deliver?
- Please deliver
- Hang on, since we use Tryton POS we first need to generate a shipment, add a
handling unit (carton) to it, determine the shipping route and print
documents. No problem Mr. Krier, but your Pizza will be cold at that time.

(just print delivery address on the sales slip. Optional)

Any opinions from other readers?

[Dominique Chabord]

2015-08-18 8:37 GMT+02:00 Axel Braun <axel....@gmx.de>:

>>
>> That's why I put it as an extra feature (re-read my email).
>
> The option to have it as feature does not change the fact that a shipment from
> POS is overengineerd at that point.
>
> - Are you picking up your Pizza or shall we deliver?
> - Please deliver
> - Hang on, since we use Tryton POS we first need to generate a shipment, add a
> handling unit (carton) to it, determine the shipping route and print
> documents. No problem Mr. Krier, but your Pizza will be cold at that time.
>
> (just print delivery address on the sales slip. Optional)
>
> Any opinions from other readers?

I don't understand your point and how this kind od dialog could
happen. To respect data consistency, if some goods leave the company
to the customer, it must generate a move. That's a minimum.

[Axel Braun]

When something is sold from a POS, the stock must be reduced, so we have a
goods issue. I think so far we agree.
In a typical POS scenario the customer walks away with what he has bought, so
there is no need for a delivery - or shipment.
In some special cases the goods might de delivered as a service - from the
grocery to the customer, the pizza delivery service, or some TV or microwaves,
which are too heavy to carry, or because the customer has no car to transport.
These are service deliveries to a customer near by, so there is no need to
trigger a complex shipment scenario.
My point is to keep the goods movement at sale and just add address
information, instead of starting a shipment process.
Thats the point of discussion.

[Cédric Krier]

On 2015-08-18 08:37, Axel Braun wrote:
> Am Montag, 17. August 2015, 11:19:43 schrieb Cédric Krier:
>
> > > > > 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
> >
> > Because you are saling tax included and marketing wants nice price.
>
> You always want nice price, if you sell via Web, catalog or POS.
> If it costs 2,99 RRP, its 2,99, even if you write 2,51 + 19% VAT (0,48). Just
> need to make sure the tax amount can be shown.

Except it is impossible to get all the possible net price with such
computation.
So clearly a net price field on the product form is needed.

> > > > > > - 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.
> >
> > That's why I put it as an extra feature (re-read my email).
>
> The option to have it as feature does not change the fact that a shipment from
> POS is overengineerd at that point.
>
> - Are you picking up your Pizza or shall we deliver?
> - Please deliver
> - Hang on, since we use Tryton POS we first need to generate a shipment, add a
> handling unit (carton) to it, determine the shipping route and print
> documents. No problem Mr. Krier, but your Pizza will be cold at that time.

So in your example the deliver guy is the one who also answer the phone.
That looks really completly strange.

> (just print delivery address on the sales slip. Optional)

And what if all can not be deliveried because clearly the customer
doesn't have the items with him?

> Any opinions from other readers?

Indeed I don't care about your opinions on what I *already* called an
*EXTRA FEATURE*.

[Cédric Krier]

On 2015-08-17 11:38, ferr...@gmail.com wrote:
>
>
> > For now, I'm just in the information collection and design phase.
> > Later there will be the need to have testers.
> >
> It would be nice if
> (1) It prints directly to an installed printer, instead of generating a
> document (PDF, ODT, etc.),

That's not part of Tryton feature. But the client can "direct print" on
default printer on most OS.

> (2) it reads and finds barcodes (generating and printing would be a plus).

Tryton doesn't provide any hardware so if you want to read barcode, you
have to buy a barcode reader. Barcodes are just codes which already
exist on product form.

[Axel Braun]

Am Dienstag, 18. August 2015, 10:06:17 schrieb Cédric Krier:
> > Any opinions from other readers?
>
> Indeed I don't care about your opinions on what I *already* called an
> *EXTRA FEATURE*.

Stop shouting at me.
If you cant stand business knowledge beyond your horizon, dont ask.

EOD

[Markus Bala]

Just my 2 cents of opinion, since POS consider new in tryton. 

It will be good design in the very basic which is  "POINT OF SALE" --> selling and transaction on the spot.

In the expansion for extra features such as delivery, invoice or etc.. in other modules.

[Dominique Chabord]

2015-08-18 10:00 GMT+02:00 Axel Braun <axel....@gmx.de>:


>
> When something is sold from a POS, the stock must be reduced, so we have a
> goods issue. I think so far we agree.
> In a typical POS scenario the customer walks away with what he has bought, so
> there is no need for a delivery - or shipment.

but you need a move, and a move which put goods outside the company is
called a delivery since ever.

> In some special cases the goods might de delivered as a service

This is basic too. I don't see the point.


- from the

> so there is no need to
> trigger a complex shipment scenario.

I don't understand why there is a shipment scenario. Generating a move
is automated and you don't have to print any document you don't need.

> My point is to keep the goods movement at sale and just add address
> information, instead of starting a shipment process.

It impacts levels of stocks and accounting. It has nothing to do with sales.

[Cédric Krier]

You need to if the customer doesn't take the product with him because:

- products must be assigned
- back order must be managed
- delivery service must be warned about something to do

> My point is to keep the goods movement at sale and just add address
> information, instead of starting a shipment process.

This will not work because it is too simplistic.

[Maria Cecilia Santos Popper]

On Sunday, August 16, 2015 at 6:39:48 PM UTC-3, Cédric Krier 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.
Also for me, a POS should work with tax included price as bases, it
should not create shipments nor invoice by default.

This is really good news!

In our case (Argentina) POS sales are usually the case with sales over the counter where the client picks up the product.  We have a kind of tax entity called "Final Consumer" for this type of client. This type of transaction does not require to show the tax ammount in the invoice report (though the tax is included in the price and the company needs to declare it at the end of the taxable month/semester/year).

We have a special type of invoice  for this kind of sales: It is a legal invoice but the tax is not detailed).

In our case, we are are using the sale_pos from ZikZaKMedia, which also haves an option to set "Self PIck UP" by default so it handles stock movements automatically.

Just my 2 cents

[Mark Hayden]

Point of sale wold be very welcome feature! I have some comments below...

On 16 Aug 2015 15:39, "Cédric Krier" <cedric...@b2ck.com> 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.

[David Bruchmann]

In our case (Argentina) POS sales are usually the case with sales over the counter where the client picks up the product.  We have a kind of tax entity called "Final Consumer" for this type of client. This type of transaction does not require to show the tax ammount in the invoice report (though the tax is included in the price and the company needs to declare it at the end of the taxable month/semester/year).

We have a special type of invoice  for this kind of sales: It is a legal invoice but the tax is not detailed).

In our case, we are are using the sale_pos from ZikZaKMedia, which also haves an option to set "Self PIck UP" by default so it handles stock movements automatically.

This shows what I thought already, that taxes are not handled the same in each country, furthermore it might depend on the kind of business if and how they are shown (i.e. for gnu health different than for a warehouse).

While on the one hand it would be nice to cover any existing standards, on the other hand being able to meet national requirements by configuration.

So I'd like to see standards for that what Axel called "business knowledge" if possible.

Best Regards,

David

[Cédric Krier]

On 2015-08-18 20:02, David Bruchmann wrote:
> >
> >
> >> In our case (Argentina) POS sales are usually the case with sales over
> > the counter where the client picks up the product. We have a kind of tax
> > entity called "Final Consumer" for this type of client. This type of
> > transaction does not require to show the tax ammount in the invoice report
> > (though the tax is included in the price and the company needs to declare
> > it at the end of the taxable month/semester/year).
> > We have a special type of invoice for this kind of sales: It is a legal
> > invoice but the tax is not detailed).

> > In our case, we are are using the *sale_pos
> > <https://bitbucket.org/zikzakmedia/trytond-sale_pos>* from ZikZaKMedia,

> > which also haves an option to set "Self PIck UP" by default so it handles
> > stock movements automatically.
> >
>
>
> This shows what I thought already, that taxes are not handled the same in
> each country,

I higly doubt about that. A Tax is simply a tax.

> furthermore it might depend on the kind of business if and
> how they are shown (i.e. for gnu health different than for a warehouse).

I still doubt about that.

> While on the one hand it would be nice to cover any existing standards, on
> the other hand being able to meet national requirements by configuration.

Here what they call another type of invoice is not what we named in
Tryton an invoice. So I'm pretty sure that the POS order will have all
the requirements to be considered as this kind of invoice.

[E. Boer]

On Sunday, August 16, 2015 at 11:39:48 PM UTC+2, Cédric Krier wrote:

Hi,

I will maybe have the opportunity to start working on a simple POS module
for Tryton.

As we are in process of migrating from OpenERP to Tryton, I'm talking about the pos-module which we now have. For us there are three cases:
1. direct payment
2. pay by picking up but they e.g. called or mailed to reserve the product
3. pay by invoice

In all cases a shipment are automaticly made and the employee sets the products apart to be delivered or picked up. If the customer realizes that it's the wrong product, shipment will be canceled and the product is put back in stock. When a customer wants to pay by invoice, the pos-order is moved into sale-order and from that point on, it follows the standard sale-order-workflow. We did this, so we can then group sale-orders onto one invoice.

 

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,

I fully agree with that.
 

it should not create shipments nor invoice by default. 

For us the pos-module creates shipments by default when the pos-order is confirmed (not payed!), so a pickinglist is created, just to get the product of the shelf. We have two steps:
- confirm the pos-order
- pay the pos-order or move it to sale-order
 

[Cédric Krier]

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.

[Mark Hayden]

On 18 Aug 2015 07:45, "Cédric Krier" <cedric...@b2ck.com> wrote:
>
> On 2015-08-18 20:02, David Bruchmann wrote:
> > >
> > >
> > >> In our case (Argentina) POS sales are usually the case with sales over
> > > the counter where the client picks up the product.  We have a kind of tax
> > > entity called "Final Consumer" for this type of client. This type of
> > > transaction does not require to show the tax ammount in the invoice report
> > > (though the tax is included in the price and the company needs to declare
> > > it at the end of the taxable month/semester/year).
> > > We have a special type of invoice  for this kind of sales: It is a legal
> > > invoice but the tax is not detailed).
> > > In our case, we are are using the *sale_pos
> > > <https://bitbucket.org/zikzakmedia/trytond-sale_pos>* from ZikZaKMedia,
> > > which also haves an option to set "Self PIck UP" by default so it handles
> > > stock movements automatically.
> > >
> >
> >
> > This shows what I thought already, that taxes are not handled the same in
> > each country,
>
> I higly doubt about that. A Tax is simply a tax.

I've never encountered a tax that is simple ;-)

Taxes are not only handled differently in some countries, but even within one country depending on location and industry. In Canada retail operations even have different rules for businesses operated on aboriginal reserve land for example.

A general purpose module need not handle every specific case, however some aspects if tax calculation and display must be configurable.

>
> > furthermore it might depend on the kind of business if and
> > how they are shown (i.e. for gnu health different than for a warehouse).
>
> I still doubt about that.

Service stations are a common example in north america as i mentioned earlier. Prices for fuel dispensed at pumps is displayed tax included. All other goods without. Typically only very small retail operations that are exempt from taxes or operate heavily with non electronic cash transactions (and so round prices to whole dollars and need little signage notifying the tax is included) operate on a tax included basis here...food trucks, snack food concession stands at hockey arenas, etc

>
> > While on the one hand it would be nice to cover any existing standards, on
> > the other hand being able to meet national requirements by configuration.
>
> Here what they call another type of invoice is not what we named in
> Tryton an invoice. So I'm pretty sure that the POS order will have all
> the requirements to be considered as this kind of invoice.

What is an invoice in Tryton is a proper invoice. This other document in a point of sale situation here is referred to as a till receipt. Both are records of a transaction and have some common information but a till receipt doesn't have detailed descriptions, payment terms or a workflow since it is a record of a sale already concluded. That makes them different documents to me rather than being different variants of the same document.

[Cédric Krier]

On 2015-08-18 06:31, E. Boer wrote:
>
> On Sunday, August 16, 2015 at 11:39:48 PM UTC+2, Cédric Krier wrote:
> >
> > Hi,
> >
> > I will maybe have the opportunity to start working on a simple POS module
> > for Tryton.
>
>
> As we are in process of migrating from OpenERP to Tryton, I'm talking about
> the pos-module which we now have. For us there are three cases:
> 1. direct payment
> 2. pay by picking up but they e.g. called or mailed to reserve the product
> 3. pay by invoice
>
> In all cases a shipment are automaticly made and the employee sets the
> products apart to be delivered or picked up. If the customer realizes that
> it's the wrong product, shipment will be canceled and the product is put
> back in stock. When a customer wants to pay by invoice, the pos-order is
> moved into sale-order and from that point on, it follows the standard
> sale-order-workflow. We did this, so we can then group sale-orders onto one
> invoice.

> > it should not create shipments nor invoice by default.
> >
>
> For us the pos-module creates shipments by default when the pos-order is
> confirmed (not payed!), so a pickinglist is created, just to get the
> product of the shelf. We have two steps:
> - confirm the pos-order
> - pay the pos-order or move it to sale-order

So for me what you are describing is not a POS but a normal sale because
the customer doesn't have the products with him. So you probably need to
check if you have the product in stock or make a reservation etc.

[Cédric Krier]

On 2015-08-18 08:11, Mark Hayden wrote:
> On 18 Aug 2015 07:45, "Cédric Krier" <cedric...@b2ck.com> wrote:
> > I higly doubt about that. A Tax is simply a tax.
>
> I've never encountered a tax that is simple ;-)

I never said that.

> Taxes are not only handled differently in some countries, but even within
> one country depending on location and industry. In Canada retail operations
> even have different rules for businesses operated on aboriginal reserve
> land for example.
>
> A general purpose module need not handle every specific case, however some
> aspects if tax calculation and display must be configurable.

Do you know the Tax system of Tryton before asking?

> > > While on the one hand it would be nice to cover any existing standards,
> on
> > > the other hand being able to meet national requirements by
> configuration.
> >
> > Here what they call another type of invoice is not what we named in
> > Tryton an invoice. So I'm pretty sure that the POS order will have all
> > the requirements to be considered as this kind of invoice.
>
> What is an invoice in Tryton is a proper invoice. This other document in a
> point of sale situation here is referred to as a till receipt. Both are
> records of a transaction and have some common information but a till
> receipt doesn't have detailed descriptions,

Of what?

> payment terms

Why payment term when you are talking about a POS?

> or a workflow

What do you mean by workflow?

> since it is a record of a sale already concluded. That makes them different
> documents to me rather than being different variants of the same document.

Why will it have to be different?

[David Bruchmann]

Taxes are quite complicated.

In Germany for common products are 2 different taxes on common products: either 7% or 19%.

For some higher taxes like for Tobacco and Patrol Products I don't know how it's calculated at the POS. In general it's possible that it's calculated at the POS with 19% but with a different value at a B2B point - honestly I just don't know.

Furthermore there existed some special tax for salt which was abolished but it had to be expected perhaps that resembling taxes still exist in other countries,

As long as you plan to include an option for different unlimited tax-classes I don't see a problem here, but concerning the abolished salt-tax I don't know if there have been even 2 taxes on one product.

As far as I see a configurable option would be nice, so even for US never had to be programmed anything extra.

I know it's Tryton, but it's international, isn't it?

Best Regards,

David

[Mark Hayden]

I agree it is not logical, but in Canada and US retail is often not a logical business! The culture here is much more anti-tax than in Europe and business owners and the public in general exert a lot of pressure to make sure people are informed of how much tax is being paid to government. It is a cultural and historical thing--if what you are being taxed is not prominently displayed then people worry the rate can be too easily raised or shopkeepers are being dishonest. It is not logical but it's how things work.

It is also due to sales taxes being overly complicated. Many items are tax exempt and people need to be informed which are.  For example, a single bottle of a beverage 1 litre or less is taxable, but the same exact product sold in a box of more than 5 or a bottle bigger than 1 litre is tax exempt because it is bulk/grocery.

That said your solution would work fine--if both prices are easily accessible how it is managed behind the scenes is irrelevant

> > 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.
>

Don't get me started on dates...there are different preferences even between canada/us/Mexico! Plus the US being so insistent with avoiding metric when even Canada and Mexico have long since adopted metric...

Anyways special needs can be addressed with modules like chart of accounts do ..

A module to modify for

[Cédric Krier]

On 2015-08-18 21:09, David Bruchmann wrote:
> Taxes are quite complicated.
> In Germany for common products are 2 different taxes on common products:
> either 7% or 19%.
> For some higher taxes like for Tobacco and Patrol Products I don't know how
> it's calculated at the POS. In general it's possible that it's calculated
> at the POS with 19% but with a different value at a B2B point - honestly I
> just don't know.
> Furthermore there existed some special tax for salt which was abolished but
> it had to be expected perhaps that resembling taxes still exist in other
> countries,
> As long as you plan to include an option for different unlimited
> tax-classes I don't see a problem here, but concerning the abolished
> salt-tax I don't know if there have been even 2 taxes on one product.

So what there are nothing new which Tryton doesn't manage already.

> As far as I see a configurable option would be nice, so even for US never
> had to be programmed anything extra.

That's not the Tryton way. If you have specific requirements you have to
create a module for that.

> I know it's Tryton, but it's international, isn't it?

I don't understand the point as I don't know to what you are answering.
So please don't top-post on this mailing list, see
http://groups.tryton.org/netiquette

[Maria Cecilia Santos Popper]

On Tuesday, August 18, 2015, Cédric Krier <cedric...@b2ck.com> wrote:

On 2015-08-18 20:02, David Bruchmann wrote:
> >
> >
> >> In our case (Argentina) POS sales are usually the case with sales over
> > the counter where the client picks up the product.  We have a kind of tax
> > entity called "Final Consumer" for this type of client. This type of
> > transaction does not require to show the tax ammount in the invoice report
> > (though the tax is included in the price and the company needs to declare
> > it at the end of the taxable month/semester/year).
> > We have a special type of invoice  for this kind of sales: It is a legal
> > invoice but the tax is not detailed).
> > In our case, we are are using the *sale_pos
> > <https://bitbucket.org/zikzakmedia/trytond-sale_pos>* from ZikZaKMedia,
> > which also haves an option to set "Self PIck UP" by default so it handles
> > stock movements automatically.
> >
>
>
> This shows what I thought already, that taxes are not handled the same in
> each country,

I higly doubt about that. A Tax is simply a tax.

Just a side note to clarify in regard to my comment about taxes and types of invoices. In Argentina one may need to use three different type of invoices: A, b or c. The first one is used to bill companies, the second one to end users (final consumer where tax isI included) and the third one to tax exent organizations. So in Tryton we use three different sequences to handle invoices according to the type of customer. This is managed by the account__ar module created by Gcoop (sorry I don't provide with a link but I'm on the road with little access to data coverage).  This module adds a field in the party's module where you can set the Vat condition for that party (a, b or c). Just to comment how invoices are handled and that, in our case, there are different types.

 

> furthermore it might depend on the kind of business if and
> how they are shown (i.e. for gnu health different than for a warehouse).

I still doubt about that.

> While on the one hand it would be nice to cover any existing standards, on
> the other hand being able to meet national requirements by configuration.

Here what they call another type of invoice is not what we named in
Tryton an invoice. So I'm pretty sure that the POS order will have all
the requirements to be considered as this kind of invoice.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

 

--

Lic. Cecilia Santos Popper

Santa Fe
www.linkedin.com/in/ceciliasp/

[Cédric Krier]

I don't understand that. Is the type of invoice depends on how you
display the price on the product? That sounds very strange.

> and the third one
> to tax exent organizations.

I don't understand what is that?

> So in Tryton we use three different sequences
> to handle invoices according to the type of customer. This is managed by
> the account__ar module created by Gcoop (sorry I don't provide with a link
> but I'm on the road with little access to data coverage). This module adds
> a field in the party's module where you can set the Vat condition for that
> party (a, b or c).

But that sounds like the tax rules. Why creating something else?

> Just to comment how invoices are handled and that, in
> our case, there are different types.

But I still think your are mixing invoice with POS receipt.

[Ossi Viljakainen]

On Tuesday, August 18, 2015 at 4:25:03 PM UTC+2, David Bruchmann wrote:

Taxes are quite complicated.

In Germany for common products are 2 different taxes on common products: either 7% or 19%.

Yes, these are VAT. (MvSt.) There can be one, two or more VAT categories depending on country.

Finland has 3 + tax free:

1. Standard rate 24% (goods)

2. Reduced rate I 14% (food & restaurants)

3. Reduced rate II 10% (books, pharmaceuticals, public transport, cinema, newspapers)

4. VAT Free 0% (doctor, dentist, hospital, insurance, lottery)

 

For some higher taxes like for Tobacco and Patrol Products I don't know how it's calculated at the POS. In general it's possible that it's calculated at the POS with 19% but with a different value at a B2B point - honestly I just don't know.

Furthermore there existed some special tax for salt which was abolished but it had to be expected perhaps that resembling taxes still exist in other countries,

Tobacco tax, alcohol tax, sugar tax etc taxes are not POS taxes. They are not calculated at POS. They are added to the price at point of manufacture, and part of the product price throughout the retail chain. Only the manufacturer pays the tax to the government.

 

As long as you plan to include an option for different unlimited tax-classes I don't see a problem here, but concerning the abolished salt-tax I don't know if there have been even 2 taxes on one product.

In USA they have very weird and complex, illogical tax system, as mentioned earlier, tax depends on which product category, quantity of sale, in which state you are located, whether on reservate or private land, on the street widht, the house number, the strenght on wind, the tide and amount of sunshine your shop gets :D

 

As far as I see a configurable option would be nice, so even for US never had to be programmed anything extra.

Most of the wold uses tax included prices. This is true specially in counties using VAT. The logic of VAT is simple and similar in all countries using VAT. But the USA does not use VAT, it uses sales tax, with complex rules varying from state to state.

[David Bruchmann]

On 8/19/15, Ossi Viljakainen <arju...@gmail.com> wrote:
>
>
> On Tuesday, August 18, 2015 at 4:25:03 PM UTC+2, David Bruchmann wrote:
>>
>> Taxes are quite complicated.
>> In Germany for common products are 2 different taxes on common products:
>> either 7% or 19%.
>>
>
> Yes, these are VAT. (MvSt.) There can be one, two or more VAT categories
> depending on country.

Concerning Germany it's "Mehrwersteuer" / MwSt. that's right.
Some stores advertise selling "without MwSt" but sure they have to pay
taxes and just reduce the price by 19% and have to pay and calculate
MwSt. from the reduced price.
Concerning other countries I've no knowledge.

>
> Finland has 3 + tax free:
> 1. Standard rate 24% (goods)
> 2. Reduced rate I 14% (food & restaurants)
> 3. Reduced rate II 10% (books, pharmaceuticals, public transport, cinema,
> newspapers)
> 4. VAT Free 0% (doctor, dentist, hospital, insurance, lottery)
>

Ok, that can be solved by tax categories I think. Concerning Germany I
know that any store has to be able to calculate different categories
depending on the product. So it should be possible to assign a default
category and the option to change that to further categories. VAT Free
could be solved by a dummy category with 0% taxes.

>
>> For some higher taxes like for Tobacco and Patrol Products I don't know
>> how it's calculated at the POS. In general it's possible that it's
>> calculated at the POS with 19% but with a different value at a B2B point -
>>
>> honestly I just don't know.
>>
> Furthermore there existed some special tax for salt which was abolished but
>
>> it had to be expected perhaps that resembling taxes still exist in other
>> countries,
>>
>
> Tobacco tax, alcohol tax, sugar tax etc taxes are not POS taxes. They are
> not calculated at POS. They are added to the price at point of manufacture,
>
> and part of the product price throughout the retail chain. Only the
> manufacturer pays the tax to the government.
>

Ok, that's not part of POS, clearly.

>
>> As long as you plan to include an option for different unlimited
>> tax-classes I don't see a problem here, but concerning the abolished
>> salt-tax I don't know if there have been even 2 taxes on one product.
>>

This point is still open, is there anywhere a requirement to assign 2
or more taxes to a product or service?

>
> In USA they have very weird and complex, illogical tax system, as mentioned
>
> earlier, tax depends on which product category, quantity of sale, in which
> state you are located, whether on reservate or private land, on the street
> widht, the house number, the strenght on wind, the tide and amount of
> sunshine your shop gets :D
>
>
>> As far as I see a configurable option would be nice, so even for US never
>>
>> had to be programmed anything extra.
>>
>
> Most of the wold uses tax included prices. This is true specially in
> counties using VAT. The logic of VAT is simple and similar in all countries
>
> using VAT. But the USA does not use VAT, it uses sales tax, with complex
> rules varying from state to state.
>
>

Question is if the US-Model could be solved with taxes and
tax-categories, both in an own table each - in the same kind like the
EU-Model. I never expect a pre-configuration for each state. I think
even the name and the laws in background are different perhaps the
facts keep the same: product -> price -> tax-class(es?) -> tax(es?)
Display and Print can be solved by Templates where the general name
for the tax can be adjusted (VAT, sales tax, whatever ...) or directly
taken from the database.

Talking about Templates, there is still the question if these should
be optionally implemented in several languages. In some countries are
several official languages (i.e. Tunesia: Arabic and French) and some
like to offer an international version perhaps for foreigners (i.e. in
English or Spanish).

I admit about all the different taxes I've not much knowledge, but
with the proposed database-model I suppose there could be implemented
nearly every kind of tax. For the case that for one product exist
several taxes like described above, tax-groups still could be added
where these different taxes are grouped to required combinations.

Sure it can't be expected from a programmer to include all taxes for
many countries especially if it's complicated and very various.
Nevertheless the most options have to be configurable anyway and
concerning US I don't see a problem yet to make the configuration for
any state.

If there are modules which just load preconfigured taxes in the
database then I don't mind about modules, but the general mechanism
can be handled by only one modul I suppose. In the moment I don't see
a reason for further functions yet.

Best Regards,
David

[ferr...@gmail.com]

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.

It will have a button to add payments registered as lines on it:

    - journal
    - amount

with change line created on cash journal.

Could there be a way to show cash change? (the difference between the amount to be paid and the money which is received by the cashier). It's simple math, but still useful for some people.

Tax included: yes, please.
Showing the amount of tax on the receipt: yes, please?.
A nice little greeting (or some other stupid stuff on the receipt): pleeeease???

(yes, I know all of this is probably already considered. Success with the module. A lot of us will be really grateful. No need to reply).

[Cédric Krier]

On 2015-08-19 00:06, ferr...@gmail.com wrote:
>
> >
> > 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.
> >
> > It will have a button to add payments registered as lines on it:
> >
> > - journal
> > - amount
> >
> > with change line created on cash journal.
> >
> Could there be a way to show cash change? (the difference between the
> amount to be paid and the money which is received by the cashier). It's
> simple math, but still useful for some people.

Yes I was think that the wizard to create payement lines will ask
journal and amount and display change (computed field) on the fly.

> Tax included: yes, please.
> Showing the amount of tax on the receipt: yes, please?.

Yes not complicated indeed.

> A nice little greeting (or some other stupid stuff on the receipt):
> pleeeease???

It will be a standard report.

[Udo Spallek]

Hi,

Sun, 16 Aug 2015 23:39:09 +0200
Cédric Krier <cedric...@b2ck.com>:
> ...

>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

> ...
there are some other considerable requirements I heard about
with cash register drawers (e.g. POS terminals in a supermarket):

- Shift Change
When the employees change shift, the former employee makes
a cashing-up. Which means she counts manually the amount of money in the
cash register drawer and compares the number with the ending balance of
her shift.
The new employee brings a new money bag or takes the former one. Before
he starts, he counts the money in his bag and types the number in the
cash register drawer as starting balance.

- Cancellation
One employee can only enter products and quantities, but can not
correct or cancel them. For cancellation there is another employee
needed with the cancellation-key.

- Standalone System
A POS System should work even when there is no network connection to a
backend or database. If a system fails it should be easily
replaceable by a new system. All needed data should be considered local
for the system and synchronised on demand.

- No Stock Limitation
If a product is out of stock but a customer has found one to buy, it
should be possible to sell it, even it is out of stock.

Regards
Udo Spallek
--
_____________________________
virtual things
Preisler & Spallek GbR
München - Aachen

Windeckstr. 77
81375 München
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56

in...@virtual-things.biz
http://www.virtual-things.biz

[Dominique Chabord]

2015-08-19 11:20 GMT+02:00 'Udo Spallek' via tryton <try...@googlegroups.com>:
> Hi,
>
> Sun, 16 Aug 2015 23:39:09 +0200
> Cédric Krier <cedric...@b2ck.com>:
>> ...
>>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
>> ...
> there are some other considerable requirements I heard about
> with cash register drawers (e.g. POS terminals in a supermarket):

Supermarkets use cashiers not POS. Maybe just a matter of name, but I
don't think we are considering cashiers here.

>
> - Standalone System
> A POS System should work even when there is no network connection to a
> backend or database.

This is not my understanding. Cashiers are another story, there are
plenty around, no need to reinvent in Tryton. I know many shops using
POS and no cashier.

[Dominique Chabord]

My mistake : seems the word cashier means the user of the cash
register, not the machine itself. I meant cahier's deck or cash
register.

[Udo Spallek]

Wed, 19 Aug 2015 11:34:00 +0200
Dominique Chabord <dominiqu...@sisalp.org>:

>2015-08-19 11:20 GMT+02:00 'Udo Spallek' via tryton
><try...@googlegroups.com>:
>> Hi,
>>
>> Sun, 16 Aug 2015 23:39:09 +0200
>> Cédric Krier <cedric...@b2ck.com>:
>>> ...
>>>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
>>> ...
>> there are some other considerable requirements I heard about
>> with cash register drawers (e.g. POS terminals in a supermarket):
>
>Supermarkets use cashiers not POS. Maybe just a matter of name, but I
>don't think we are considering cashiers here.

You are right, but I don't meant the all in one cashier systems. I meant
setups like this, based on a PC platform with POS specific hardware
(from Tryton GSOC ):
https://www.youtube.com/watch?v=uzi-N4-aYtQ

Regards Udo

[Antonio Roncero]

El domingo, 16 de agosto de 2015, 22:39:48 (UTC+1), Cédric Krier escribió:

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.

Also for me, a POS should work with tax included price as bases, it
should not create shipments nor invoice by default.

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.

¿? maybe "pos device" and each machine has its own order number (In Spain order numbers are a special type (simplify) of invoice so they have to be consecutive without gaps)

 

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

¿? Cash regiter for each POS device with an inital and close balance to knows how many money "should be"

 

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).

 

I think (a very very personal opinion because I hate javascript ) is "better" a desktop one with a sync method to work offline

 

Did I forget something? Or do you see a use case that could not be
supported?

as I said, I think the concept of POS device and cash register

 

Thanks,