So I am trying to take payment and book appointments for my oil change shop, I found an app that takes care of the scheduling, but now I need to make the product change prices based on the make/model/year of the car. Pricing is pretty simple, $49, $59 or $79 based on the labor for the specific make/model/year. I have a database and excel sheet with the corresponding price for every car we service.
I've tried a lot of apps and none of them seem to fit. Currently, I'm using Infinite Product Options which allows me to change the price based model but doesn't pay attention to the year (which I could live with) but I can't find a way to validate the selection. i.e. if Ford is selected as the make, it should only show cards made by Ford in the model dropdown.
Is there a better way to do this? Is this a feature in the app that I am missing?
Appreciate any help you can offer!
A long time ago I made a car shop or two or three. All of them used the standard MODEL/MAKE/YEAR selections for choosing things like available tires, etc.
So that magic is controlled by a mafia and you pay for access to it. It costs something like $2000 but that may have changes. Anyway, if someone chooses Ford, they only get Ford cars, which means MAKE choices are so much easier. I suppose it is also smart enough to know you cannot have a 1972 Ford Taurus.
Once you get past that brain dead selection, you could present the correct variant, and hence the correct price by having that selector match variants based on some magic. A back-end script might use the MAKE/MODEL/YEAR result to find a product that matches the make, then the 100 variants would cover model (for the most part).
Anyway, tough for you as yes, those low-fruit on the tree Apps for product options are generally too simple for serious use.
Related
Basically, I'm kinda exhausted while thinking about the best possible way to structure my database for a recipe app I have planned and could need some help/ideas.
The goal is to make a recipe app including multiple languages(translated recipes) and which has features like a meal plan and shopping list, for example.
To achieve all that, I came up with this design of a database(Image below). It's important to have the ingredients as an own entity so that they add up in the shopping list. With the current design its really hard to filter by the total amount of calories, eg. "I want to see all recipes that have less than 500 calories".
The recipes only get added by me, meaning there will be probably never ever be more than 10 000 of them(In the absolute best case :D).
I would appreciate any help and also comments about other things like scalabilty/performance etc.
I am hoping someone could help on this.
I am updating an ordering / despatch and invoicing system.
I have a OrderItem table which includes the following (truncated for ease):
OrderItemId (PK)
OrderId
ProductId
UnitPrice
Qty
VatCodeId (FK)
The net, gross, total and VAT fields are calculated when required.
I have always used this method but now I am thinking that the values should be stored in the OrderItemTable, as such:
OrderItemId (PK)
OrderId
ProductId
UnitNet
UnitVat
UnitGross
LineNet
LineVat
LineGross
Qty
VatCodeId (FK)
I realise this table is now not normalised but speaking to someone in the field, they have quite successfully convinced me that this is historical data which should never be changed and as such, should be stored at the time of posting. I am inclined to believe them.
Performance wise, I do not think it will make much difference either way but may make reporting slightly easier.
Could I be so cheeky as to ask some of you experts your opinion?
Many thanks in advance, as usual!
I strongly recommend storing the calculated values of all fields, because tax rates and calculations change. That includes net, gross, VAT, and total. The reason is because the calculations could change at any time.
For example, imagine today that the tax rate is 10%. You make a sale of 10 units at $10 each. So gross is $100. You calculate tax, subtract 10%, and your net is now $90.
But two years from now, tax rate goes to 13%. Are you going to modify your reporting programs so that they calculate the tax differently for older transactions? Having done this in the past, I'll bet you get it wrong somewhere. You'll have to change dozens, or perhaps hundreds, of reporting programs. You're bound to miss a few, and you won't find all of them for years. Save yourself the headache: store everything you'll need. Don't depend on the ability to calculate tomorrow the things you calculated today.
Also note that things other than rates can change. They might change which items are taxable. They might add graduated tax rates, or make you compute two different kinds of taxes, or ... believe me, lots of different things change. In the U.S., the tax calculations for gasoline will make your head spin, with different rates for federal, state, county, city, etc. Sometimes the tax rate depends on how long you've had the fuel in inventory, where you shipped it from, where you shipped it to, and (I'm not kidding) the day of the week that you're delivering it on. It's maddening!
Tax rates and calculations change distressingly often for certain products. You can try to keep historical tax rate data so you can re-compute taxes and fees on previous transactions, but it's a whole lot easier and much more reliable to save what you calculated at the time.
Whatever you do, have users and client programs access views and stored procedures, not base tables. That way, you can change what you store and what you compute without any fuss. This is one of the key features of relational DBMSs.
Bear in mind that if you introduce redundancy (by storing "everything") without controlling it with constraints, you will end up with inconsistent data. Rules belong in the database.
If your rules are currently simple (i.e. VatCodeId determines VAT (and changes if the VAT changes), UnitGross = UnitNet + UnitVat and so on), your system will be simplest and most reliable if you avoid redundancy and store only the minimum. It is a simple matter to create a view that looks as if you store everything, and use this for reporting, UIs etc.
If the rules subsequently change, change the base table(s) (and use the simple rules to populate the new columns), and redefine views and stored procedures to account for the table changes (without changing their headers/signatures, preferrably). This saves you from database schema complexity you might never need.
So this is going to depend on a few other factors.
Is this a new environment or one that has already been running for awhile? Altering db design on something currently being used is a headache. This is especially true if the OrderItem table is a critical part of the Inbound business processes.
If we are on a fresh db environment with no users or data to worry about, then I would say we are safe to make the change. However, we should also ask whether its a possibility that this 'historical data' will ever become 'active data' in the future.
If the this is an active db, then we need a good reason to go through the headache of altering table schema with data already associated to it. How often are we needing to hit VatCodeID (FK) in our current reporting processes? If the answer is 'not very often', then we can save ourselves a lot of time and a lot of money by leaving it as is.
But maybe we are using OrderItem quite often and it would be nice to have all our data on a flat table for a business reason. Then we should ask, can I get away with doing less and achieve a similar performance increase?
Since we checked how often that OrderItem was being queried while being join to whatever VatCodeId is referencing, then we can look up those queries and to see if they can be optimized at all. This may involve adding an index to either OrderItem or the reference of VatCodeId, that would still be preferable to altering the table structure most of the time.
Keep in mind that even after you've altered the tables involved and migrated the data across, that you may then have to fix any insert statements where a developer got lazy and wasn't as explicit as they should have been. Additionally, if a record on OrderItem is associated to multiple records on the table VatCodeId is referencing, then we may also have to through and fix the group by statements that are pulling from OrderItem.
You will then likely need to touch up any third-party reporting software that references the tables you changed because that reporting software also often requires explicit call outs.
Basically, the answer to your question is that no, we should probably leave that table as is unless we have a very good reason not. But, if we do think we have a very good reason, then the next step is to spend several hours researching everything else we would need to change in order to make this work.
I would also store the entire history for the reasons stated by other posters. However, here is a thought for you: by using SqlServer's Temporal Tables you can then design your queries to grab the various tax structures as-at the date of the transaction. This functionality is provided by the database engine with just a few extra key words to your SQL. The approach will appeal to your sense of order and correctness I am sure, but it's obviously then incumbent on you to ensure you use the feature as appropriate (it would be easy to overlook or forget). Another downside is that. Lot of reporting or ORMs don't yet support it natively, so more SQL or procedures for you.
Food for thought. You will have to decide if it's worth it (I suspect not but I don't know the details of your app)
Pedram poses a problem regarding discounts for product customizations.
Example
If you apply a specific price for 100 pieces, let's say 5% discount, and you add 50 t-shirts with print A and 50 t-shirts with print B, you get a discount. But in reality only 50 pieces of one print production is sold. So there shouldn't been any discount (perhaps in my opinion).
Let's take a crazy example, say we have 100 different prints, then you would have to set up the printing production 100 times! And there for the discount for 100 pieces is not appropriate anymore.
Question
How can I make discounts (specific price) only apply to an indivual customization in the cart?
Further thought
My guess is that it should be changed somewhere in the core. Hopefully with a not to invasive class override. The setting PS_QTY_DISCOUNT_ON_COMBINATION tells if a discount should apply to the whole product or only to the combination. This setting is used in SpecificPriceCore::getSpecificPrice(), and doesn't seem to be the key in solving this problem.
While it's possible combinations, setting a specific price for customizations (not to be confused) is unfortunately is not yet supported in the Core.
It looks that this cannot be done by means of an override because you'd probably need to add a new parameter to getSpecificPrice(), among others.
Feel free to submit a pull request if you want this feature added to the Core (branch develop for 1.7), or add a ticket to the forge.
I want to create a database that has the table for sales and services for a certain company. What I want to know (since I don't know much of SQL) if there a way to store like an object that represents a list or array in a single cell. Why? Because I want a cell in the Sales table to point to all the services that generated that particular sale. For example:
A sale of in 09/09/11 that was generated by service_1, service_2, ... , service_n . Where service_# is a certain service that this particular company offers. Again I apologize for my stupidity but I'm now in the process of learning SQL.
I'm planning to create the database on SQL server.
This is a bad approach.
Database must be well normalized. You are talking to make a design that is not in first normal form.
That you are loking for is a N:M relation ship, you should create a new table called sale_services:
sales (saleId, ...)
services (servideId, name, price, ...)
sale_services( saleId, serviceId)
As a rule of thumb, as soon as you want to add multiple things in one cell, change your database design. Split the tables. Use one table called Sales, another called Services and then a last one that joins the two together which has the ids of the sales and services you want to "join".
As others have said, just wanting to store an array is a sign that you are designing incorrectly. If you want an array of data, what you really need is a related table to store that information in individual records.
What I want to talk about is what happens when you decide to store an array in a field, separated by a comma for instance.
Suppose you store the available colors of a product in a field called colors.
Now you have
Product Colors
item1 red, blue, yellow
item2 blue, purple, red
and so forth for a million records
Now how do you find all the products that come in red? Array fields are difficult to properly query and the performance when you do so is generally abysmal. Adding a new color is also a pain point especially if you want it to be in a certain order.
Before you go any farther in designing a database you need to read about normalization and database design. One of the very first rules of database design is NEVER store more than one piece of information in a field in a record. This is a complex subject and making the wrong choice early on can kill your system. Database are not simple or easy to refactor so you need to know what you are doing at the time you create the design.
Lots of good comments here.
You might want to take a step back and look at the bigger picture of your database. The comments here are from practical experience, not just text books. Try to see what other uses will happen with your data. In your example, if you stored the service list in a single cell, like you mentioned, how would you determine which service was performed the most? How about what services are never used? If your solution requires reading every "row" and doing something, than most likely there is a better approach.
If you put together a suggested design, many people here will help you tweak it and fine-tune it to make it better..
Good luck...
I'm trying to set up Schema.org metadata on a site at the moment, and I'm wondering how (or if) to declare multiple currencies. I have 6 formats of the price - GBP, USD and EUR, all with inc. and ex. VAT prices.
Based on the examples Schema provide on the Product page, there is only ever 1 price - is it possible to specify more, and if so, how does the search engine decide which one to show? If not, I'm assuming I should show GBP inc. VAT - is that correct?
It's really the Offer that has a price associated with it. If you look at the second example on the Offer schema page, you'll see multiple offers associated with a single product. They're from different sellers (and don't specify the price in a machine readable way), but you could do the same thing with multiple offers in different currencies from the same seller.
I'm not sure there is a way to express inclusive or exclusive of VAT in the schema, so you may be stuck with just text labels for that.
If it’s the same Offer and you allow payment in multiple currencies, you could use multiple priceSpecification properties.
Each property has a PriceSpecification as value, which can have a price (via price property) and a currency (via priceCurrency property).
how does the search engine decide which one to show?
That’s up to the search engines. When you specify the currency, they have all they need to know (if or if not they use this information is a different question, off-topic for SO). Schema.org doesn’t provide a way to mark a "primary" PriceSpecification, and why should they? After all, all your prices are valid.