I've been working on an exercise for school that should have been rather simple. For some reason I cant quite figure out where I went wrong. I have been at it awhile so I may be overlooking something simple. I have some experience with data bases and actually implemented sqlite earlier today in an app but access is throwing me for a loop ! Any help is much appreciated.
Directions:
create a relationship between the tblEmployee table and the tblDepartment table as well as between the tblEmployee and the tblSale table. Be sure to enforce referential integrity in both relationships.
Create a query in Design view using the tblEmployee, tblProduct, tblSale, and tblSaleDetail tables. Add the First, Last, and Active? fields (in that order) to the query. Make the following changes to the query:
Display only active employees.
In the first empty column, calculate a new field, Total Sales (UnitPrice * Quantity) for each active employee.
Only display employees with more that than $300.00 in Total Sales.
Calculate a new field, Total Revenue (Total Sales – (Coupon * Quantity)) for each active employee.
Sum the UnitPrice, Quantity, Coupon, Total Sales, and Total Revenue fields.
Show First, Last, Total Sales, and Total Revenue in the query results.
Access Setup
When I run the query
Why is Total Sales not populated from that equation ?
Also, im a little unclear on where to add the > 300.00 to filter on employee sales.
The issue here isn't the total sales column, it is that you refer to a calculated field total sales when you create a column called total revenue.
Total Sales is only calculated once the query has been run, but total revenue wants to know what the value is before the query is run.
A workaround for this is to use the same calculation:
total revenue: ([Quantity]*[UnitPrice])-([coupon]*[quantity])
Another workaround is to create a query that calculates total sales. You can then insert that query into this one and use it as a subquery.
As for the ">300 for employee sales". I think the following may work:
I assume this is a monetary value by the 2 decimal places and not a 'number of sales' value. Therefore, I would add a new column.
SumOfSales: sum([tblSales].[quantity]*[tblSales].[UnitPrice])
Criteria: >300.00
Show: unticked
Related
Consider a collection of "sale" records with these fields:
Date
Seller
Revenue
These records are immutable and created in chronological order.
Now, consider a paginated query for a given date range, grouped by seller, ordered by total revenue per seller, like this:
Top sellers between [date] and [date] - Page 1
1. Alice $999
2. Bob $888
3. Chuck $777
...
What sort of data structure(s)/algorithms could do this efficiently, assuming:
Very many unique sellers
Very many records per seller
Very many pages of results (no sequential operations on results outside the requested page)
Date ranges are entirely variable and arbitrary
I understand how to get total revenue without grouping: an ordered tree structure, keyed on the date, with total revenue stored at each intermediate node.
Grouping without a date range could similarly use a tree keyed on seller, with revenue and number of unique sellers at each node.
But the combined filtering and grouping, I can't quite figure out.
For bonus points, are there any off-the-shelf databases that can do this? And support custom aggregation logic e.g. map/reduce?
I am designing an e-commerce website that has the following scenario:
A customer can purchase items and create an order.
The order may have unknown fee that will be added after the customer
pays the total amount of the items. That is, the customer pays
certain amount first. The order adds some fee and changes the total.
And the customer pays again for the difference. But the two (or
more) payments are associated with the same order.
(Optional) The customer can submit a single payment for multiple
orders.
Currently, I have an Order table and each order may consist of multiple OrderLineItems (simplified schema):
Order
=====
customer
line_items
total
status
OrderLineItem
=============
price
quantity
order
product
A payment is associated with an order (simplified schema):
Payment
=======
order
payment_account
total
result
It seems to be very hard to support the multiple payments for a single order scenario in the current implementation. I reckon that I have to introduce immutable invoices in the system, and the payment should be associated with an invoice instead of an order. However, I would need some help with the order/invoice/payment modeling for the above scenario. Some specific questions I have:
An order and an invoice look very similar to me (e.g. both have
items and totals). What is the major difference in typical
e-commerce systems?
How should I model invoices for my scenario? Should I have
OrderLineItems for an Order AND InvoiceLineItems for an Invoice?
Some preliminary thoughts: I will have multiple invoices associated
with a certain order. Whenever the order changes the total, I have
to somehow calculate the difference and send a new/immutable invoice
to the customer. Then, the customer can pay and the payment will be
associated with the invoice.
Would love to hear some advice. Much appreciated. Thanks!
There are a lot of questions here, I'll try to address as many as I can. A lot of the issues are the business model rather than the data model.
Firstly, you are right that you need an immutable invoice. Once an invoice is created you cannot alter it, the standard way of handling a change in invoice is to issue a credit note and a new invoice.
Think about the relations between the tables: the Order does not need to hold the lineItems as these are referenced the other way, i.e.
Order
=====
orderId
customerId
status
OrderLineItem
=============
orderLineItemId
orderId
product
price
quantity
So to view the order you join the tables on orderId. There's also no need to store the total as that is calculated from the join.
Try not to duplicate your data: your invoice will reference orderLineItems, but not necessarily the same ones in the order. For example, the customer orders an A and a B, but B is out of stock. You ship A and create an invoice that references orderLineItemId for A. So your invoice tables might look like:
invoice
=======
invoiceId
status
invoiceLineItem
===============
invoiceId
orderLineItemId
quantity
In other words there's no need to have the details of the item. You may be wondering why you don't just add an invoiceId to the orderLineItem table - the reason is the customer might order 10 of item A, but you only ship 8 of them, the other two will go on a subsequent invoice.
Payments are not made against orders, they are against invoices. So your payments table should reference the invoiceId.
Then you touch on reconciliation. If everything was perfect, the customer would make a payment against a particular invoice, even if a partial payment. In reality this is going to be your biggest headache. Suppose the customer has several outstanding invoices for amounts x, y and z. If they make a payment of p, which do you allocate it against? Perhaps in date order, so that if p>x the remainder is allocated against y. What if p=z? Perhaps the customer is intending to pay z now but is disputing y and has mislaid x? How you deal with these sorts of things is up to you, but I can say that most invoicing systems do it very badly indeed.
I am new to sql and I am attempting to write a query that takes a maximum after two separate columns are multiplied together.
One table is called portfolio and contains the amount of shares purchased. The other table is called investment and has the price paid. I am just trying to get the highest (max) purchase price after multiplying the two values. Any help would be appreciated.
Assuming that all you want is the overall max, and that the price paid stored in the investment table is the 'quantity' column and the number of shares purchased is the 'amount' column on the portfolio table, AND that the link between the portfolio and investment tables is the 'port_id' you want something like this:
SELECT MAX(t2.amount * t1.quantity) AS 'Max Purchase Price'
FROM Investment t1
JOIN Portfolio t2 ON t1.port_id = t2.port_id
If you need more columns you can add them to the SELECT list and you'll need to add in a GROUP BY (plenty of posts on SO related to this). Hope this helps!
I have a pretty basic scenario: contacts have orders and orders have order line items. An order has a forumla field on it to calculate the entire cost of the order and that is working fine. I'm trying to create a report that shows each customer name and the summed dollar amounts of all orders for that customer. So I drag the customer name onto the fields area and then add the order total field. I group by the customer full name and then I set the group by on the order total column to sum and this works fine...but then I can't sort by that column. I want to sort by total dollar amount so I can quickly see who is a high buying customer. Is there a way to order a report by a summed field or will I just have to export to Excel and manipulate the data there?
Thanks
Josh
I'm sure that this is possible. I've recreated your scenario with the standard Opportunity object and the Amount field. I have grouped on both Opportunity Name and Amount. Clicking on the down arrow button on the group gives a menu that allows you to change the sort order of the group as shown in this image.
I think the fields in your report should behave in the same way.
I am in a situation similar to the one below:
Think for instance we need to store customer sales in a fact table (under a data warehouse built with dimensional modelling). I have sales, discounts related to the sale, sales returns and cancellations to be stored.
Do you think it would be advisable to store sales for a day to a customer in a particular product (when the day is the grain) as a positive value while the returns and discounts are stored as minuses?
Also if a discount is enforced to a customer at a level other than the product (for instance brand), do you think it is alright to persist it with a key particularly assigned to the brand (product is the grain) while the product column being given an N/A, for the particular record?
Thanks in advance.
If your sales are considered a good thing (I'm assuming they are) then recording sales as positive numbers makes perfect sense. Any transaction that reduces sales (i.e. discounts and returns) should therefore be recorded as negative numbers. This will make reporting your sales very natural.
If you have diffent dimensions that might account for a record, you should populate the dimensions that make sense. So yes, attribute a discount to a brand rather than a product if that is what happened in your business transaction. This way your reporting will be able to look at all discounts, at discounts for particular products and discounts for entire brands. If your fact table shows the most direct "cause" of the discount (product or brand) then your reports will be more useful than if you link the fact to brand through a relationship to product.