Purchase Order Relationship

silentwolf

Active member
Local time
Today, 01:30
Joined
Jun 12, 2009
Messages
655
Hi guys,

just wonderig your thoughs on the following relationship.

I got a Supplier table 1: n to Product table

PurchaseOrder Table 1:n to PurchOrderDetails table

Attached the Relationship.

I was wondering if I should include SupID also in the PurchaseOrders Table so I can Pick a Supplier and create a PurchaseOrder or is it better to leave the relationship as it is?


Thanks for your Input!

Cheers
Albert
 

Attachments

  • PuchaseOrderStructure.JPG
    PuchaseOrderStructure.JPG
    38.5 KB · Views: 163
Leave it as is.

You can query the supplier via the ProdIDRef -> Products.ProdID -> Products.SupIDRef -> Suppliers.SupplierName

When you pick a product for the PurchaseOrder it is already tied to a supplier.
 
If a product is available from more than one supplier you will have to change the relationship between Suppliers and Products to a n:n (via a junction table)
 
Hi David,

Ok than I will leave it as it is as there are not really more suppliers with the same Products.

Cheers!
 
Hi Pat,

thanks for your reply!
So you mean just add the SupplierID to the PO table but don' t join it to Suppliers Table?
Or join it and just don't enforce RI?
 
You can have a default Supplier ID in the Product table. That can save time when creating orders but does not prevent you from using a different supplier.
 
I would not assume you can only have one supplier for a given product. That sounds unreasonably limiting to me

When you say suppliers 1 to many with products, do you mean you store the supplier in the product table?

However you store the supplier, you still want the supplierID on the order, as otherwise you could add products to the current order from more than one supplier.
 
Hi,

there are few suppliers with many products but each supplier has its own products.
So if I select a supplier I like to show only the products of that supplier and then create a Purchase Order for that particular supplier.

When you say suppliers 1 to many with products, do you mean you store the supplier in the product table?

I store the FK to the Product Table and the FK to the PurchaseOrder Table.

Hope that makes sence?
 
Hi,

there are few suppliers with many products but each supplier has its own products.
So if I select a supplier I like to show only the products of that supplier and then create a Purchase Order for that particular supplier.



I store the FK to the Product Table and the FK to the PurchaseOrder Table.

Hope that makes sence?
So what do you do/would you do if you change the supplier for a product, or you ever need to source a product from a different supplier? I don't know what products you sell, but there are generally some generic products in most systems that could be bought from more than one supplier. You can't do that if you store the designated supplier in the product table.
 
Well that system needs to look for parts for maintainence.
And those Parts are from an individual supplier.
I had it with multiple Suppliers set up first but as there are so many products about 10 tsd. the System will blow up if I set it up so each supplier could sell the same products.

Which in most times that is not the case.
A supplier has Models and sells Parts to those models.
So if I have maintainence work to do I need to find those parts related to the specific Model or in that case the Supplier.

Not sure how I could set it up so I don't have thousands of products also able to buy from different suppliers so I keep the system not blowing up.

Hope that makes sence and is understandable.
 
You need 3 tables as others have said.

A products table
A suppliers table
A products-suppliers table

You don't set it up that any supplier can supply any product.
You set it up that each product can be supplied by the suppliers you designate for the product, possibly at different prices.

Otherwise, if you want to buy a Widget that is supplied by ACME, but ACME haven't got any, you're in trouble. If you have other suppliers then if ACME don't have any you can order from The Widget Co instead and add the new supplier as an additional supplier for the Widget in the products-suppliers table. You don't want to change THE supplier for the Widget from ACME to The Widget Co, because next time you might want to go back to ACME. You design the system to provide you with the flexibility that you actually need in your business. The system analysis is most important so hopefully you get it right (or nearly right) the first time. You can designate one of the potential suppliers as the preferred supplier, or have a supplier preference order. Whatever you need to do the job.
 
Ok well then I change it again :).
But how would you set up the Purchase Order in relation to those tables?
 
Ok Thanks Pat,

I will put something together and post the layout maybe you could have a commant about it then see if it is as you think.

Cheers
 
