puzzledom in a restaurant database

Hello everybody,

I am making a db for recording ordered dishes for kitchen and the billing in
a restaurant. There is one problem. Rarely but it happens, two customers
sharing one table, for example Table No.1, order independently their own
food, then comes the puzzledom, the db can not manage to accept the two
different orders from the same table at this time.

I have been trying very hard, but so far can not find a solution. Can
someone help? Thanks in advance.

Paul

re: puzzledom in a restaurant database

Paul T. Rong wrote:
[color=blue]
> Hello everybody,
>
> I am making a db for recording ordered dishes for kitchen and the billing in
> a restaurant. There is one problem. Rarely but it happens, two customers
> sharing one table, for example Table No.1, order independently their own
> food, then comes the puzzledom, the db can not manage to accept the two
> different orders from the same table at this time.[/color]

Then you need to make a modification so it can accept two different orders.

You may need to structure your tables to
Table1#
Order1#
Item1
Item2
Order2#
Item1
Item2
Item3
etc

Either that or create a field to put in a sequence number.
Ex: Order1 Seq 1
Items ordered
Order1 Seq 2
Items ordered

Which is basically the same as the first example. You can have a party
of 4 and have 4 separate bills. So...you might have to modify the code
and structure slightly.
[color=blue]
>
> I have been trying very hard,[/color]

In order to make life easy for yourself, when planning/building a
program try to get as much info you can prior to coding and then build
your code with extensibility into it. Practice makes perfect.

but so far can not find a solution.

There are as many solutions as you can dream up. I find sometimes it is
best to walk away from the computer, eat a candy bar, chat with someone,
get the mind off the problem. Oftentimes the solution will come when
you are not so focused you can't see the forest from the trees. I'm
sure there are many programmers that have woken up out of a dead sleep
with the solution to a problem.

Can[color=blue]
> someone help? Thanks in advance.
>
> Paul[/color]

re: puzzledom in a restaurant database

"Paul T. Rong" wrote
[color=blue]
> I am making a db for recording ordered
> dishes for kitchen and the billing in
> a restaurant. There is one problem. Rarely
> but it happens, two customers sharing one
> table, for example Table No.1, order
> independently their own food, then comes
> the puzzledom, the db can not manage to
> accept the two different orders from the
> same table at this time.[/color]

Then you have a basic logic problem -- you need to go back to your design,
because you must be using the table's identity in some way that you
shouldn't. Your orders/billing will have to be by customer, not table. That
could be, however, "position at table" to identify customer/order. If you
have a party at the table where clearly one order/bill is needed, you can
arbitrarily select a "position".

Restuarant software is a highly competitive business; there are some
well-established, well-thought-of products. I know this from brief
participation in an Access software project for a national chain quite some
years ago. It's not, you might say, "as simple as it seems". If this is for
your own restaurant, you might want to do some looking around -- it is often
more economical to buy than build. If not, best of luck with your project.

Larry Linson

re: puzzledom in a restaurant database

Hi Salad,

That is the best reply I've ever got. Thanks a million.

Paul

"Salad" <oil@vinegar.com>
??????:qxi9d.5329$UP1.413@newsread1.news.pas.earth link.net...[color=blue]
> Paul T. Rong wrote:
>[color=green]
> > Hello everybody,
> >
> > I am making a db for recording ordered dishes for kitchen and the[/color][/color]
billing in[color=blue][color=green]
> > a restaurant. There is one problem. Rarely but it happens, two customers
> > sharing one table, for example Table No.1, order independently their own
> > food, then comes the puzzledom, the db can not manage to accept the two
> > different orders from the same table at this time.[/color]
>
> Then you need to make a modification so it can accept two different[/color]
orders.[color=blue]
>
> You may need to structure your tables to
> Table1#
> Order1#
> Item1
> Item2
> Order2#
> Item1
> Item2
> Item3
> etc
>
> Either that or create a field to put in a sequence number.
> Ex: Order1 Seq 1
> Items ordered
> Order1 Seq 2
> Items ordered
>
> Which is basically the same as the first example. You can have a party
> of 4 and have 4 separate bills. So...you might have to modify the code
> and structure slightly.
>[color=green]
> >
> > I have been trying very hard,[/color]
>
> In order to make life easy for yourself, when planning/building a
> program try to get as much info you can prior to coding and then build
> your code with extensibility into it. Practice makes perfect.
>
> but so far can not find a solution.
>
> There are as many solutions as you can dream up. I find sometimes it is
> best to walk away from the computer, eat a candy bar, chat with someone,
> get the mind off the problem. Oftentimes the solution will come when
> you are not so focused you can't see the forest from the trees. I'm
> sure there are many programmers that have woken up out of a dead sleep
> with the solution to a problem.
>
> Can[color=green]
> > someone help? Thanks in advance.
> >
> > Paul[/color][/color]

