This is a question that came up on the ITToolbox forum peopletools-l. I decided that it would be a good idea to flush out my answer in additional detail (and post it here). Interestingly, as I did my research, I discovered that how commitment control uses trees was more complex than I thought. I also discovered that one of my statements in my response was inaccurate.

Here is a link to the post.

Can you do it?

The answer to whether you can use them in GL is still yes, and the method by which you use them is the same as how you would use them elsewhere. For those who don't want to read all the way through my blog post that discusses trees, here is some background on winter and summer trees.

Winter and Summer Trees

The naming of summer and winter trees comes from whether they have leaves on them or not. So, just as with a deciduous tree, a summer tree has leaves and a winter tree doesn't.

The first question that may come to mind is "why have leaves in one type of tree, but not another?" The answer to that question is whether the hierarchy is logically separate from the items being organizaed by the tree. For example, in a position hierarchy, each position belongs at a specific place in the hierarchy, so there are no need for leaves. By contrast, in most department hierarchies, departments are rolled up into offices, regions, divisions, etc., which means that departments are the leaf, and the rollups are not actually departments (and are the nodes).

When these trees are used by products, such as nVision and Query, those tools understand how to gather the underlying information for subtotalling and filtering based on the tree type (the join for a winter tree uses the nodes for joining directly to the data table, whereas the join for a summer tree uses the nodes to identify the leaves to join to the data table).

Why would you want to use Winter Trees in GL?

This is a good question, because at first blush, most reporting is done against aggregations of chartfields in GL. However, there is one very good scenario where you may want to eliminate the leaves and have each node in the tree be a chartfield value in your ledger table: budgeting.

When you do budgeting, quite often it is just too cumbersome to budget everything at the lowest level of granularity in which you capture transaction data (i.e. your journals). If you make the decision that you will create summary accounts that represent different rollups in your hierarchy, then a winter tree will work for you.

The delivered PeopleSoft demo database has an example of a winter tree on accounts (and interestingly enough, it's called "CONTROL_BD_ACCOUNTS".

One thing to keep in mind, however, when having aggregate chartfields values that you use in your trees, is that they are real chartfield values that could have values posted to them unless you do something to specifically prevent that. The Financials developers have done exactly that for the budgeting scenario. When you set up a GL account, you can specify it as being a Budgetary Only account, which will allow you to post data into budget ledgers, but not actual ledgers for that account.

Spring Trees

I think it's also important to mention Spring Trees, because they are similar to winter trees in several ways (and this is something I got wrong in my answer on ITTOOLBOX). Strictly speaking, though, Spring Trees are summer trees.

This is because Spring Trees do have both leaves and nodes. However, in a Spring Tree, the Leaf and the Node attributes are stored in the same table and use the same field.

This is a relatively curious, because a winter tree would accomplish exactly the same thing, especially since the aggregate accounts (i.e. the ones referenced on nodes) are not duplicated on the leaves. I think the main reason for this is that the tree nodes themselves drive the commitment control rules for determining whether you have budget or not, whereas the leaves are the level at which the data is posted. However, it looks like I need to do a bit more research on this.

Labels: Tree_Manager