This is how I had the structure a while ago.
For better understanding I placed the English Table Names on top of each table.

Sorry for having it still named with my old convention but just so to give you an idea of how I had it set up.

Units and PackagingUnits are used so you can have have prices based on the Packaging Units

For example:
Units = Liter, Package, Hour, Piece,
PackagingUnits = Bottle, Canister, Box, Barrel

I buy a product

BaseCategory = Chemical
Manufacturer = Buzil
Description = Spezial Cleaner
BaseArticle = T201

The above Article can be bought in different Units like
1 Liter
10 Liters
200 Liters

This Article can be sold by different Suppliers
Supplier = AB
Supplier = ABC

Supplier AB sells 1 Liter, Bottel T201 for 8,99
Supplier ABC sells 1 Liter, T201 for 10,55
Supplier AB sells 10 Liter, Canister, T201 for 60,99
Supplier ABC sells 10 Liter, Canister T201 for 75,88

So if I use this setup then it would mean I need to have all References in those tables which then blow up the database.
But it would be very flexible in terms of using the right packaging units and compare those prices for the cheapest.

And buy it then where I get the cheapest price.
 

Attachments

  • StructureArticles.JPG
    StructureArticles.JPG
    221.6 KB · Views: 157
hmm ok I understand Pat.

But I guess in that case it is to much anyway.
I guess I just have the junktion table and then work from there as suggested above.

So you would work with a Structure like this below the SupIDRef ist red crossed out so I will delete it after.
Would you then Link ProductSupplier to PurchaseOrders ??

I really need to sort this out and turning always in the wrong direction...

Help would be much appreciated.

Cheers
 

Attachments

  • StructureArticle_02.JPG
    StructureArticle_02.JPG
    64.8 KB · Views: 142
Sorry to be a pain guys,

just updated the Relationship and was hoping to get some feetback.
At present I have Products and SupplierProducts nearly the same just for the sake of getting all Data into the Database.

Marked as red is what I believe could be deleted.

Would that be ok like this? And what should be added in order to be able to create Purchase Orders and Sel Price and PurchasePrice?

I did not quite understand how Pat ment it.

Sorry
 

Attachments

  • StructureArticle_03.JPG
    StructureArticle_03.JPG
    114.6 KB · Views: 143
Hi again,

sorry for the late responds.. Had to sit back and think about the structure a bit more.

I changed Products to Parts which is more appropiate as we receive Prices from Suppliers for SpareParts.

Further more I have included ModelParts as a linke Table to Parts and Models

Each Model requiere Parts for Maintainence or Repair,
Parts could be used in different Models thats why the Linked Table ModelParts.

Also I did include PartGroup as a linked table to Group and Parts.
Again the Parts could belong to different groups.
For example a part could be a "Clamp for certain adapter"
So the Part would belong in Group "Clamps" and "Adapter"

Attached is the updated version of my Structure.

Maybe and it would be much appreciated if Pat or someone else take a look at it the naming convention should be also
match your liking :)

Purchase Orders are left out for now as I am wondering if the current Structure would be ok now or do I need to change something?

Cheers
 

Attachments

  • StructureArticle_04.JPG
    StructureArticle_04.JPG
    84.7 KB · Views: 138
Hi,
thanks Pat but this drives me nuts this model..

Not sure how many times I tried in different ways of getting it right but still no luck.
Drives me nuts.

1. The Manufacturer is also the supplier!
2. Parts are for Maintainence Work, Parts come form Manufacturer/Supplier
3. Parts are needet to complete the Maintainence work.
4. Parts can be used on one or more Models
5. A model can have different Types "Model A" with Type of "Round", "Half Round", "6 Corners",....
6. Models have functions " "Model A" has "Whirl function", "Sound System", "Steam function",...
7. Models have issues .. "Steam function defect" need repair, or replacement or cleaning or new Parts in order to fix it.
8. We need to find easily the parts for each Order/Project so we can create an Offer for the Customer or to place an Invoice
9. Models could also be sold to a customer.
10. Find Models and prices so we can sell it with a markup
11. Find Parts or Models easily.. to place an Order or an Offer or a Delivery
12. Purchase Models or Parts
13. Parts can be used in more then just one Model!
14. Find all Parts according to what Model needs Maintainence

