4 Replies Latest reply on Apr 5, 2012 4:55 PM by philmodjunk

    Parent Context Layout Issue



      Parent Context Layout Issue


      Updated See Second Post


      Hello All,

      I have looked and have been unable to find documentation on my issue; possibly because I am not asking the right question. Can some one people point me to the correct method or research material to implement this correctly (or is this just a limitation I am hitting?). I have attached a picture of my database relationship graph, partly censored for privacy.

      Everything is fine an dandy up-until I hit Purchase Orders, I have no problem in the child context to pull data from the parent. Most of my data entry is via drop down "cascading" menus which I would like to reproduce but from a parent context.

      I need a way to select multiple Requisition# as separate line items for purchase orders carrying with it all the p/n and job# data along with it (ie. quantity) and item data (ie. units) this is a very early build and the structure may change but I am trying to get the base system functioning.

      I found a work around by selecting preexisting PO# and tying them to Requisition# from the Requisition context but that means I have to create the PO# first, and I am more worried about the information not carried along  down to the Receiving and RMA tables. Having a parent in the chain seems to break the relationship flow. I could make PO# a child of Requ# but that would limit 1 item per PO which is not realistic for us. Every way I look at it, I don't see a way of escaping the issue.

      Context: Keep in mind this is more of a MRP (material requirements planning) system and not a method of accepting customer order; also Job# is a bit similar to a "lot" or "batch".

      Any help is very much appreciated!! Thanks!


        • 1. Re: Parent Context Layout Issue

          What layout are you on when you can't access the P/N data that you need to see?


          From a layout based on Receiving, the current record matches to a single Purchase Order record, but this record then matches to multiple records in requisitions--each with their own link to JobManager and P/NManager records. That is what would be expected, given the design of your relationships. You can access a specific related record via portal filters, GetNthRecord, or other means but somehow you'd have to determine which of those many records is the one you want to work with.

          What is not clear is what data P/N data you want to see and how you would distinguish amongst the potential list of many Requisitions records.

          • 2. Re: Parent Context Layout Issue

            Thank you PhilModJunk!

            On reading your reply I did some testing and found that this is actually a layout problem. The relationship flow is fine, I am striking-out all irrelevant info in the original post. I successfully flowed all related data down to Receiving and RMA.

            I have attached a screenshot of the two functions I wish to preform with a single layout. 1) Create a PO# associated with a serialized Primary Key and 2) Associate that PO# to one or more Requisition#'s.

            First of all, I was trying to associate Requisition#'s[variable] with PO#[control] from the Purchase Orders (Parent) context because it is within that context that I can create PO#. I found that I was unable to do this, so I attempted the opposite: associate a PO#[variable] with Requisition#'s[control] from the Requisitions (Child) context and was successful; The drawback here was that I was unable to create new PO#'s (__pk_PO) from within that Child context. This has got me feel like a dog chasing it's tail, I would leave it be but by having two separate functions with a human in between it may create errors.

            Help! Thanks in advance!!

            Some unrelated questions:

            1. Is there a way to make a field in a specific layout unable to be modified? Disabling modification in the table/field setting is not an option because I need it to be enabled in certain layouts and disabled in others.
            2. Using two values sometimes does not work properly, even if I set it to only show the value I want sometimes it refuses and only shows the other value I wish to hide. In some rare cases using a drop down menu will show the value i want hidden while the drop-down options shows the correct value I want visible. Fix? Suggestions?
            • 3. Re: Parent Context Layout Issue

              Why do you need both a __pk_PO and a PO# field?

              Can't they be one and the same value?

              "attaching a requisition to a PO#"?

              Don't do that. Use __pk_PO to link requisition records to PO's. A portal to Requisitions, if "allow creation of records via this relationship" is enabled for requisitions in the relationship, is all you need for that or a simple script can put the current value of __pk_PO into a variable and then create a new record in Requisitions, using set field to copy the value from the variable into the _fk_PO field.

              • 4. Re: Parent Context Layout Issue

                Answers to Unrelated Questions:

                1) On the inspector's data tab, you can use Field Behavior to deny access to the field when in browse mode.

                2) I had to read that one more than once before I figured out what you were asking. You are talking about value lists where you have values from two fields shown and the first field value is hidden?

                When you exit a pop up menu field, the second field value remains visible in the field. When you exit a drop down list field, the first field value is displayed. For pop up menus, there is one exception to that. If you later delete the record that supplied the value selected in that pop up menu, the field 1 value will appear in the pop up menu as there is no longer any way to access the field 2 value to display it.

                You can either stick with pop up menus or you can define a relationship (if you don't have one already) linking the layout's table to the table of values by the field1 values. Then you can place a field with access denied (see 1 above) on top of the drop down list and with a solid fill color. When you click on this field, the drop down list behind it deploys. When you select a value and exit the field, it disappears back behind the field2 field and you see the field 2 value displayed just like you do with a pop up menu.