Purchase Order - Opinion on my query design (1 Viewer)

steve21nj

Registered User.
Local time
Today, 15:24
Joined
Sep 11, 2012
Messages
260
Hi All,

I wanted to get some opinions if my query design is flawed or if I am going about this the right way. My numbers display correctly as of now, but I read a lot about running totals and using (DSum) which i'm not doing.

I am building a purchase order system where I have a static starting budget in several categories.

I created a few queries to puts everything together:
a -a select query for the category table based on the budget name and amount.
b -a select query for my purchase orders that shows the subtotal, estimated, and actual amounts; and groups on the category.
c -a select query that sums the subtotals, estimated, and actual amounts.
d -a select query that groups by category, then subtracts the starting totals from the subtotal, estimated, and actual amounts.

I was wondering if I am going about this wrong or not.

The below SQL code is for query [C]
Code:
SELECT tblOCC.OCCName, Sum(qPurchaseRequisitionSubtotal.Subtotals) AS SumOfSubtotals, Sum(qPurchaseRequisitionSubtotal.FinalAmount) AS SumOfFinalAmount
FROM tblOCC INNER JOIN qPurchaseRequisitionSubtotal ON tblOCC.OCCName = qPurchaseRequisitionSubtotal.OCCName
GROUP BY tblOCC.OCCName;

The below SQL code is for query [D]
Code:
SELECT qStartingBudgetOCCs.OCCName, qStartingBudgetOCCs.BudgetAmount, [BudgetAmount]-[SumOfSubtotals] AS Estimated, [BudgetAmount]-[SumOfFinalAmount] AS Actual
FROM qStartingBudgetOCCs LEFT JOIN [qSumEst&Actual] ON qStartingBudgetOCCs.OCCName = [qSumEst&Actual].OCCName
GROUP BY qStartingBudgetOCCs.OCCName, qStartingBudgetOCCs.BudgetAmount, [BudgetAmount]-[SumOfSubtotals], [BudgetAmount]-[SumOfFinalAmount], [qSumEst&Actual].SumOfSubtotals, [qSumEst&Actual].SumOfFinalAmount
ORDER BY qStartingBudgetOCCs.OCCName;
 

jdraw

Super Moderator
Staff member
Local time
Today, 16:24
Joined
Jan 23, 2006
Messages
15,379
I think you would get responses if you showed us your tables and relationships.
We know nothing of your set up and you are showing some sql with a joined query (that we can only guess what it might be)???

So it's a purchase order system --- what exactly does that mean in 2 or 3 sentences?

There are some free data models involving purchase orders at
http://www.databaseanswers.org/data_models/index.htm

Maybe they can provide some guidance/ideas.
 

steve21nj

Registered User.
Local time
Today, 15:24
Joined
Sep 11, 2012
Messages
260
Attached is a snapshot of the relationships.

The purchase order system is based on requisitions. A requisition can have many purchase orders, but any given purchase order can only have one requisition.

This system tracks the purchases for the company by auto generating a specific PO number through vba. Each purchase order falls into an OCC category, where a specific yearly budget is set up for the year.
 

Attachments

  • relations.PNG
    relations.PNG
    83.1 KB · Views: 1,531

kipcliff

Registered User.
Local time
Today, 15:24
Joined
Sep 19, 2012
Messages
71
When I looked at your snapshot, my first instinct was to grab my mouse and arrange without crossing any lines. lol

So far, the only thing I see wrong is that you have fk_OCCID in two tables, one of which is a child of the other. You do not need to duplicate the reference in Purchase when it is already in Requisitions.
 

steve21nj

Registered User.
Local time
Today, 15:24
Joined
Sep 11, 2012
Messages
260
I updated the "Halloween" themed relationship lines!

I know the OCC in both is "wrong" as far as typical relationships go. But I use the OCC on the requisition tbl to feed into another printable/editable custom form for the user based on the state forms we are required to use. I put this because my purchase order details table can have several different OCC's within a requisition.
 

Attachments

  • updated.jpg
    updated.jpg
    94.1 KB · Views: 2,309

kipcliff

Registered User.
Local time
Today, 15:24
Joined
Sep 19, 2012
Messages
71
It all seems clean, so far as I can tell. Make a copy of it, and populate the copy with a series of test data to see how it holds up. Don't forget weird stuff to account for input errors (nulls, negative values where only positives should be, etc.).

No matter how pretty we make it, there is always a user who will trigger that one error we overlooked.
 

Users who are viewing this thread

Top Bottom