Discount amount would not be associated with a supplier unless you are talking about YOUR discount.
Yes it is our Discount to the Suppliers.
Each Supplier could have a different Discount rate.
Or change the Discount rates.

Sales price is also tracked at the supplier level. You either automatically calculate a markup or you enter the sale price specifically.
I created for that reason a Markup Table with Precentage Rates.
Table "MarkUp"

We are only seeing some of the tables in the database so please tell us what part of the process we are looking at.
Not exactly sure what you mean by that?
I thought it is clear with the table Names?
Project = Order we receive! I called it Project as it manly or mostly are Projects we are working on.
Project means we are working on Maintainance Work on Models at a particular Address.

Attached another try for the Structure.
it is not complete yet as I am very nervous of having it wrong again.

So is it so far ok and how would you tackle down the "Supplier Parts"?
And have that linked to the Purchase Orders or is that also wrong again?


Hope someone can help as I really need to get that finished.

Many thanks

Albert
 

Attachments

  • StructureArticle_05.JPG
    StructureArticle_05.JPG
    169.7 KB · Views: 141
Alright, your business repairs stuff using parts you can obtain ONLY from the manufacturer??
Yes more or less. Generic parts like nuts and Bolts or washers could be bought somewhere else to in a Warehouse or something like that. But not really relevant in that case.
You haven't actually defined what business process you are trying to automate.
Using your example of your Honda :) : You bought the Hoda from a dealer, after a while that poor Lady does not start anymore. You are call the Dealer and tell him about the Problem.

The dealer is to bussy to look at this or does not repair it. So he calles us to fix the poor Lady on the weekend.
The Manufacturer sends me an "Service Order" about what brand it is "Honda", what Type it is "CBR 900rr" the issue "Starter defect", tells me who the Customer is and where the "Customer Address is"

Also is a billing code to tell me who needs to pay for the costs of this repair.
If the "CBR 900rr" is still under waranty or factory waranty then I can send the bill directly to "Honda" if it is the dealers fault as he stuffed something up then the bill goes to "Honda Dealer Vienna", or if it is just something the customer had done then the bill goes to the "Customer"

Therefor I have a BillingCode table to let me register those type of "BillingCodes".

Also there are just private Customers calling and wanting a Service for their "Honda" :) .. so we go and do also that.

Models have different Types . Like a Car which has 5 doors or 2 doors or Caprio.. Still the same "Make" but not the same "Type".
So the parts are mostly the same but there wont be 5 seats in the 2 Door car.

This system needs to be able to fine "Already" repaird or maintaince work done in the past so we can make an Offer accordingly.
So sometimes we need to give the customer an Offer frirst before we can do the work.

Finding parts is essential to give the correct Offer. As there could be steam functions or or soundsystems or whirl functions and those parts can be expensive and nowadays those prices can change quickly.

Regarding the Prices of our work it is depanding on distance mostly "flat rate" for travel.
Work can be both in hourly rates or in flat rates depanding on what needs to be done.

Maintaince work is done once a year so we need to record when the next duration is when we need to contact the Customer for the yearly Maintainace.
Perhabs give him a new price as parts went up. Or the petrol prices are 4 Euros a Liter. So the prices need to be updated for a new Offer.

On site we like to give the Customer work what has been done. Like a delivery slip kind of.

Work has been done "Fixing bath tap as it was calcified or parts replaced or Parts fixed.

Once that is recordet I like to send a Invoice of what has been done.

Models as such is mainly not sold but if we record the prices it would not be a problem do do so in a Customer is require an Offer.

Models could be bought from other Suppliers not the Manufacturer it self.

Hope that is a bit more clear?

Attached another try of the Schema

Is there an existing application or several applications that you are combining?
No there is no existing system well a bought one but from that system I just got the customers out nothing else.
The system must handle all kind of business intelegent to work with models parts, Customers, billing, quotes and so on.
 

Attachments

  • StructureArticle_06.JPG
    StructureArticle_06.JPG
    255.1 KB · Views: 128
Last edited:

Users who are viewing this thread

Back
Top Bottom