[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[seul-edu] [Fwd: Cafeteria Software Specs]

This is what Jacques and I discussed and what he is working on.

Ryan

-- BEGIN included message

On Wed, 30 Aug 2000, Ryan Booz wrote:

> Jacques,
> 
> I've had some time to sit and talk with the cafeteria staff, and look at
> the things they had from the programs they were looking at.  I'll list
> the "needs" below and then give some thoughts afterward.
> 
> What the program should be able to do:
> 
> 1.  Keep track of individual student accounts with money
> credited/charged to them.  Also would be nice to be able to keep track
> of each date the student bought a lunch and what type it was (free,
> reduced, regular, or charged).
> 
> 2.  The pay schedule for lunches is somewhat complicated this year, but
> not hard to program I am thinking.  Basically there are five levels, and
> the computer needs to be able to "know" which it needs to do without
> intervention.  When we enter each student record there needs to be a
> place where we can check if they are FREE or REDUCED lunches.  If either
> of them are true, they either get charged nothing (sorry for stating the
> obvious) or $.40 if it's reduced - no matter what the grade level.  The
> other three levels are as follows: pay ahead (PA) - they pay 25 lunches
> or more at a time, point of sale(POS),  charge (CH)... and to make
> things more difficult, these prices are different for grades K-5 and
> 6-12.  Here are the costs.
> 
> K-5:  $1.10 (PA), $1.15 (POS), $1.20 (CH)
> 6-12: $1.25 (PA), $1.30 (POS), $1.35 (CH)
> Staff and visiting adult: $1.65
> 
> I don't know the best way to program this, but I guess it would be an
> if/then type thing on everything except CH, which could probably have a
> different button.  If there's money in the account it's POS.  If there's
> a tag associated with that name somewhere, then it's either FREE,
> REDUCED, or PA.
> 
> 3.  There needs to be some way to input different food that students by
> on the spot.  Now, this is where we aren't that picky right now, since
> inventory is still done by hand (although that's changing before the
> year is out!)  At the moment, if there was just a "key pad" kind of
> thing that was labeled "Extra Food" or something, which didn't even
> require them to enter a student ID, that would be best probably.  There
> are so many little price break-downs, that I don't think it would be
> worth making separate buttons for each item, or even a "$.25 Candy",
> "$.40 Candy" type of thing.  The only breakdown that needs to occur is
> extra money for MILK and extra money for anything else.  So if they
> could punch in $.50 and then have the option of that being added to the
> MILK total or the XTRA total, that would be perfect.
	So essentially, there's a generic "lunch" with the weird price
scale, xtra food, and milk?  That should do for now, and if you actually
get a cash register, we could break it down a bit more.
> 
> 4.  The ability to have a data entry screen.  When the students hand in
> money in the morning, someone does go through and credit it towards the
> accounts.  So if that could be easily done, maybe by grade since that's
> how the money comes in each morning, another plus!  Could this also be a
> place to make changes and corrections?
> 
> 5.  Lastly a place to call up reports.  The required ones would be stuff
> the cafeteria needs for their government reports.  They include:
> 
> Daily:
>     - Per grade totals of: Paid lunches (PA + POS), Free lunches,
> Reduced lunches, and then the total number of lunches for the day.
>     - Total student money, Total adult money, Total money.
>     - Staff totals money
>     - Total amounts on the following: Student lunch money, Staff/Adults
> lunch money, Milk money, Xtra money.
>     - Total Money
> 
> Monthly and yearly: Same as above only for month and year.
> 
> 
> Thoughts:
> First, if I've forgotten details, please let me know.  I've never had to
> give specs for something like this before.  Second, I really will help
> anywhere you think I can.  All of this stuff has been on my list, so
> even if it's taking what you have, and trying to make "updates" as the
> year goes on - I think as long as I can see the code, I'll be able to
> slowly pick things up.
> 
> Now, the only three things I don't have is student IDs, input devices,
> and terminal specs.  Here are my thoughts.  IDs can be anything you
> want.  Obviously if we end up going with a scanner or something for the
> input device of IDs, then a consistent numbering scheme would be best -
> heck even if we don't that would be good.  For computer IDs, we use
> initials followed by the two year graduation date.  (ACB02).  Something
> like this with numbers might work, but looks a little odd when you get
> to double digit numbers.  So for this years graduating class (2001)
> something like (0101, 0201, 0301....1801).  This would also be easier
> for someone to type (if that's how we input) than ABC02.
> 
> Input devices will be tied to the IDs mostly I think, at least right
> now.  I only mention this because of what others have said, that's it's
> possible at least.  I think we could round up the $300-$500 for this, if
> it's going to work.  Otherwise, I'm assuming it will be a combination of
> keyboard and mouse.
	I don't have any experience working with cash registers, although
I assume it would work with some fairly simple serial interface.  However,
the reason that I suggested the netscape route is because it's nice and
simple, and I think there's less that could go wrong.  Of course, nice and
simple means nice and simple for me, not necessarily for the cashier.
Hooking up a cash register would require more work, and probably a custom
program for the frontend, but it is certainly doable.  I think the best
thing to do is to start with a web-based frontend, and then if people
complain too much, to work on a custom, easier-to-use one.
	As for as IDs are concerned, I think the easiest thing to do is
just make a 32 character field, and let whoever is in charge decide
exactly how they want to code them.

> 
> Lastly the terminal discussion.  I'm all about having a Linux
> workstation, mostly because I know the reliability of it.  However,
> having it boot only into Netscape is something I don't have any
> experience in (I think I understand where this would be changed... in
> inittab I believe), but I've only ever changed a print server to boot
> Vterm 2 as a visible log.  Anyway, this is not something I have
> experience in and I'm thinking that would limit the usability of the
> system for other things.  One other thought I had, was making this a
> server of sorts (which I guess it would be already), and allowing any
> computer on the network to use the system.  This would be helpful for
> the office being able to enter money in the morning.  That way they
> don't have to go to the cafeteria to do it.   Of course passwords would
> have to be set up then so that students couldn't get in an credit
> themselves or see other student records.  Let's keep talking about this
> as you develop and come to a decision.
	I don't know if this is how you do it, but many people use a
graphical login program.  What happens is that X is started during the
boot procedure (by changing the initial runlevel in inittab to 5), and a
graphical login program is run in addition to the normal text-based ones.
These programs (such as xdm and gdm) are a lot more flexible than the
normal login program, because they let you choose a "session-type".  To
make netsape load up automatically, it's just a matter of creating a
custom session (which is just a shell script) and making it the default
for a particular user.  I've already done this, and it's very easy to
modify for different resolutions.  It also wouldn't limit the usability of
the computer, because only one particular user would have this special
default session.  All other users could login to a normal X session
(gnome, kde, etc.), or hit alt-fN to change to a text-mode login.
	There should be no problem making the system available on the
network.  PHP is designed to be used on a server, so it's just a matter of
ensuring proper security.

> 
> I think that's it.  I hope this isn't more than I let on.  I think I was
> pretty straight forward, but I never know.
> 
> I don't know what else to say but thank you.  I'm very excited to get
> working on this and seeing the reaction of school personnel to a "free"
> program.
> 
> Blessings to you.  Let me know of questions.
> Ryan Booz
> 

Jacques

-- END included message