I'm trying to understand REST naming with this example.
Suppose I want to create a new company with this relations:
Company <--->> CompanyTaxes <<----> Taxes
Taxes is a global Entity, and CompanyTaxes are the selected Taxes for this company.
In the creation of a new Company I have to list all the existing Taxes in order to check or uncheck one or many taxes to use. Then, following REST resource naming I think the better option is to use:
GET /Companies/{0}/Taxes: if the id of the company is 0 then I list all taxes.
GET /Companies/123456/Taxes: if the id is 123456 then I send the list of all taxes and mark those that the company has selected.
Is that ok, or I have to move the Taxes so they can be independent of the Company?
In the case of a new Company:
GET /Taxes/: get all the taxes and render them on the UI
In the case of an existing company:
GET /Taxes/: get all the taxes
GET /Company/123456/Taxes: get the taxes from Company 123456
Then, in the UI I have to match the taxes from company with the global ones in order to check/uncheck selected.
What is the better option? In the first case the server sends the information of all the taxes, along with the selected. In the second case the UI is responsible for the match in order to show which taxes are selected.
Greetings!
Related
I made some changes in this file catalog>view>theme>default>template>product.
I created a custom textbox where the price of the product changes according to the selection made in the select option.
http://webanddesigning.com.np/ocart/index.php?route=product/product&product_id=72&search=bara
but I cannot pass the selected price to the shopping cart. Any idea ?
Opencart does not pass price info to the cart. Price is calculated in the library cart class according to options, discounts, specials and other product data in your database. In your case it sounds like you need to either do this using native options or write a custom option method.
I am writing a simple JavaScript which will update my price automatically (I know there are addons but they dont work with the nature of my products) when the user enters amount, size etc etc. I want to know how do I override the product price before/after it is sent to the shopping cart?
Example: The product price is 10€. The user select some variatons and then the price is 22,40€. I want to send that price to the checkout instead of the 10€.
So far I have written my JavaScript which updates the price based on user input and selections. I just need to know how to pass that new price variable and more important WHERE.
Any tips or help would be appreciated.
You mention "variations". Are you using attributes? If so, you can simply attach a price adjustment to each option value. That would be the quickest and most proper way to handle variation-specific pricing.
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 building a dashboard application for an accounting department.
The user will select a month, and see all the companies that meet certain criteria in that month. The routes will be
/:month_id a summary page
/:month_id/companies more details about each company
/:month_id/companies/:company_id all details about a single company
Ideally I'd have a month model which hasMany company models. The only problem is, companies will show up in multiple months.
Correct me if I'm wrong, but doesn't this mean that if a company is already in the store, when a new month is requested, it will take that company's data from the store instead of from the server? The data will be different for each month, so this wouldn't work for me.
I suppose in this application each company's id is really their normal, integer id plus the selected month. So one way around this would be to give each company an id like '15-Mar-2013'.
Alternatively, I could just pass each month's companies data through raw and do transformations on the plain array. The problem with this, though, is that I'll have to calculate aggregates on companies (in addition to the entire month), and it would be very nice to keep those two things separate. If I had a completely separate Company model, I could just go to town within the model:
App.Company = DS.Model.extend({
month: DS.belongsTo('App.Month'),
name: DS.attr('string'),
contracts: DS.hasMany('App.Contract'),
totalRevenue: function() {
return this.get('contracts')
.filterProperty('type', 'newSetup')
.getEach('feeChange').reduce(function(accum, item) {
return accum + item;
}, 0);
}.property('contracts.#each.feeChange'),
...additional aggregation functions
});
What do you think?
It doesn't make any sense to me that months own companies, which is what your month[1]->[N]company relationship indicates.
What you want to say is that you're looking for all companies that have certain criteria that occur within a month. The month chosen is just part of the search criteria.
Imagine a little webshop which uses its own currency.
In the database, there is a table for items, which can be bought. The count of each item is limited. This limit is stored in a collumn in this table as integer.
Also, there is a table for the user's cash accounts, whereas for each account the current balance is saved.
If, for example, two users conduct their purchases at the same time and only one item is available, it could be possible that both users pay but only one receives the item due to racing conditions.
How can such racing conditions be resolved, without relying on entity framework throwing exceptions on saving?
How can I ensure the count of available items and the account balance of the buyer is correctly updated?
This isn't really a problem specific to Entity Framework, it's applicable to just about any shop scenario. It comes down to a question of policy - the only way to ensure that two customers do not purchase the same item is to allow a temporary lock to be placed on that item when they add the item to the cart, or begin the checkout process, similar to how concert tickets or flights are sold. This lock would expire if the purchase is not completed within a set amount of time, and the item would be released back for other customers to purchase.
In an e-commerce setting, this is not as suitable, since people may add an item to their cart and not check out, or spend extra time choosing additional items. This may lead to the scenario where you have items for sale but they can't be bought because they're in someone's cart who's not planning on checking out. Instead, duplicate orders are allowed, but payments are typically only pre-authorised and then completed at the time of shipping or order confirmation, so even if the second customer enters all their details and presses Buy, their card wouldn't be charged since the item wouldn't be shippable.
You can implement checks at different stages during the Checkout process to ensure the items in the cart are still available, or at the simplest level, leave it for the final "Pay Now" button on the last page. Ultimately though, this just reduces the potential for the race condition, rather than eliminating it.