Why do you have a specific field for the price in "Orders" when there is a price in the "Products" sheet? Isnt it better to take that value and if there is a discount or something happens to change that price manually? @16:01
Great question! I usually like to have a price at the product level and a manual price at the order (rather than a lookup), in case the product price changes later. You can set up an automation to automatically fill the order price using the product. This video explains a similar scenario ua-cam.com/video/AUrbR8K4KNs/v-deo.html
great demo thank you. I have used Airtable for several years but never to this extent. What if we took this further yet, and used this concept to help with costing parts ( IE: I can say to a potential vendor that I am projecting to sell X number of parts and try using that projection as a negotiation tool etc), and - by extension - to help with pricing products?
Great explanation. My ADHD brain thinks backwards from this. I start with the schema first and within the schema I start with the order of how life happens. I created a block for each task and then draw lines for what needs to be linked. I use Miro to plan the steps and what needs to be linked.
Hi Kareem - absolutely! If you want to see how many of a bundled product *could* be produced with your current part inventory, you need to create a formula in the Parts x Products table that calculates how many bundles each part could make based on the quantity needed per bundle and the existing inventory. Then you take the lowest number (limiting part), and you know how many can be made. If you make a pass at this and run into a roadblock, post some screenshots here and I'll give you some tips community.3rings.co/t/inventory-bundles/11
You could be pricing your products differently based on the size of the order. So if you order 1 unit it's priced $10, but if you order 50 it's down to $8. In this case it's better to keep the price on order-level rather than on product-level. Also, the product's price might be changing over time, and you wouldn't want your order price to change retroactivity
Do you mean that when it is sold, you lock in that price? If yes, check out this video where I show you how to do that: ua-cam.com/video/AUrbR8K4KNs/v-deo.html&ab_channel=JulianPost
@@julian_post no I want to have a fixed price that when I pick a particular product it automatically has that price I don't have to input it Manually and can I have a form that will work someone can just be updating the database by just using a form
This is really helping me set up my inventory correctly! At the end of the video, you reference showing how to ensure the current price matches the order price in real time, but I couldn't find the link. Where would I find this video?
How would you modify / handle this if your "sold products" included both products, and another layer down that were "bundles" consisting of different products?
Ah! So, like, bundles of bundles? One answer to this is actually to combine the Parts and Products tables into one. After all, a Product can also be a Part. Let's call the combined table Parts. Then, in the table that was called "Parts x Products," you have two links back to the Parts table. One link is called "Part" and one is Called "Product". Every record will have both filled out. The caveat to this system is that you can no longer use simple Rollups to track inventory. You need to "manufacture" inventory when you turn parts into products, or products into bundled products, to account for their transformation. Maybe some day I'll do a video on it, but if you need professional help in the mean time feel free to email me at the address in the video description! P.S. another good name for the Parts x Products table would be "Bill of Materials", an industry term.
@@julian_post I appreciate you taking the time to respond. I don't think we can afford you, but otherwise would get in touch! Thanks for doing the videos, I'll keep watching and racking up views for you.
Do you have a video on purchase orders with multiple products
Why do you have a specific field for the price in "Orders" when there is a price in the "Products" sheet? Isnt it better to take that value and if there is a discount or something happens to change that price manually? @16:01
Great question! I usually like to have a price at the product level and a manual price at the order (rather than a lookup), in case the product price changes later. You can set up an automation to automatically fill the order price using the product. This video explains a similar scenario ua-cam.com/video/AUrbR8K4KNs/v-deo.html
This video is so great! Thank you for sharing
Welcome! Happy building :)
great demo thank you. I have used Airtable for several years but never to this extent. What if we took this further yet, and used this concept to help with costing parts ( IE: I can say to a potential vendor that I am projecting to sell X number of parts and try using that projection as a negotiation tool etc), and - by extension - to help with pricing products?
Brilliant Julian. Many thanks for sharing. You should have 100's of views of this by now in my opinion.
Thanks so much! A nice comment is better than 100s of views :)
Very underrated content Julian, keep going, you are doing great
Thanks for the encouragement, Adrian!
Love this!
how do i add sizes to an item in my inventory? IE: red shirt size 10, 12, 16?
Thank you for sharing!
Thanks for watching 🤗
Great explanation. My ADHD brain thinks backwards from this. I start with the schema first and within the schema I start with the order of how life happens. I created a block for each task and then draw lines for what needs to be linked. I use Miro to plan the steps and what needs to be linked.
This is a great way to do it. When I’m doing work for clients, generally I work in the order you described as well
Hello Julian! Is there a way to have airtable, calculate how many bundled products you can sale based on current inventory?
Hi Kareem - absolutely! If you want to see how many of a bundled product *could* be produced with your current part inventory, you need to create a formula in the Parts x Products table that calculates how many bundles each part could make based on the quantity needed per bundle and the existing inventory. Then you take the lowest number (limiting part), and you know how many can be made. If you make a pass at this and run into a roadblock, post some screenshots here and I'll give you some tips community.3rings.co/t/inventory-bundles/11
Thank you! I will give it a try! @@julian_post
I think the price per product in orders table should be a lookup column which displays the price you assigned in products table.
You could be pricing your products differently based on the size of the order. So if you order 1 unit it's priced $10, but if you order 50 it's down to $8. In this case it's better to keep the price on order-level rather than on product-level. Also, the product's price might be changing over time, and you wouldn't want your order price to change retroactivity
Hiii Julian can I make the prices fixed for a particular product both for selling and cost
Do you mean that when it is sold, you lock in that price? If yes, check out this video where I show you how to do that: ua-cam.com/video/AUrbR8K4KNs/v-deo.html&ab_channel=JulianPost
@@julian_post no I want to have a fixed price that when I pick a particular product it automatically has that price I don't have to input it Manually and can I have a form that will work someone can just be updating the database by just using a form
@@julian_post thank you for replying me Juian
In this scenario, would you need to add Parts x Products record for parts sold not in a bundle? Always sell a Product never sell a part?
Correct! You'd want to create bundles of one for single products
This is really helping me set up my inventory correctly! At the end of the video, you reference showing how to ensure the current price matches the order price in real time, but I couldn't find the link. Where would I find this video?
I hadn't posted it yet, but it's up now! You can watch it here: ua-cam.com/video/AUrbR8K4KNs/v-deo.html
How would you modify / handle this if your "sold products" included both products, and another layer down that were "bundles" consisting of different products?
Ah! So, like, bundles of bundles? One answer to this is actually to combine the Parts and Products tables into one. After all, a Product can also be a Part. Let's call the combined table Parts. Then, in the table that was called "Parts x Products," you have two links back to the Parts table. One link is called "Part" and one is Called "Product". Every record will have both filled out. The caveat to this system is that you can no longer use simple Rollups to track inventory. You need to "manufacture" inventory when you turn parts into products, or products into bundled products, to account for their transformation. Maybe some day I'll do a video on it, but if you need professional help in the mean time feel free to email me at the address in the video description! P.S. another good name for the Parts x Products table would be "Bill of Materials", an industry term.
@@julian_post I appreciate you taking the time to respond. I don't think we can afford you, but otherwise would get in touch! Thanks for doing the videos, I'll keep watching and racking up views for you.