ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BJ Freeman <bjf...@free-man.net>
Subject Re: Ofbiz for restaurants - please advise
Date Sat, 15 Sep 2007 06:16:48 GMT
I have been chunking away at Restaurant from some software i wrote in
cobol in 84.

The concept is a chain of restaurants.

the actual menu separate Catalog with BOM for dishes, that eventually
become products.
This allows the manufacturing to be implemented for ERP and kitchen
displays of preparation.

there is also a catalog that is used by the chefs or restrauant manage
to order supplies, that does not show up on the catalog for the Item
sold to the public.

for some restaurants They have terminals at the table for the customer
to  select menu items. this is a modified Ecommerce site. Some terminals
would have cc swipes and the cc processing would happen like and e
commerce site.

At this point then the POS is more a reconciliation for payment, and
change order.

the order in most cases would be comp by the restaurants manager in case
of bad service. here the pos would be used to recall the order.

You also have to reconcile orders that are walked out on and no payment
is made. The POS is used as a login and waitress, orders review for a shift.

You then need localization for the restaurant's flavor Like Mexican,
chinesse, and English, depending on the clients.

clearchris sent the following on 9/14/2007 9:44 PM:
> I missed a great thread.  Here's my 2c on the POS issues that have been
> brought up.
> 1)  Touchscreen:  This is handled by the OS and is basically translated into
> mouse clicks.  I haven't yet seen a pos web application that would work well
> with a touchscreen, because touchscreens aren't exact like a mouse.  Large
> buttons are pretty much a requirement.  I would also be *very* hesitant to
> do anything that would give anything (the browser) control over button
> location, as changes in layout or presentation will directly affect waiter
> speed with the POS.  Go watch a waiter at a busy bar.  Those guys fly
> through the menus, because they remember where all the buttons are.
> 2) Handling group/customer orders, aka split checks.  The best way I have
> seen this handled in a POS system is the table is initially grouped
> together.  At any point, the check can be split, which pops a new screen
> where the existing order items can be distributed to new orders.  This
> ensures that order items aren't lost during the splitting and allows for
> quick creation of the new orders.
> 3) To edit orders.  Orders are editable in the current POS system.  I would
> look at the Load/Save a Sale functionality put in by JLR recently.  IMHO,
> it's not perfect, but it's 80% there, there just needs to be some tweaking
> of the business rules.  This functionality is closely related to the ability
> to associate orders to tables.
> 4) To visualize tables, seats, to do table reservations.  Visualizing
> tables, IMHO would be pretty easy.  You would need to a) create a
> representation of the restaurant and tables in XUI, and b) have a way of
> associating orders to tables.  The rest of the functionality could be pretty
> much cut and pasted from the Load/Save a Sale feature.  I haven't given much
> thought to table reservations, so I'll defer on that one for now. 
> 5) To enter the registered customers for order payments.  Is having
> "registered customers" part of a loyalty program?  Is this essentially a
> patron "running a tab"?  I'm not sure of the use case in this scenario.
> 6) To do Returns.  Returns?  Returns don't exist as "returns" in a
> restaurant context AFAIK.  Is this something sent back to the kitchen to be
> fixed?  Is this a monetary credit because of a problem?  If it's a monetary
> discount to the order, this exists today in POS.
> 7) The products should come dynamically from categories and catalogs, like
> in order manager (especially as ecommerce).  I agree with this completely,
> and is how I'm handling item configuration.  Adding this functionality could
> be done with a medium amount of effort.
> Chris Lombardi

View raw message