What type of relationships do i need?

[Connor55]

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?  

[poweractivate]

@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.

[poweractivate]

@Connor55 

Some more elaboration:

If One Inventory has Many Show, then the following is usually the result:

1. Inventory would be able to list the associated Show
2. The Lookup field is on the Many side actually. So the Show has only one Inventory. However, the Inventory can have many Show
   1. In other words, on your Show form, there is one Lookup field for Inventory
   2. However, two or more Show records could be referencing the same Inventory - hence, One Inventory, Many Show
   3. Thus, each Inventory record can have an associated view that "shows" you all the "Show" for which the Lookup field was set to that same Inventory

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:

1. It is the Show record, which would be able to list the associated Inventory
2. The Lookup field is on the Many side actually. So the Inventory would be the one that has only one Show in this case
   1. In other words, on your Inventory form, there is one Lookup field for Show
   2. However, two or more Inventory records could be referencing the same Show - hence, One Show, Many Inventory
   3. Thus, each Show record can have an associated view that "shows" you all the "Inventory" for which the Lookup field was set to that same Show

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.

[v-xida-msft]

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,

[Connor55]

@v-xida-msft 
@poweractivate 

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!

[poweractivate]

@Connor55 

You could attempt something like this:

1. One "Show" to many "Inventory" 
2. For Inventory, you have One "Inventory" to many "Barcode" - so multiple barcodes could be referencing same Inventory (the Lookup would be on the inventory)
3.  For your one-to-one, you could have a Field under "inventory" for a single barcode.
4.  You can have a "Two Options" Option set with two options: "Single Barcode" or "Multiple Barcode"
5. On the Inventory Form, you could use a Business Rule to decide the following:
   1.  If the Two Options field is set to Single Barcode ->
      1. show the single barcode field,
      2. clear any value for multiple barcode - then
      3. hide multiple barcode field
      4. set Single Barcode as required - then
      5. set Multiple Barcode as Optional
   2.  If the Two Options field is set to Multiple Barcode -> 
      1. show the multiple barcode field,
      2. clear any value for single barcode - then
      3. hide single barcode field
      4. set Multiple Barcode as required - then
      5. set Single Barcode as Optional

See if this works above for you.

[Connor55 · Accepted 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]

@Connor55 

---

@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:
  1.  If the Two Options field is set to Single Barcode ->
     1. show the single barcode field,
     2. clear any value for multiple barcode - then
     3. hide multiple barcode field
     4. set Single Barcode as required - then
     5. set Multiple Barcode as Optional
  2.  If the Two Options field is set to Multiple Barcode -> 
     1. show the multiple barcode field,
     2. clear any value for single barcode - then
     3. hide single barcode field
     4. set Multiple Barcode as required - then
     5. 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.

[Connor55 · Accepted solution]

@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!