re: puzzledom in a restaurant database

Hi Larry,

Thank you for you comment. Obviously my design has problems, logic or
whatever. I am working with it. Thanks for advise for the restaurant
software. The software is for a friend. So for him and me it is something
more friendship than a product. But I fully agree with you, that the
restaurant software is not simple at all and very often it is more
reasonable to buy than to build.

greetings from Bratislava, Slovakia

Paul


"Larry Linson" <bouncer@localhost.not> дÈëÏûÏ¢ÐÂÎÅ
:pJi9d.8509$Sl2.3894@trnddc09...[color=blue]
> "Paul T. Rong" wrote
>[color=green]
> > I am making a db for recording ordered
> > dishes for kitchen and the billing in
> > a restaurant. There is one problem. Rarely
> > but it happens, two customers sharing one
> > table, for example Table No.1, order
> > independently their own food, then comes
> > the puzzledom, the db can not manage to
> > accept the two different orders from the
> > same table at this time.[/color]
>
> Then you have a basic logic problem -- you need to go back to your design,
> because you must be using the table's identity in some way that you
> shouldn't. Your orders/billing will have to be by customer, not table.[/color]
That[color=blue]
> could be, however, "position at table" to identify customer/order. If you
> have a party at the table where clearly one order/bill is needed, you can
> arbitrarily select a "position".
>
> Restuarant software is a highly competitive business; there are some
> well-established, well-thought-of products. I know this from brief
> participation in an Access software project for a national chain quite[/color]
some[color=blue]
> years ago. It's not, you might say, "as simple as it seems". If this is[/color]
for[color=blue]
> your own restaurant, you might want to do some looking around -- it is[/color]
often[color=blue]
> more economical to buy than build. If not, best of luck with your project.
>
> Larry Linson
>
>
>[/color]

re: puzzledom in a restaurant database

"Paul T. Rong" wrote
[color=blue]
> Thank you for you comment. Obviously my
> design has problems, logic or whatever. I am
> working with it.[/color]

It was not my intent to just criticize your design, nor to criticize you,
but to try to point out the _part_ of the design you should examine in order
to correct the problem. Without knowing the design, I just couldn't be more
specific.
[color=blue]
> Thanks for advise for the restaurant software.
> The software is for a friend. So for him and
> me it is something more friendship than a
> product. But I fully agree with you, that the
> restaurant software is not simple at all and
> very often it is more reasonable to buy
> than to build.[/color]

No, restaurant software can be more than a little complex, particularly (as
is, I am sure, always the case) when you and the user look at what you have
and think "This would be so much more helpful if it only had .... <some
feature you are thinking about>... and it ought not to be hard to add that."

It might be worth your time to do some research on commercial restaurant
software to see what they and their customers consider to be the important
things to include, and to see how they have handled those things (from an
external or user interface point of view).

Larry Linson
Microsoft Access MVP

re: puzzledom in a restaurant database

Paul T. Rong,
A restaurant is synonymous to a manufacturing plant in terms of the business
processes. An order comes in for a finished good, inventory is consumed to
produce the finished good, the finished good is delivered to the customer
and paid for. When tracking orders (I missed the beginning of this, so
forgive me if I am repeating what has been already said), you have to track
per seat rather than per table. Seat 1 at Table 1 ordered the steak
special, rare, sauce on the side, sub vegetable for example. You already
see the problem with tracking orders per table.

