Hi,
Embedded comments.
"Vance" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thank you for attempting to help me. I'm not sure how to do all
> this, though; my experience is very limited.
>
> When the teacher selects the item to order, that IS the best price
> (because they are choosing from a list created through a many-to-many
> relationship between fldItemID and fldVendorID... so I don't think I
> need the BestPrice table.
>
> I don't understand how the supplier number can be the new PO number.
> It wouldn't be unique would it? We would order from the same supplier
> more than once.
The PO would be unique, but you would know how many of them to create
knowing how many suppliers you need to supply all the articles.
>
> I don't know how to create "Inner Joins"... I'm sorry that my
> knowledge is so limited.
In the designer, you bring (at least) two tables. In the top half, the
graphical part, drag a field from one table and drop it over the field to be
matched in the second table.
If you have
table ShoppingList:
ShoppingListID (PK, autonumber)
PONumber (FK for tblPurchaseOders. which is now empty)
' no need of OrderDate (created using a default value of today's
date)
' no need of fldVendorID
ItemName
UnitCost
Quantity ... etc.
and
table PurchaseOrders:
PurchaseOrderID (PK)
PO_Date
PO_VendorID
VendorID
Then, assume ShoppingList.PONumber is filled with a valid POnumber ( an
existing one in PurchaseOrders.PurchaseOrderID ). Now, observe that I
mentionned that you do not need OrderDate in ShoppingList! Why? because you
can get that info by inner join:
Bring both tables in the designer, drag and drop ShoppingList.PONumber
over PurchaseOrders.PO_VendorID. In the grid, drag all the fields from both
tables ( * ). Look at the data, the field OrderDate in ShoppingList is the
same than the associated one in PurchaseOrders.PO_Date! Because of the inner
join, you can "pump" (or lookup) the data in PurchaseOrders through the
joining fields
PONumber - PO_VendorID.
Sure, as it is, that is working only for existing PONumber, but the goal
was to illustrate the power of joints.
If you have a table PricesList
ItemName (pk)
UnitCost
VendorID
You can get the VendorID you need to contact, this month, with something
like:
SELECT DISTINCT VendorID
FROM PricesList INNER JOIN ShoppingListID
ON PricesList.ItemName = ShoppingListID.ItemName
WHERE ShoppingListID.PONumber IS NULL
Again, we lookup through the items to be order to get the VendorID. The
items to be ordered are those in ShoppingListID where their PONumber is
still NULL (unassigned, unknown, at the moment). Since each item has one
VendorID, what we really want is the list without repetition, so the
DISTINCT "option".
> I did figure out how to create a unique
> purchase order number, though by combining the OrderDate, the vendorID
> and the materialID:
> SL_PONumber: CLng(Format([OrderDate],"mmddyyyy") & [fldVM_VendorID])
> This gives me a unique number to use, but now Access won't let me
> append it to the tblPurchaseOrders -- it says that my records have
> "Key Violations."
>
So, now we know how many PO have to be issued ( exactly one by Vendor ),
we can start to create those records. It seems you want the PO be made of
the mmddyyy representation follow by the VendorID, great (note that I have
added one field to your PurchaseOrders table) :
INSERT INTO PurchaseOrders( PO_Date, PO_VendorID, VendorID)
SELECT Date(), CLng(Format(Date(), "mmddyyyy") & VendorID) , VendorID
FROM (
SELECT DISTINCT VendorID
FROM PricesList INNER JOIN ShoppingListID
ON PricesList.ItemName = ShoppingListID.ItemName
WHERE ShoppingListID.PONumber IS NULL
)
And all the PO number are then created (Observe that the inner most query is
the one we discussed before).
Well, half the job is done, we now need to update the ShoppingList table
with the PO number we just got.
Start with a new query. Bring the three table PricesList, ShoppingList and
PurchaseOrders. We will join ShippingList to PricesList through their
ItemName fields. We will also join PricesList and PurchaseOrders through
their VendorID field. In the grid, drag ItemName and PONumber from
ShoppingList, under PONumber, add the criteria IS NULL. Drag the PO_VendorID
from PurchaseOrders table in the grid too. Take a look at the data! Magic,
we just have to "update" the PONumber by its now associated PO_VendorID
value! Back in design mode, change the query from a SELECT type to an UPDATE
type, and update PONumber by [PurchaseOrders].[PO_VendorID]. You may also
want to update the field UnitCost of ShoppingList by [PriceList].[UnitCost]
at that moment. Just run that second query (after the INSERT INTO one), and
the job is now done, just running those two queries, each month.
> Thanks for trying to help me, though.
> Everette
Hoping it may help,
Vanderghast, Access MVP