So here's my scenario, I have 2 entities that need to work together. I have an event production company that has a large inventory of gear - different shows will call for different amounts and types of inventory. I need to be able to keep track of things coming in and going out.
Shows
- Show name, date, client, etc.
Inventory
- Manufacturer, part number, owned stock, in stock, product ID #, barcode #, etc.
Is this a many to many relationship? How would you go about building a list of inventory that would be applied to a show name?
Solved! Go to Solution.
Thanks for the article @v-xida-msft
https://powerapps.microsoft.com/en-us/blog/one-to-many-relationships-for-canvas-apps/
Looking at this - I think my issue is I need another entity. It seems like the best way to do this is to have:
Show Details
- Show ID
- Show Name
- Show Date
- etc.
Inventory
- Manufacturer
- Part #
- Product ID
- Barcode
- In Stock Quantity
- Owned Stock Quantity
- etc.
Show Inventory
- Show ID
- Product ID
- Quantity
- Rental Price
- etc.
Relationships:
Inventory has a 1:n relationship with Show Inventory via the "Product ID"
Show Inventory has a n:1 relationship with Show Details via "Show ID"
I think this is the right solution - I'll update this thread if I run into an issue with non-serial vs serialized items.
@poweractivate
From my research, you're right. The non-serial vs serial items does pose an issue. The solution is a many to many relationship - since one item can be related to multiple Show Details entity.
Now there's the issue of keeping track of stock. I'll tag you in a new thread I'm adding for this.
Thanks for all your help so far!
@Connor55
One Inventory has Many Show to our understanding.
A one to many relationship, with Inventory on the one side, and Show on the many side
However, if Many to many came to mind first, maybe your scenario may be more complex, maybe you need more Entities that have 1:N or N:1 in between the model in your case, so you may need to think about that.
@Connor55
Some more elaboration:
If One Inventory has Many Show, then the following is usually the result:
Does the above fit your case?
If you invert the One to many, then it is as follows:
If One Show has Many Inventory, then the following is usually the result:
Does neither of the above work? Then you may need to recheck your model and think it through more.
If one of the above does work, then choose the one that best fits your scenario.
Hi @Connor55 ,
Could you please share a bit more about your scenario?
Is a show name related to multiple inventory records on your side?
If a show name is related to multiple inventory records, but a inventory record could only be bind to single one show name, I think the "One-to-Many" relationship would be better in your scenario.
On your side, you could consider create a "One-to-Many" relationship from your Shows Entity to your Inventory Entity. Then there is a LookUp field generated automatically within your Inventory Entity. After that, you could consider filter your Inventory records based on the generated LookUp field.
Add a Gallery (ShowsGallery) in your app, set the Items property to following:
Shows
add another Gallery control (InventoryGallery) in your app, then set the Items property to following
Filter(Inventory, LookUpField.IdentifierColumn = ShowsGallery.Selected.IdentifierColumn)
Note: The LookUpField represents the generated LookUp field in your Inventory Entity based on the "One-to-Many" relationship.
Please check and see if the following blog would help in your scenario:
https://powerapps.microsoft.com/en-us/blog/one-to-many-relationships-for-canvas-apps/
Best regards,
A barcode in this case is a unique number assigned to an item.
A product ID is a number that refers to a specific model of an item.
There are two types of Product ID's:
Serialized - multiple barcodes refer to the same Product ID
Non-serialized - a single barcode refers to a single Product ID (instead of multiple barcodes, a fixed quantity is attached)
The one "Show" to many "Inventory" works for serialized items, but the non-serial items will share different shows at different quantities.
My solution was to create a new entity for each show - having a one "Show Entity" to many "Inventory" relationship - a column named InStock would update whenever an item is added to a show.
HOWEVER, I don't know of a way to automate adding an entity.
Looking forward to your thoughts, thank you!
You could attempt something like this:
See if this works above for you.
Thanks for the article @v-xida-msft
https://powerapps.microsoft.com/en-us/blog/one-to-many-relationships-for-canvas-apps/
Looking at this - I think my issue is I need another entity. It seems like the best way to do this is to have:
Show Details
- Show ID
- Show Name
- Show Date
- etc.
Inventory
- Manufacturer
- Part #
- Product ID
- Barcode
- In Stock Quantity
- Owned Stock Quantity
- etc.
Show Inventory
- Show ID
- Product ID
- Quantity
- Rental Price
- etc.
Relationships:
Inventory has a 1:n relationship with Show Inventory via the "Product ID"
Show Inventory has a n:1 relationship with Show Details via "Show ID"
I think this is the right solution - I'll update this thread if I run into an issue with non-serial vs serialized items.
@Connor55 wrote:Relationships:
Inventory has a 1:n relationship with Show Inventory via the "Product ID"
Show Inventory has a n:1 relationship with Show Details via "Show ID"
I think this is the right solution - I'll update this thread if I run into an issue with non-serial vs serialized items.
Connor, you are likely right for your case.
You have the "N" in the middle Show Inventory
1(Inventory):N(ShowInventory):1(ShowDetails)
That means in your case,
1. In your Product ID, each ShowInventory can be tied to one Inventory, so the lookup field (Product ID) is on the ShowInventory record form for associated Inventory record.
Consequently, an Inventory record can have a new associated ShowInventory record created from that Inventory form (equivalent to creating a new ShowInventory and populating the lookup field (Product ID) with the Inventory it was created from).
Then, any one Inventory record can have one or more ShowInventory
2. In your Show ID , each ShowInventory can be tied to one ShowDetails, so there is another lookup field ( Show ID ) on the ShowInventory record form for associated ShowDetails record.
Consequently, a ShowDetails, record can have a new associated ShowInventory record created from that Inventory form (equivalent to creating a new ShowInventory and populating the lookup field ( Show ID ) with the ShowDetails record it was created from).
Then, any one ShowDetails, record can have one or more ShowInventory
However, regarding your barcode, we wonder if now our previous suggestion becomes relevant at this point (in addition to what you have implemented so far) for the Serialized versus Non Serialized inventory.
@dynamicsedge wrote:
- For Inventory, you have One "Inventory" to many "Barcode" - so multiple barcodes could be referencing same Inventory (the Lookup would be on the inventory)
- For your one-to-one, you could have a Field under "inventory" for a single barcode.
- You can have a "Two Options" Option set with two options: "Single Barcode" or "Multiple Barcode"
- On the Inventory Form, you could use a Business Rule to decide the following:
- If the Two Options field is set to Single Barcode ->
- show the single barcode field,
- clear any value for multiple barcode - then
- hide multiple barcode field
- set Single Barcode as required - then
- set Multiple Barcode as Optional
- If the Two Options field is set to Multiple Barcode ->
- show the multiple barcode field,
- clear any value for single barcode - then
- hide single barcode field
- set Multiple Barcode as required - then
- set Single Barcode as Optional
Alternatively @Connor55 if you would prefer that 1:1 is not modeled as an attribute as in our original suggestion, and if you prefer that it must be a lookup, you could also instead have a setting in the Barcode of Two Options - Serialized or Non-Serialized
Then you could write a CDS plugin that checks on creation of a new Barcode:
1. If the Barcode is Non-Serialized and associated Inventory is already associated with one Barcode that is being attempted to be updated, the change is rejected.
2. If the Barcode is already Serialized and is already associated with more than one Barcode, and the attempt is to change it to Non Serialized, the change is rejected.
3. If the Barcode is Non-Serialized and somehow it became associated with more than one Barcode, the model was breached and a critical error message should be displayed, and if this ever happens, then it was not implemented correctly.
4. It is possible to apply Business Rules directly on the Entity (not just the form) using the Entity scope under Business Rules - but we are not sure the above can be done as Business Rules (probably cannot) - whereas the original suggestion we had can be done without any complex plugins and using just Business Rules.
We think the plugin approach is more complex than the approach we said first. Therefore the approach we said the first time of modeling 1:1 as an attribute and doing it with Business Rules might be preferable.
@poweractivate
From my research, you're right. The non-serial vs serial items does pose an issue. The solution is a many to many relationship - since one item can be related to multiple Show Details entity.
Now there's the issue of keeping track of stock. I'll tag you in a new thread I'm adding for this.
Thanks for all your help so far!
The first Microsoft-sponsored Power Platform Conference is coming in September. 100+ speakers, 150+ sessions, and what's new and next for Power Platform.
User | Count |
---|---|
202 | |
98 | |
60 | |
57 | |
52 |
User | Count |
---|---|
257 | |
161 | |
87 | |
79 | |
68 |