"Paul T. Rong" <etjsk@hotmail.com> wrote in message
news:ZVB9d.364842$vG5.131184@news.chello.at...[color=blue]
> Hi Salad,
>
> That is the best reply I've ever got. Thanks a million.
>
> Paul
>
> "Salad" <oil@vinegar.com>
> ??????:qxi9d.5329$UP1.413@newsread1.news.pas.earth link.net...[color=green]
>> Paul T. Rong wrote:
>>[color=darkred]
>> > Hello everybody,
>> >
>> > I am making a db for recording ordered dishes for kitchen and the[/color][/color]
> billing in[color=green][color=darkred]
>> > a restaurant. There is one problem. Rarely but it happens, two
>> > customers
>> > sharing one table, for example Table No.1, order independently their
>> > own
>> > food, then comes the puzzledom, the db can not manage to accept the two
>> > different orders from the same table at this time.[/color]
>>
>> Then you need to make a modification so it can accept two different[/color]
> orders.[color=green]
>>
>> You may need to structure your tables to
>> Table1#
>> Order1#
>> Item1
>> Item2
>> Order2#
>> Item1
>> Item2
>> Item3
>> etc
>>
>> Either that or create a field to put in a sequence number.
>> Ex: Order1 Seq 1
>> Items ordered
>> Order1 Seq 2
>> Items ordered
>>
>> Which is basically the same as the first example. You can have a party
>> of 4 and have 4 separate bills. So...you might have to modify the code
>> and structure slightly.
>>[color=darkred]
>> >
>> > I have been trying very hard,[/color]
>>
>> In order to make life easy for yourself, when planning/building a
>> program try to get as much info you can prior to coding and then build
>> your code with extensibility into it. Practice makes perfect.
>>
>> but so far can not find a solution.
>>
>> There are as many solutions as you can dream up. I find sometimes it is
>> best to walk away from the computer, eat a candy bar, chat with someone,
>> get the mind off the problem. Oftentimes the solution will come when
>> you are not so focused you can't see the forest from the trees. I'm
>> sure there are many programmers that have woken up out of a dead sleep
>> with the solution to a problem.
>>
>> Can[color=darkred]
>> > someone help? Thanks in advance.
>> >
>> > Paul[/color][/color]
>
>[/color]

re: puzzledom in a restaurant database

Alan Webb,

Thank you very much. It helped me to clear my mind.

Paul

"Alan Webb" <knogeek@hotmail.com> дÈëÏûÏ¢ÐÂÎÅ
:e6qdnTho59uCzvbcRVn-gg@comcast.com...[color=blue]
> Paul T. Rong,
> A restaurant is synonymous to a manufacturing plant in terms of the[/color]
business[color=blue]
> processes. An order comes in for a finished good, inventory is consumed[/color]
to[color=blue]
> produce the finished good, the finished good is delivered to the customer
> and paid for. When tracking orders (I missed the beginning of this, so
> forgive me if I am repeating what has been already said), you have to[/color]
track[color=blue]
> per seat rather than per table. Seat 1 at Table 1 ordered the steak
> special, rare, sauce on the side, sub vegetable for example. You already
> see the problem with tracking orders per table.
>
> "Paul T. Rong" <etjsk@hotmail.com> wrote in message
> news:ZVB9d.364842$vG5.131184@news.chello.at...[color=green]
> > Hi Salad,
> >
> > That is the best reply I've ever got. Thanks a million.
> >
> > Paul
> >
> > "Salad" <oil@vinegar.com>
> > ??????:qxi9d.5329$UP1.413@newsread1.news.pas.earth link.net...[color=darkred]
> >> Paul T. Rong wrote:
> >>
> >> > Hello everybody,
> >> >
> >> > I am making a db for recording ordered dishes for kitchen and the[/color]
> > billing in[color=darkred]
> >> > a restaurant. There is one problem. Rarely but it happens, two
> >> > customers
> >> > sharing one table, for example Table No.1, order independently their
> >> > own
> >> > food, then comes the puzzledom, the db can not manage to accept the[/color][/color][/color]
two[color=blue][color=green][color=darkred]
> >> > different orders from the same table at this time.
> >>
> >> Then you need to make a modification so it can accept two different[/color]
> > orders.[color=darkred]
> >>
> >> You may need to structure your tables to
> >> Table1#
> >> Order1#
> >> Item1
> >> Item2
> >> Order2#
> >> Item1
> >> Item2
> >> Item3
> >> etc
> >>
> >> Either that or create a field to put in a sequence number.
> >> Ex: Order1 Seq 1
> >> Items ordered
> >> Order1 Seq 2
> >> Items ordered
> >>
> >> Which is basically the same as the first example. You can have a party
> >> of 4 and have 4 separate bills. So...you might have to modify the code
> >> and structure slightly.
> >>
> >> >
> >> > I have been trying very hard,
> >>
> >> In order to make life easy for yourself, when planning/building a
> >> program try to get as much info you can prior to coding and then build
> >> your code with extensibility into it. Practice makes perfect.
> >>
> >> but so far can not find a solution.
> >>
> >> There are as many solutions as you can dream up. I find sometimes it[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> >> best to walk away from the computer, eat a candy bar, chat with[/color][/color][/color]
someone,[color=blue][color=green][color=darkred]
> >> get the mind off the problem. Oftentimes the solution will come when
> >> you are not so focused you can't see the forest from the trees. I'm
> >> sure there are many programmers that have woken up out of a dead sleep
> >> with the solution to a problem.
> >>
> >> Can
> >> > someone help? Thanks in advance.
> >> >
> >> > Paul[/color]
> >
> >[/color]
>
>[/color]