Raffle Software Status.

[SteveColes]

The following programs have been ported to vb4 and are now availble for use. Please feel free to take them for spin. The raffle system is in test so you will not create any real transactions.

Raffle Admin
Purchase Raffle Tickets
Raffle Sales Report

In addition a new program was created
Enter Manual/Mail In transactions - To be used by person(s) receiving mail In purchases
If we have an internet connection at the picnic, we can use this to also log in, in person sales.

The system was enhanced to allow several new functions.
we will be able to keep track of, and administer multiple raffles. Not run more than one raffle at a time, but rather save all the info for all our raffles for as long a s have space and need.
In addition to each sale for each raffle, there will be a single record for every raffle ticket sold and that will be point back to the sales transaction that the number was sold in.

The Sales report is does not yet support multiple raffles, I will do that a bit later, but the addition of being able to enter a ticket number in a particular raffle and get the complete sales report will be added before the drawing.

Thanks to all of you for being so patient with me.

 

[McRabbet]

Steve,

Thanks for all your work on this!

The Manual/Mail-in process does not have any submit button and does it need both a field for Number of tickets and Money tendered since each ticket is $5 (If the Money field is not a $5 multiple, couldn't the process round the number of tickets down to fully paid ones -- e.g., enter $24 and only 4 tickets are generated).

The Sales report cannot stay online during the raffle and I really think it and all the others need to have permissions set for the minimum number of people (e.g., Barbara, you and me) or we would need to prohibit any technical team members with Admin access from entering the raffle. The Raffle Admin module is very potent and could really mess us up if someone hits the Delete button.

Just thinking...

 

[ehpoole]

The following are my thoughts on the points Rob has kindly brought up

Delete Button
Actually, an easy safety mechanism for the "Delete" button would be to disable it unless the Raffle were first "closed". This way deletion becomes a two step process. This should be an adequate safety against accidental deletion.

If alternate entry is to be used for Picnic:
I had not really looked at the alternate entry mechanism -- especially from the perspective of Picnic sales -- until now (sorry Steve). For picnic sales, I feel we should add a field that is preloaded with the *expected* first ticket number. Then require the issuer to verify this ticket number is the first in the series. If for some reason there is a discrepancy then we should allow the entry of a new starting ticket # -- along with a safety check upon submission that ensures the new starting number does not conflict with any existing sales (i.e. it must be greater than the last known ticket issued). This would allow recovery in the event someone tears off the wrong number of tickets at the picnic.

Upon submission via the alternate method, I feel there should be a screen that displays the starting an ending numbers in the series -- which would help prevent errors at the picnic.

None of these are a concern so long as *real* tickets are not be issued at the time of sale. Electronic-only transactions should already be protected by internal checks to ensure that no ticket duplication takes place. It is when we introduce the human element at the picnic that the greatest protections become necessary because people do sometimes tear off or issue the wrong number of tickets and there need to be mechanisms to reduce the consequences from such should that happen -- as well as to help in the recovery from such mistakes.

It might be easier(?) to add an extra "picnic mode" to the raffle which would activate the added human checks discussed above given that they are both unwarranted and unwanted during electronic-only transactions.

With respect to Rounding transactions
That would be more of an internal accounting issue. Realistically, we have to trust our Treasurer to handle financial transactions responsibly. At most, a warning could be issued with respect to the discrepancy (I would do so in JavaScript for simplicity so it would add not added complexity to the Raffle plugin).

Sales Report
Realistically, for the Treasurer to do their job I suspect the Sales Report needs to be available during the Raffle. It would, however, probably be wise to strip the Ticket #'s from the report so long as the raffle is live. From an accounting perspective, you don't ever want to cut off whomever is responsible for accounting from access to sales reports.

There is one concern with respect to stripping Ticket #'s entirely and that is the following: If a user fails to receive their Ticket #'s via email (for whatever reason) do we have another mechanism in place that can re-send those Ticket #'s (preferably without exposing them)? As an admin I know we have active users with bad email addresses on record, so this issue will likely crop up.

 

[cskipper]

This discussion, as with many other technical ones make me very thankful for you guys - it is certainly not something I understand. Thanks for all of the hard work ya'll have put into the site! :eusa_clap

 

[McRabbet]

We must assume that we will not have an internet connection at the Picnic. First, there is not a critical need to have the ticket sales at the Picnic in the databas, but there is a critical need that the ticket numbers sold are in sequence with the online and manually entered sales before the event and that actual tickets are entered into the Pick Jar as sold. For the past two picnics, I have used an EXCEL spreadsheet which works very effectively. It requires entry of the next ticket number in sequence after the close of online ticket sales into a specific cell and then as each cash sale is made from attendees, we enter their name and email address and the number of tickets they are purchasing. The spreadsheet displays the sequence of new ticket numbers and the cash conveyed. We then tear off the tickets from the roll and place them in the Pick Jar. It is quick and accurate and provides a solid record of purchases. At the time of the drawing, we use the Sales report along with this spreadsheet to quickly find the name of each ticket winner as they are drawn. I even created a section in the sheet to record each winner using simple entry (we used a second team of people to record ticket numbers and stated winners as a cross reference and also writh the Lot# and personson name on the back of each ticket when selected).

 

[SteveColes]

Delete Button
Actually, an easy safety mechanism for the "Delete" button would be to disable it unless the Raffle were first "closed". This way deletion becomes a two step process. This should be an adequate safety against accidental deletion.

First and most important, the delete button only deletes the header record for a raffle. It does not delete the sales records or ticket number records. They can only be trimmed by going into the DB itself. If the a raffle is the current raffle, it will not delete it at all. He gives you an error message.

The Sales report cannot stay online during the raffle and I really think it and all the others need to have permissions set for the minimum number of people (e.g., Barbara, you and me) or we would need to prohibit any technical team members with Admin access from entering the raffle. The Raffle Admin module is very potent and could really mess us up if someone hits the Delete button.

Just thinking...

Don't think :rotflm:

I don't understand this at all. This is the same Sales report that was used last year. I have not changed any functionality.

The sales report must be available for whoever needs it. It is accessible only to BOD and Admins, it could be restricted further, but if you do that you are depending on me to be available if there is an issue. Not a good idea. Also, I have used exactly the same permissions as were used last. year

Finally and most important, the sales report is a "passive" tool. It does nothing that can influence the outcome of the raffle. it doesn't pick tickets. if barbara wants, I can easily blank out the ticket numbers.

There is one concern with respect to stripping Ticket #'s entirely and that is the following: If a user fails to receive their Ticket #'s via email (for whatever reason) do we have another mechanism in place that can re-send those Ticket #'s (preferably without exposing them)? As an admin I know we have active users with bad email addresses on record, so this issue will likely crop up.

Stripping information from the report, does not strip the numbes from the DB. Also, each sales record points to a seperate record for each number purchased in each sale. Please look at the DB structure, to what I mean.

If alternate entry is to be used for Picnic:

I haven't dealt with that issue at all, because we have time. I want to see how this all falls out in use for the first week or so before I make any changes or added functionality for the picnic.

Now finally, how manual ticket (mail in) works from the user standpoint is really up to Barbara. She is the one who is doing the actual entry and is also doing the QuickBooks accounting, the we have to meet her and basic accounting needs. If Rob or someone else is doing the work then they can tell me how it should be done. Period.

Unless, there is a major debug, I will NOT make any real coding changes to the programs today. That is recipe for the accidental introduction of major bugs. Only those changes needed for mail in program will be made, if requested by barbara.

I will, however, explain the way mail in program works and why. But in a different thread.http://www.ncwoodworker.net/forums/...ussion-mail-ticket-purchases-entry-44293.htmlhttp://www.ncwoodworker.net/forums/...ussion-mail-ticket-purchases-entry-44293.html This thread has enough issues in it.

 

[ehpoole]

Steve

I think you misunderstood what I was suggesting with respect to stripping Ticket #'s. I was referring to the possibility of stripping them from the REPORT (i.e. simply not printing them for an active raffle).

I mention this because I could see someone possibly arguing a conflict of interest on the part of the individual performing the drawing if the numbers were known ahead of time (less so if known by others).

 

[SteveColes]

Steve

I think you misunderstood what I was suggesting with respect to stripping Ticket #'s. I was referring to the possibility of stripping them from the REPORT (i.e. simply not printing them for an active raffle).

I mention this because I could see someone possibly arguing a conflict of interest on the part of the individual performing the drawing if the numbers were known ahead of time (less so if known by others).

Actually you misunderstood me.

But please remeber the person pulling the numbers has to have who has what numbers so that we can see who won. Most people don't even bring there numbers with to the picnic.