I have written some application software in my time, mostly cash flow analysis, management
systems, analytical systems and so on.  My own beekeeping materials for my 15-20 hives
consists of a clipboard and some notes on paper that I prepare before and during the time I
"make my rounds."  I have attempted to put together a database application for my own use,
but it sits unused (see below). I have had some success in producing software for a professional
beekeeper of some 3,000 hives whose business is organized around pollination services.

When I examined commercially available beekeeping programs, I found that most of them are geared
toward the hobbyist, particularly those inclined to track very methodically as many variables as possible,
such as the last requeening date, the number of frames of brood, and so on.

This sort of information was not what my beekeeper client needed.  His staff knows how they manage
the health of the colonies; know how to spot a queenless hive, how to treat for varroa, when to pull
honey, and so on.  What they needed was a more overall management scheme to help accurately manage
when and where their "resources" were deployed, convey accurate information to their grower clients, and
provide helpful information to those clients as they prepare for the subsequent year.

My program is geared toward managing the location, crop, time on site and pollination fee for pallet sized
quantities of colonies.  It accomodates extra fees for moving colonies within a grower's site (you can
incur this fee numerous times, or you can log the fact that the bees were moved but the move was not
charged for), and you can incur special fees if the bees are left on site for a longer than normal period (if the
grower has a later crop and wants the bees to be on site after the primary crop has passed its bloom).
It summarizes where all of your bees are at any given time, how long they are on site, and generates
billing statements for each grower.  Each grower can have several locations, with one crop at each location, the pollination fee being different (if needed) per crop, in state and out of state. In addition to
billing statements, it will generate a "first of year" letter that goes to each grower, summarizing by crop just how many colonies he/she used, and how many days the bees were on site (working, presumably) for each crop.  The "first of year" letter goes out to help the grower determine his/her orders for bees the following season.

As Allen's msg indicated, the more complex the application, the steeper the learning curve, and the
less value the application potentially adds. This is particularly true if you design an application to include
every possible variant form of data imaginable. My software clients, beekeeper included, prefer "lean"
applications that are easy to use, deal well with fewer possible parameters, to more generalized highly
flexible environments that are cumbersome as well as being difficult to cross-train personnel for.

 For my own colonies, which generally do not move and do not generate pollination fees, I have
tinkered with a database application but it has yielded to paper notes that are prepared before, during, and after I make the rounds of my few small beeyards, making notes about splits, queens, varroa counts, and so on.

  The only working stuff I've written for my own use is something simple that has a table of products, sizes, and so on, that prints customer's bills for honey and other services, and does a nice summary of revenue for me when tax time comes.  I use it when I get an order and need an invoice, and later it is updated when checks come in.

C. Crowell
Bountiful Bees of Broad Street
Hightstown, NJ

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
-- Visit www.honeybeeworld.com/BEE-L for rules, FAQ and  other info ---
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::