Dimension

NavStudentNavStudent Member Posts: 399
Hello
I would like to get your opinion about Dimensions and how it's implemented in Navision.

Pros.
No modification required for new fields that need to flow to GL.
Account Schedule Reporting.
Analysis by dimension


Cons
Posting is slower
Size of db.
Synchronize code that is messy. The same info is two places.
Not fully implemented. (Discount Gl Account No not get any dimensions)
COGS dimension cannot be setup because of adjust cost routine.
Most companies misuse and don't set it up properly.
Setup is not mandatory and people forget.
Nobody has ever used Posted Document dimensions for reporting.


So my question is if you would implement Dimensions how would you do it, or would you do it at all?

The whole idea of putting default Dimension doesn't make sense. If the data is static then the reports and analysis should get the info from Default dimension table, the dimension should flow all the way to 10 tables. The only thing that should flow to the transactions is transactional dimension.

If you have experience with other ERP systems, I would like to know how they've implemented better.

As far for reporting purposes, it should be done OLAP cubes where you can slice and dice the information.
my 2 cents

Comments

  • Alex_ChowAlex_Chow Member Posts: 5,063
    I agree with you in regards to Dimensions. It's a very good demo tool, but it's not very practical for everyday use.

    I typically implement it if the customer requires departmental analysis, costing/profit center analysis, etc. Basically, anything that they have to categorize into different G/L accounts in their old system.
  • kinekine Member Posts: 12,562
    Main reason why dimensions are part of the ledgers entries is the history. If you need change e.g. department on some customer, you need to keep the history for old value and just new entries to post with new value. It is why just default dimensions is not enough.

    Sometime the dimension is changed in particular case (e.g. order) and you need to keep that change -> dimensions on entries.

    Doubling the dimension into entry and related table is a little "problem". Yes, it is not good, but it has own history - in 2.60 there were no dimensions. Just two fields - department and something other I forgot. These two fields were than redone as first two global dimensions. It is why just these two fields are part of entries. And second thing is, that most companies needs just two dimensions. But to have possiblity of "infinite" dimensions (which sounds good for new prospects) the related table was needed...
    8)
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • AdministratorAdministrator Member, Moderator, Administrator Posts: 2,499
    [Topic moved from Upcoming version NAV 6.0 to Navision forum]
  • NavStudentNavStudent Member Posts: 399
    kine wrote:
    Main reason why dimensions are part of the ledgers entries is the history. If you need change e.g. department on some customer, you need to keep the history for old value and just new entries to post with new value. It is why just default dimensions is not enough.

    Sometime the dimension is changed in particular case (e.g. order) and you need to keep that change -> dimensions on entries.

    Doubling the dimension into entry and related table is a little "problem". Yes, it is not good, but it has own history - in 2.60 there were no dimensions. Just two fields - department and something other I forgot. These two fields were than redone as first two global dimensions. It is why just these two fields are part of entries. And second thing is, that most companies needs just two dimensions. But to have possiblity of "infinite" dimensions (which sounds good for new prospects) the related table was needed...
    8)

    The first issue can be solved by OLAP cubes. Or You can a table that keeps track based on date. So only one record instead of millions.
    Second a lot of customers do want to change the history, and there is no way to do that right now.

    Second, the history reason makes sense, but they could have made them as flowfields.

    Third, they whole idea of unlimited dimension is stupid. They could have created 10 dimension and be done with it. If somebody needed more, then you would modify the system. The data would reside in the same table.
    No need to create analysis View table, which is limited to 4 dim at a time.
    my 2 cents
  • NavStudentNavStudent Member Posts: 399
    [Topic moved from Upcoming version NAV 6.0 to Navision forum]

    The reason I wanted this in that thread was that I wanted to mention that the new client should be able to connect and to OLAP cubes and and you could run sql reports etc without knowing it. You don't need a separate BA client. There is no reason for it.
    my 2 cents
Sign In or Register to comment.