gregorj Posted January 26, 2008 Posted January 26, 2008 Without using a find routine, how would the syntax of my calculation look for the following solution? A member has a bar-coded 5 digit unique membership number which is scanned in which becomes a transaction, date and time stamped. Call this 5 digit field Member_ID. We must keep track of this Member_ID during the day. He can only use the number once a day. If the card is scanned again later the same day, we must be alerted at the time of the rescan via a message to the operator. "Member has already used this card today. Allow? The key is to relate his usage to todays date. If he uses it tomorrow, its fine as long as he only uses it one time. This solution is in Kiosk mode...no keyboard...just a touchscreen. Not that that should make a difference. Thanks for your help Greg
David Jondreau Posted January 26, 2008 Posted January 26, 2008 I assume you want a calc in the "swipe" table. You'll need to know what today is. A global (Current Date) in the Swipe table set on start up each morning to Get(CurrentDate) would do the trick. And the timestamp of the swipe in date format, a calc field with a date result: Date = GetAsDate(timestamp). Then you make a self join between two TOs of the Swipe table. The criteria are SWIPE::Member ID = Swipe|SWIPE_Check::Member ID SWIPE::Current Date = Swipe|SWIPE_Check::Date You calc is then: Already Swiped = not isEmpty (Swipe|SWIPE_Check::Primary ID)
gregorj Posted January 26, 2008 Author Posted January 26, 2008 I really tried to follow solution and set it up the best I could but with no success. I am just not advanced enough to put it all together. Let me tell you what I have so far: Added a Table called Swipe with 5 fields; Current Date Date Global Auto Enter Calc CurrentDate = Get CurrentDate Member-ID Text Already Swiped Text Primary-ID Text Timestamp Date Added a table called Swipe_Check with 3 fields; Member_ID Text Date Date Timestamp Date "Relationships" shows both tables with Member_ID relating to Menber_ID and Date relating to CurrentDate From this point on their are just too many ways I can get this wrong and I've tried a lot of them. How do I get a calc in the swipe table like the one you mention in your last line? You mention a calc field with a date result Date = GetAsDate(timestamp) This gives me an error massage "The specified field cannot be found" Wow, does flagging if the member uses his card more than once in one day have to be this involved? Many thanks for the time you spent on this. I need this solution real bad so please be patient with me. Thanks, Greg
comment Posted January 27, 2008 Posted January 27, 2008 Aren't you making this more complicated than it needs to be? See if the attached makes sense: Swipe.fp7.zip
gregorj Posted January 27, 2008 Author Posted January 27, 2008 This looks very promising. I have a button that is pushed after the member-ID is scanned in. This is touchscreen POS. The button goes to a script that is called MemberScan which goes thru a series of tests including Renewal status, Senior status, Fees schedule to apply and more. Based on what you show here, how would you script your segment so that when the card is used a second time on the same day an insert text could be entered in my ProfileMessage Field such as ;"This member number has already been used today! Press 1 to allow. Press 0 to reject." Thanks' Greg
comment Posted January 27, 2008 Posted January 27, 2008 I don't see the need for so much scripting. As soon as you enter the member's unique ID, you can show all the required information through relationships. I have modified the demo slightly to emphasize which info is coming from where. Swipe.fp7.zip
gregorj Posted January 27, 2008 Author Posted January 27, 2008 I think this has to be generated by a script. When the cashier is finished with the last customer, (this is a golf course), the cursor is left at the Member-ID field for new input (the next customer). The reason we want to flag the card if it is used again today is that their are deadbeats even amoung golfers and it is not above them to "loan" their card to another player so he can play at a reduced members rate instead of a walk-on. So the card is scanned and the member-ID is inserted in the field. The cashier hits enter which is a scripted button that actually does about 6 different things and has at least 3 alerts that could be posted to the Profile Message field. This is all accomplished before the next scripted button it hit based on what the golfer wishes to do. Looking at your particular solution I see where its close but I'm missing something. If the card is swiped at the Main table and the ID exists in the entries table then a "Your a bad boy" message appears. However, if the card is swiped at the Main Table (mine is called Transactions) and this is its first use today, as far as I can tell, this transaction history never gets to the entries table. If, on the other hand, we use the entries table to generate the transaction, although this was the first time the ID number appeared in the table, the badboy message is generated. It also needs to be a script because the Transaction screen is loaded with buttons and text boxes. Not much room for adding stuff. Also we need to give the cashier 1 button to hit to refuse to allow the transaction (Clear Button) or allow the transaction to continue when the next button is hit. I'm sorry to be so long winded but I know there is usually more than one way to get the solution. Thanks Greg
comment Posted January 27, 2008 Posted January 27, 2008 My demo does NOT have a procedure for creating a new entry. This would indeed need to be scripted. Depending on your exact workflow, the same script could branch off according to the situation. But the situation is clear immediately following the swipe, before any script has run.
gregorj Posted February 6, 2008 Author Posted February 6, 2008 Sorry for the delay in getting back to the Forum. I was away. To respond to your solution, I have attempted to implement it but the specific nature of the task needs a solution that immediately warns the cashier thru a beep and a text message in the appropriate field that this member's card has been used earlier today. Again, a five digit barcode is scanned into the Customer_ID field which includes a "return". I have one script that immediately checks if the member has renewed his/her membership this year, that checks if the "Student must now renew as a "Regular" member, that checks if the "Regular" Member now qualifies as a "Senior" member at a reduced rate, that checks if the member qualifies for any "Specials and finally checks to see if the member is already on the course. This all happens in a flash and unless the transaction is part of a script that is interupted by a beep, and a text notification and a halting of the script, the cashier will continue to touch a transaction button before he becomes aware that there is a passive indication on his touch screen that he just screwed up. I need help in just the "already used card today" part on the script. My transactions table records the member number as part of a new record request so any script syntax would have to ignore the first appearance of that unique number for this date and only flag the cashier for the second appearance. Data is this table is erased at the end of the day so I don't even need a date check. Thanks once more for your help. Greg
comment Posted February 7, 2008 Posted February 7, 2008 I have a feeling we are mis-communicating here. All I wanted to show was a simple data structure that allows you to see all the required information immediately after swiping the card, and before anything else has happened. If you want to use this information in a script instead of (or in addition to) viewing it onscreen - well, it's already there, so you certainly can. For example, you could run this in your script: If [ EntryToday::EntryID ] Beep Show Custom Dialog [ "Card already used today" ] # MORE STUFF TO DO WHEN MEMBER TRIES TO ENTER A SECOND TIME End If # CONTINUE ... Using a series of If, Else If and Else steps, you could check all the conditions one by one, and, if appropriate, create a new entry record. This is more a matter of user interface, on which I am not going to advise you.
Recommended Posts
This topic is 6193 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now