Archive for the ‘tips’ Category

Usually these are the signs of coming disaster in an EP system:
1) too many dlists of the same "dimension", some elements thrown out for cutting volumes, calculating or not calculating smth, and you have all seen them laying around just because they seemed to consistent at the time of creation.
2) manually maintained access tables and elist's
3) manual allocation in dlinks

Such systems are consistent at the moment of project inception, but as time flows, people change, one or more dlists don't get updated (well, they kinda lay in another lib, are named differently or smth), one or more AT doesn't get there in time and etc.
And in some period of time (rather short) you end up holding a trembling scycraper by rapidly inserting straws. Terrible, ain't it?
This is a common situation in my practice. It's just because it's so easy to build simple things in Analyst that you miss the point where those simple things have formed one of Mandelbrot's set's.
Nowadays, with "we do all in Contributor small interlinked applications" motto it's more than serious. It's hard to find an outdated dlist in Analyst, while digging through macro, but 10 times as hard to debug a sequence of admin links with respect to access tables used.

There are really some ways to avoid these things. There's no 100%-proof recipes, just some common sense.

Let's go step by step, starting from dlist's.

Handling Dlist's

The main Idea: All dlist, forming one dimension should be maintained through one d-cube.
This is very good with hierarchical dimensions, such as products, so we'll use them as example.

Add as much attributes as you need. So if you're gonna do a dlist with not all products for application Z, you just add a column, mark required elements and make it an import link for a dlist.

The sub Idea: All dlist updates and sequencing application updates should be run by a single macro.

So after you create such a dlist for app Z, you add it's @DListUpdate in the UPDATE_ALL_DLISTS_MACRO and add an app Z sync & gtp in there. Therefore -- 1 place to change, 1 button to trigger all changes.

Problems

1) No way to import calc options. Seriously, I don't why it is that hard to do, but you just can't do it (if anybody knows -- drop me a line). So Accounts dimension is hard to handle.
2) No simple way to write formulas. You can write them in text and import Formulae attribute, but adding "{" is annoying.

Some tricks

1) You can use all those DlistItemImport (from cubes, list, odbc's, fm packages) macros instead of import links
2) If you need some sorting, some non-trivial (for Analyst) text operations like spliting\joining strings, adding codes and that stuff -- you can export the cube to a txt file, put an odbc source on it and have a full-blown SQL-92 with CONCAT,SPLIT,LIKE, ORDER and all that nice stuff.
3) You can have a more custom table like

and do all the input in cube, w\o changing the list

2 AT and elists

Main Idea: Have a single source (mentioned above) and do everything automatically.

AT and elists can be (and should be) loaded from csv files.
If you add a column "responsible" in the cube above, and calculate a column with "access level" on base of "responsible" (Yes = Write, No = No Data) -- there you go, start loading the thing up.
3,4 dimensions are okay in a separate AT cube, but it should be a cube, not adding rules in applications. It's just that since you'll have some technical applications, you'll have to repeat those AT's more than once -- and that's a dead-end.
Elist are the same, you can export a dlist as elist since 8.1 and enjoy the result, but I'd rather create all those columns myself.

Tricks
1 Maintaining the same Elist Id allows you to change Display names w\o loosing data, so you can work around that.
2 Play around calculating access level. There was a nice topic on cognoise about automaticaly closing past months. So easy to do with @Time BiF.

3 Manual allocations.

Never. No way to find problem afterwards.

Do a CashFlow Account to P&L Account columns in item descriptions and use them as allocation cubes, use allocation tables when desperate.

I'll add more as I remember, comments welcome.