I am in the process of building a e-commerce website for a small local grocery chain to allow their customers to order online and pickup at store. I will be integrating with the in-store POS system to pull the category & product data and push back the order data.
As I am new to Prestashop I am wondering if the following setup is possible out-of-the-box:
The POS system uses price zones which can be shared by stores (e.g. price_zone_1 is used by the 3 stores in San Francisco for pricing, price_zone_2 is used by 2 stores in Los Angeles for pricing).
The POS system have a pricezone_productprice table
product_id pricezone_id price
1 1 14
1 2 12
Then there is store_stock table
product_id store_id stock
1 1 98
1 2 45
And the store table has a pricezone foreign key that ties everything together
store_id pricezone_id
1 2
2 1
I need to have a similar setup on the Prestashop side to exchange data and display correct pricing and stock information for different stores.
Is such a structure/feature available out-of-the-box? If not are you aware of any module that might help with this? And finally if nothing is available how feasible do you think this is to develop under prestashop?
I explored multistore feature but as far as I understand that would not do what I am looking for as it separates order history, etc. I want customers to be able to see their order history from different stores in one page.
This might deserve an entire Override for Product Class with a Module. But honestly, you should better do a multishop website based on the zone you want to deliver, then ask the client when he enters the website.
It will cost you 10 minutes and fine tuning instead of hours of dev and lot's of debug.
If you still want to use a Module, just overide Product class and following methods : getPriceStatic and getProductPrice
NB : Another idea would be to consider price by ... country and tell each as a separate one. But this can be dangerous :).
This is a question about model design for SQL or SQLite.
Suppose you have some card game which has many reusable cards and the players make decks out of those card (e.g. MtG)
Naturally you do not want to make new instances of the cards for every deck that a user might create. That would have a lot of redundancy.
Thus there should be a "master" card (with all of its associated info).
My question is then, how to best integrate the cards (and quantity there of) in a given deck?
(I am not actually making this database, it just highlights the design of having a user having any number collections of multiple items in various quantities from some general stock).
Have three tables: One table has the data on the cards (name, cost, etc.). Another table has decks (deck name, creator, etc.). And another table has the cards in the deck (deck_cards) (linking card_id to deck_id with quantity).
EDIT: addendum: This is the same set up (and rationale) as the classic go-to example used in all database design primers: products, orders, and order-line-items. The only piece missing is "customers" (which could be added if you wanted to link decks to players or deck-builders).
I would imagine something like:
Cards - Table containing card details
Card_ID Card_Name Card_Dmg Card_Attribute Card_Health
123 Fire Mage 20 Fire 100
345 Water Man 6 Water 200
037 Earth Dwarf 10 Earth 150
Players - Table containing Player details
Player_ID Player_ForeName Player_Surname
1 Fred Smith
Player_Cards - Table detailing the players deck, with a new row for each card they own, e.g:
Player_ID Card_ID
1 123
1 345
1 037
I need help with the algorithms/ database design for my current working on web-based application (I apologize for the long question in advance)
Application description:
I am building a customer check-in station (it's basically just a monitor that displays a webpage and was connected to a scanner) where customers who come into an office (similar to a library) can scan their office ID card (it has an unique bar code on it) to check-in, customer information (First name, Last name, date of birth, check-in time...) will be sent/saved onto server and the office administrator will be able to see who is in the office right now and do stuff...)
When creating ID card for a new customer, the only information needed is: first name, last name and date of birth (customer can be any ages from kids to elder) => system will generate a unique bar-code (16 digits) and print out a new ID card (with only the bar-code on it)
Problem:
If a customer forgot/ lost their ID card or sometimes the card is too old so the bar-code can't be scanned, customer can type in their first+last name and date of birth into the check-in station then system will search for (first name + last name + date of birth) and determine whether that customer existing and check them in. But it is possible that there is more than one person who has same name + birthday:
- system then can display all matched people to screen but how can customer know which one is them self?
- or that situation can be avoided if system would not allowing customer who has same name and dob to be saved the to database in first place. But then the customer who came "second" will be very upset that he/she can not have a card :))
Edit:
How do I deal with this problem, I mean this is just a office so we can not ask for SSN or driver license ... the check-in process have to be simple and quick some of them maybe a kids who don't have any ID or phone (they will come with their parents/guardians) and many of them are older people (older than 70, or even 80) they can't even type that why the "ID card - scanning idea is here to help them - all they need to do is scan their card... (I don't think they ever can remember the "security question"), SMS verify will not work (phone number may be changed, not all of customer have a phone, the carrier will be involved here (coverage, rate charge...) I don't want any of that ).
OK after read all your suggestion:
I am thinking about a 4 digit pass-code (like 3 digits security code in the back of a credit card) - it will be printed out in the ID card with the instructions and everything, this will be different from the unique customer number (used to scan), here how it works:
- when creating a new customer ID card, system will ask for an additional 4 digits pass-code and also print it out to the card, an algorithms also will be put there to make sure that customers who have same name + dob can't have same pass-code.
In case customer can't use/lost the card, after they entering name+dob to check-in, system only ask this 4-digit passcode if there are more than 1 matched person, otherwise if there is only 1 person matched, system will check-in them in right on.
if they ever forgot this pass code, I mean there is nothing else they can do for them self, the receptionist will have to somehow help them, what do you guys think, I am still open for suggestions?
My final solution:
Because the cards have nothing else (of customer information) rather than the bar code (customer number) on it so the best way is to preprint (pre-made)them, have them ready in the desk to give to new customers or for card replacement purposes.
When creating a new customer, receptionist will manually input first name + last name + dob + phone number (optional) + email (optional) + home address + customer number (as same as in the card that they about to give to the customer) +. submit, system will check for everything, if everything is good receptionist then give customer a new card => customer come back to check-in station and check-in.
When customers forgot card => they will need to see the receptionist => do verification process => receptionist will check them in manually.
When customer lost card or card is damaged => they will need to see the receptionist => do verification process => receptionist then give customer a replacement card => customer come back to check-in station and check-in.
Have each customer tell you two "security question" style data: Location of birth, favorite dish, ... These can serve as uniquifiers.
You can then prevent duplicates from being entered because in case there is a colliding registration the customer must simply chose a different question.
Some rambling thoughts:
You could assign users a PIN and use that to make the account unique. Presumably to insure that it is unique you would have to assign it, you can't let them invent one. (You could let them invent one and then verify it's unique. That might be good to allow people to use numbers that have some meaning to them so they can remember them.) The big catch to this is that if the person loses his PIN, you're stuck. If the PIN is printed on the card, then if the card is damaged or worn, yes, they could type in the PIN. But if they lost the card, they might have no other record of the PIN.
You could ask for their phone number and use that as an identifier. My grocery store does that for their discount card. I think almost everyone has a phone these days. For the small number who don't, you could generate a random number that looks like a phone number but is not valid (so it won't coincidentally duplicate any real phone number), and use it like a PIN. For example if you're in the US, you could make generated numbers all start 555-555 and then make the last 4 digits be like a PIN. Then the only people who would be a problem are those who don't have a phone AND who lost their card, which should be a very small number.
Is there any information in this system that is confidential, or are people committing to spending money? I mean, if someone walked up to a kiosk and typed in the name and birth-date of his next door neighbor and accessed that person's account, would that be a problem? You haven't said what the system does. If getting into the system gives someone access to the person's medical records or bank account or transcripts of his last confession to his priest, then you have to take steps to prevent unauthorized access, you can't let just anyone come up and claim to be someone else and get in. I'm reminded of a case a few years ago where a reporter got access to records of some politician's DVD rentals. He was apparently hoping to find that he had rented a lot of vile pornography or some such that he could use to embarrass the guy, though as it turned out it was mostly westerns. My point is that even seemingly innocent information could be embarrassing to someone under the right circumstances, so you have to be careful.
How often do people have lost or damaged cards? And are there clerks available who could help someone in such cases? That is, if 99% of the time someone comes in, swipes his card, and he's in and everything is good, and the number of times that someone has a lost or damaged card is very small, you could say that in those cases they have to go to a clerk and show the damaged card, or if they say they lost their card, show identification. Then the clerk can verify whatever and give them a new card. You could have the clerk search by name and have a screen that shows birth dates and addresses, ask the customer what their birth date and address is and if it matches one, give them a new card, if not, say I'm sorry you're not on file. This is quite different from a security point of view of showing the customer the list of birth dates and addresses and letting them pick one, as a customer could, (a) type in a common or overheard name and then pick any matching entry that shows up, or even (b) use this to find the address of someone they want to harass, and then you could be liable.
On the current project I met the same way to find a customer. The project is about TV stuff, so the second level of 'sieve' is address. And I think you need to expand the customer information: a username, an email, an avatar or something easy to remember (or send a SMS with code). Also you can add user friendly behavior: if a customer cannot decide which record about him/her, the customer should go through the wizard and add needed information. Yes, it's hard to find a general evidence for all customers, but you can support several kinds of extra information.
In other words: first name, last name, and birth date aren't enough for unambiguously getting a person.
Are there any APIs available in the UK to allow someone to look up the transaction code (company name that appears in your bank statements) and get extra information about that transaction.
For example, if I had a transaction at a petrol station it could see that the transaction was for a petrol station and suggest the category to be "Vehicle Fuel" or something like that?
Must be able to specifically handle data from UK businesses.
I think what you're referring to is 'Transaction Description'.
This data is completely controlled by the organisation which debits the account so there is no standard, also some organisations also include transaction details in this making lookups extremely complex. Some examples below:
Shell Petrol Station CD 5487 < Includes last four digits of card
Some Restaurant 15/10 < Includes date
Google Apps Tran #16598745 < Includes transaction code
There are some sites that have an ability to search these transaction descriptions but I think these are user contributed, there is no official source as far as I'm aware.
How do the rest of you handle complex names when submitting a transaction to Authorize.net using AIM?
Nearly every ecommerce application on the planet asks the user to fill in the "Name as it appears on your credit card". For some odd reason, Authorize.net wants you to submit x_First_Name and x_Last_Name however.
This is fine when you're dealing with Mary Jones or Jack Smith. It becomes a real hassle when you've got Margret A. Jones-Robinson and H. William Robert Van Horn, Sr. though.
Is there a best practice here?
First & Middle names in the x_First_Name field?
Last Name, Hyphenated Name and/or Suffix in the x_Last_Name field?
Has anyone developed a routine to parse names accordingly?
Thanks!
Have two fields on your payment form. One for their first name and one for their last name. However the customer chooses to complete the form is how you should submit it (and save it in your database if you choose to do so). FYI, the name on the credit card is not used in the processing of the credit card so you do not have to transmit it to Authorize.Net to process the transaction. You should do it anyway as it helps to keep your records accurate and complete which is handy when doing audits of your transaction history.
You should generally try to avoid using one field for names as it opens up the possibility for people to enter bad information like, "The Smith Family" or "Barabara and Steve". By having two clearly delimited fields you greatly reduce the occurrence of this.
You should use 2 fields on your payment section. First name and last name.
The name on the credit card is actually used by certain cards for some services, so if you signed up for AVS and fraud detection they will use that name and provide feedback as to if its a match or not.
Alternatively, and what we have done in the past is ask the customer for:
-prefix
-first name
-middle initial
-last name
-suffix
This allows the customer to feel in control and you avoid them filling garbage in the 2 main fields (first name, last name). Authorize.net and other merchant service providers dont care for then other fields and you may choose not to either, it is just a way to keep the data "cleaner".