If a customer has an order with one product from each of my two stock locations locations, then the flat-rate shipping per an order is applied twice. I don't want to pass the second shipping cost to the customer, but rather only apply one flat-rate shipping expense. What is the best way to do this that will have the least impact for Spree Core?
Related
We do not want to limit the number of items a person orders. Our products are all priced the same based on size. The only way I have found to do this with Opencart is by giving them an item a price of zero and controlling the price by using options.
Our problem is a user can not purchase more than one of an item. This may or may not be related to the option condition mentioned above.
EXAMPLE: Say the product is a t-shirt and we want the size to be an option. The customer would choose a design then a size. Then quantity and checkout.
Model number is the design.
The price is based upon size.
PROBLEM: Customer is limited to one t-shirt per model. In order words they can not order two size smalls of the same design.
Your problem does have a solution. You can order more than 1 size of the same design. I see that your problem is when you add the item on your shopping bag. When you go to checkout/cart page, there is a quantity column where in you can modify the quantity of your order.
I'm creating a web based point of sale (think cash register) solution with Django as the backend. I've always taken the 'classic' approach of modeling invoices and their line items.
InvoiceTable
id
date
customer
salesperson
discount
shipping
subtotal
tax
grand_total
[...]
InvoiceLineItems
invoice_id // foreign key
product_id
unit_price
qty
item_discount
extended_price
[...]
After attempting to research best practices, I've found that there aren't many - at least no definitive source that's widely used.
The Kimball Group suggests: "Rather than holding onto the operational notion of a transaction header “object,” we recommend that you bring all the dimensionality of the header down to the line items."
See http://www.kimballgroup.com/2007/10/02/design-tip-95-patterns-to-avoid-when-modeling-headerline-item-transactions/ and http://www.kimballgroup.com/2001/07/01/design-tip-25-designing-dimensional-models-for-parent-child-applications/.
I'm new to development (only having used desktop database software before) - but from my understanding this makes sense as we can drill down the data any way we want for reporting purposes (though I imagine we could do the same with the first method by joining the tables).
My Questions
The invoice ID will need to be repeated for each row (so we can generate data like totals for the invoice). Is this an intentional feature of this way of modeling the data?
We often have invoice level data like notes, discounts, shipping charges, etc. - How do we represent these using this method? Some discounts are product specific - so they belong on the line item anyway, others are invoice wide (think of a deal where you buy two separate products and receive a discount on the two) - we could we somehow allocate it across the line items? Same with shipping charges, allocate it by dividing it among the line items?
What do we do with invoice 'notes' - we have printed and/or internal notes, would we put the data in the line items and just repeat it for each line item? That seems to go against data normalization. Put it in a related table?
Any open source projects that use this method that I could take a look at? Not sure how to search for them.
It sounds like you're confusing relational design and dimensional design.
A relational design is for facilitating transaction processing, and minimizing data anomalies and duplication. It's your operational database. A dimensional design is for facilitating analysis.
A relational design will have an invoices table and a line_items table and a dimensional design will have a company_invoices_customer fact table with a grain of invoice line item.
Since this is for POS, I assume you want a relational design first.
As for your questions:
First there are tons of good data modelling patterns for this scenario. See https://dba.stackexchange.com/questions/12991/ready-to-use-database-models-example/23831#23831
The invoice ID will need to be repeated for each row (so we can
generate data like totals for the invoice). Is this an intentional
feature of this way of modeling the data?
Yes
We often have invoice level data like notes, discounts, shipping
charges, etc. - How do we represent these using this method?
Probably easiest/simplest to have a "notes" field on the invoice table.
For charges and discounts you should use abstraction (see Table Inheritance), and add them as Order Adjustments. See the book by Silverston in the link above.
Some discounts are product specific - so they belong on the line item
anyway, others are invoice wide (think of a deal where you buy two
separate products and receive a discount on the two) - we could we
somehow allocate it across the line items?
The price of the item should be calculated at runtime based on it's default price, and any discounts or charges that apply in the current "scenario", example discount for government, nearby, on sale day. You could have hierarchical line items that reference each other, to keep things in order. Again, see Silverston book.
What do we do with invoice 'notes' - we have printed and/or internal
notes, would we put the data in the line items and just repeat it for
each line item?
If you want line item notes, add a notes column on the line items table.
That seems to go against data normalization. Put it in a related
table?
If notes are nullable, and you want to be strict about normalization, then yes, add a invoice_notes table.
I am having trouble with my order processing for Opencart 1.5.6. I have a series of checkboxes that if checked each cost $50.00. The problem is that the customer is ordering print materials in quantities of 500, 1000, 5000, etc. When they get to the shopping cart it charges the $50 extra for each option for each individual item ordered based on the quantity. This makes it so that their total skyrockets. If they pick one option for $50 and order 500 business cards they get charged an extra $25,000 for that one option.
The only solution that I can see is to have the Quantity be an option and only allow them to order one product but that does not allow them to change the Quantity of cards in the Cart.
Is there anyway to set it up so that an option charges a flat rate not based on total quantity of the order?
When customizing OpenCart follow these steps.
Look to see if this link has an extension that will do what you want.
If step 1 did not work. Go to your public_html file (the place that has all your code). Open the files that are related to your problem and edit those. There is also an OpenCart forum that will help with common problems.
As far as changing the settings on your payment function. Go look at OpenCart->catalog->checkout folder. Or maybe OpenCart->admin->checkout. You will need to find the function that adds quantity and gives value. You will need to change those around a little.
because of MAGE price calculation complexity + EPR incompatibility with MAGE calculation, I was thinking about overriding getPrice() and getFinalPrice() methods in a way, that they will call external webservice for a requested price.
Does anybody tried to solve price calculation in a suggested way and if, does this work in a real environment?
Second option is to reverse engineer price engine from ERP in MAGE database (additinal tables + logic inside MAGE).
What do you tink? Any advice would be welcome.
I had a similar problem with complex pricing issues.
I ended up with adding some custom attribute fields that where dynamically chosen on the
customer number.
Could you give me some background on your problem?
we have very complex price calculation. Every customer has its own pricing rules(per product,per product group, special discount, etc..).
There is 15.000 customers and 60.000 items.
It is possible to add all rules into MAGE, but price indexing takes very, very long and MAGE is almost unusable. pricing engine on the other hand is not so hard to implement, but a question remain if it is possible to use price engine from ERP(ERP has API for getting a price) or is it better to implement it inside MAGE (on mysql) with extending original logic.
There is no need to have administrator GUI for checking prices, because sync is done automatically and never entered by the user. (A goal is to completely replace pricing logic from MAGE).
Thank for your answer.
After some work and testing, I did new models in Magento and reimplement price calculation logic based od ERP rules. Webservice would work, but it would be very very slow(call to getPrice or getFinalPrice is executed at least twice for every item displayed).
How would you design the data model for an inventory management system in RDBMS?
Would you:
store each purchase & usage, and uses SUM() and GROUP BY to calculate the warehouse quantity on-the-fly?
same as 1, but consolidate the quantity daily, and use the value of the previous day?
quantity as an Int field, update through application layer?
same as 3, but make use of DB trigger?
Transaction-based inventory system seems to be superior in terms of level of details it captures, but it is harder to implement it correctly. Performance will degrade over time.
Quantity-based inventory system seems much easier, but might need extra lockings to make sure the Qty value is ++ or -- correct.
Which one would you choose?
I would most likely go the trigger route, and update the quantity as transactions are pushed into the database. This makes it really easy to see what the current quantity is without need of a bunch of subqueries and calculations.
If it's done in a trigger, then you can ensure that regardless of where the transaction comes from, the quantities in your stock tables will always be updated (whether there are transactions added via hard INSERTs or via the application).
If there are logging concerns, then wrap some logging into your trigger to track before/after quantities into a separate logging table.
A trigger might look like this (not tested):
CREATE TRIGGER [dbo].[OrderAdded]
ON [dbo].[Orders]
AFTER INSERT
AS
BEGIN
DELCARE #ProductID int; DECLARE #Qty int;
SET #ProductID = (SELECT ProductID FROM inserted);
SET #Qty = (SELECT Qty FROM inserted);
UPDATE StockTable
SET Stock = Stock - #Qty
WHERE ID = #ProductID
END
I don't see that there would be a performance issue to worry about so long as you've got your StockTable properly indexed for the ID and Stock field (I'm of course making all of this up given that you didn't provide any DB information).
You want transactional data if an audit trail is important. And, I've never seen a real system where it was't.
As far as performance is concerned I would:
capture a denormalized value on a periodic basis - hourly or daily for instance
move transactional records involved in this denormalization process to another table (i.e. from "current" to "warehouse").
Then totals would be a sum of this denormalized value and current transactions.
This approach also facilitates backups as the number of transactional records could exceed available disk space. So write out the warehouse to tape backup for instance.