Sub Collection within a Sub Collection

Hey All,

Trying to create a form like a quick Order entry style window for Vendor invoices - and the corresponding Purchase Orders that they match off too.

However, Since I realize that one invoice line can have multiple Purchase Order lines associated with it, I needed to switch from a 1-1 approach to something that looks like the diagram below, where I can see all my unvouchered invoices in a grid on the side, and then on the form I can see the Invoice Lines and then the Purchase Orders that are against them. Hopefully the diagram makes it clear.

Can anyone tell me if CSI Supports nesting of Sub Collections on a form? Or if that isn't the case, suggest a workaround so that I can acheieve the same functionality as the method I've described?

Thanks,

Jamie.

Find more posts tagged with

Syteline Development

Accepted answers

Legacy Contributor

I stand by my earlier recommendation. The filtering for the Matched PO lines is NOT done on the IDO, it is a grid level filter applied using additional properties from the current invoice line.

You do also need additional logic if reading through the Matched PO lines for an Invoice header in code, it will not be aware of the current invoice line unless you tell it to be aware of it.

All comments

Legacy Contributor

You should be able to access it by typing the value of the subcollection as follows:

object.SubCollection1PropertyName.SubCollection2PropertyName

The toolset will not let you pick it from a drop-down box.

Properties in the resulting grid would need to be entered as:

object.SubCollection1PropertyName.SubCollection2PropertyName.PropertyName

Again, the toolset will not let you pick it from the drop-down box.

Legacy Contributor

As an alternative, you could always do a custom-load method to populate the grid. The IDO would contain unbound properties for the columns returned from the custom-load method, and you would pass the key fields to the CLM as parameters that would filter the PO Line record set to just the lines you want to show for a given invoice line. I personally find the CLM's to be faster performing, and they can be more flexible and can be changed more easily than nested subcollections. The only trick to them is remembering to refresh the collection for the grid containing the CLM when the parent grid selection changes.

Legacy Contributor

Last time I checked Sub collection of a subcollection wasn't a thing (though I am a bit rusty so maybe it has changed).

You can however have InvoiceLines and MatchedPOLines as a sub-collection of the InvoiceHeader, providing you can make the association with SQL from the invoice header to the Matches PO Lines (even if you need to join via the invoice line).

This would allow you to present both InvoiceHeader subcollections, and filter the grid containing the MatchedPOLines by the current record for the InvoiceLine. This technique works quite well and to the user it will behave like a subcollection of a subcollection.

There may be other ways to do this, forms within forms for example, but best to steer clear of that for this example.

Legacy Contributor

Hi Tim,

Thank you for your response and confirming that this could be done.

I had tried to do this originally but interestingly enough I was finding that the start of the subcollection string was dropping off. i.e object.SubCollection1PropertyName.SubCollection2PropertyName was just shorted to SubCollection2PropertyName when i closed the pop-up.

Where I managed to get it to work was manually typing in the link by properties as SubCollectionProperty1.PropertyName = PropertyName.

I'll be sure to look into a CLM Solution should this one fall through!

Cheers,

Jamie.

Legacy Contributor

Hi Tim,

Everything looked like it was working well until I started populating Data. Seemed that I may have spoken a little too soon.

The sub-sub collection refreshing wasn't working as expected. changing Invoice line did not refresh the PO-Invoice Line Collection and adding data presented a bevy of object reference errors.

At this stage I'm looking to move towards having a single primary IDO Collection (The invoices) and then a secondary IDO Collection (Of invoice Lines) and then the sub collection PO-InvoiceLines attached to that.

I'll have to manually write the logic around the primary and secondary collection joins.

Is there anything you can think that I might have done incorrectly to produce these errors (Ideally I would still like to get it working as a sub-sub collection. I don't think a CLM would work in our instance because we want to be able to manipulate and save the data in the sub-subcollection on the fly.)

If not, is there any particularly easy way you could think of to join a second and primary collection on some of he primary IDO Collections Properties? At this stage my best idea is to have variables representing the join properties and pass those through the secondary collection filter. (I don't think you can specify a property from another IDO in a secondary IDO's filter?) Then have custom events for 'on filter' etc.

Cheers,

Jamie.

Legacy Contributor

I stand by my earlier recommendation. The filtering for the Matched PO lines is NOT done on the IDO, it is a grid level filter applied using additional properties from the current invoice line.

You do also need additional logic if reading through the Matched PO lines for an Invoice header in code, it will not be aware of the current invoice line unless you tell it to be aware of it.

BradleyBrown

Just as another option, although Lee's suggestions are very good, you could use a secondary collection for your "Matched PO Lines" grid and use form variables to set a permanent collection filter. Using StdObjectSelectCurrentCompleted on your Invoice Lines sub-collection you can set the filter variable(s) to whatever values you would need to filtering the collection accordingly.

One side-affect of using variables as permanent collection filters is that when they are updated, the framework takes notice and refreshes the related collection automatically.

This does introduce the need to handle collection operations manually, saves for example, but those are typically fairly easy to setup.

Legacy Contributor

Sorry for the late reply Lee,

After enough trail and error with trying to get the sub-sub collection working I did take your advice. Already it works a hell of a lot better than what was functional via the original approach. Definitely a few gotchas with regards to collection refreshing on data change, but they've been easy enough hurdles to leap.

Thanks for your suggestion!

Cheers,

Jamie.

VID003_APIV_Adding a new Tab and a View.zip

Copyright © 2025 Infor. All rights reserved.