Is a given invoice limited to a single distributor and thus you specify the distributor in a field in the Invoice record?
Or can a given invoice list products from multiple distributors and thus you select the distributor via a field in the Invoice Part record?
There is a single distributor for each invoice.
There are two approaches that you can use to set up a basic relationship based conditional value list (there are many other options possible):
1) Define a category field in Invoices. Set up a relationship to a new occurrence of products:
Invoices::Category = Products|CVL::Category AND
Invoices::Distributor = Products|CVL::Distributor
Your value list can list values from Products|CVL and if you select "Include only related values starting from Invoices", you'll get a list of products only from the specific category and distributor.
Draw back: You have to click outside the Invoice Parts portal to select a different category before you can select a product from a different catetory.
2) Set up a calculation field in Invoice Part that copies the value of your distributor field that you've defined in Invoices: cDistributor: Invoices::Distributor. Define your Category field in Invoice Part. Put this field in your portal row for selecting a category.
Define this relationship:
Invoice Part::Category = Products|CVL::Category AND
Invoice Part::cDistributor = Products|CVL::Distributor
Now make Invoice Part your "starting from" table occurrence
For more on Conditional Value Lists and alternative methods for picking a value from a list see these teaching files:
Each file has a number of different working examples along with detailed documentation on how they are set up and how they work.
Each item uses a checkbox for whether or not the product can be ordered from X location, created by a dynamic value list. Will this worth with that method, even though multiple checks will be used? I feel like what I originally tried was method number 2.
It should still work as long as the check box fields in products are indexed.
A check box formatted field stores the selected values as a list of values separated by returns. When a field with a list of such values is used as the match field in a relationship, you get an "OR" type relationship where records match in the relationship if any one of the listed values matches to a value in the corresponding match field on the other side of the relationship.
Say check box field is in a relationship like this:
TO::CheckboxField = TO2::Field
Say you've clicked two check boxes to get:
Then any records with
Apple OR Orange in the TO2::Field will match.
So, still pretty much the same thing, but I have been changing my form for adding items to be added NOT through portal, but through the form itself (The users said it was too annoying on their iPads to add items through the portal). So now, I have a button for adding the product to the portal, so I can do a check by script on add- whether or not the product will show. I tried again on adding distributor == distributor, but it just created empty lists. So now, just to try and make things a little easier (I guess) I can check on script. However, when I use 'distributor = distributor' through script, it fails still (I am using a dialog box that pops up only on fail).
The field does say 'indexed', and options say it is at 'minimal', 'automatically create indexes'.
This is not the same thing at all from what I can tell. But there's just enough info to tell exactly what you are attempting.
By context, you should use option 1.
But distributor == distributor looks like find criteria rather than a relationship.
I have tried option 1, and it does not work. The value list comes up with mixed results. 1 supplied shows all, then the rest come up with empty lists; even though select items are selected for all (I just randomly picked 5 items, and check all the check boxes for every supplier)
Please ignore the "genscoID/JohnStoneID; those are going away.
It turns out, that on my form for modifying/adding items, the piece for "availability"/"seller" was not changed to the correct field- so it was setting the values to "Category" instead, providing these problems. Option 1 does work now, along with the scripting portion (which is now tossed, since it is not needed)