This is a rant, I suppose, since there’s no changing the foundational structure of the Kinetic financial system now. But I wanted to spell out what’s kind of there just below the surface with any multi-entity implementation. (The stuff you only learn by accident long after you are deep into implementing.)
So, where I work we have
- 1 company (
Company
table) - 2 divisions
- 3 sites (
Plant
table)
Divisions… yeah.
So, what I mean is that in our company, inventory (for example) hits one of two accounts
- 1300.RID.00 (for site A and site C)
- 1300.PDC.62 (for site B)
RID and PDC are the “divisions” for us.
You say, “But that’s YOUR setup - not everyone’s COA is a 3-segment with division at the center.”
Well, OK, but it sure is assumed throughout Kinetic.
Division is somewhat of a half-implemented concept in Kinetic.
@LarsonSolutions and I hinted at this yesterday
“Division” kind of wants to be a site; it kind of wants to be a warehouse; it kind of wants to be above them both - in the same way that a Cost Set can encompass multiple sites.
I think that’s the clearest analog to Division, is Cost Set. And that’s what started this rant today.
I am trying to revise a BAQ I made for inventory aging. I need to consider two of my sites as one division - though they have separate transaction histories. That was OK, till I tried to tie in the (standard) cost.
This subquery is bad enough for a single site (plant). Now try to do this with 2 sites but they are both related to the same cost set. (You don’t have to actually weigh in; it’s just to make the point.)
I think this would be easier if there was a link to Division
(not a real table) and the cost sets tied to Division
, not the Plant
. Maybe. Ah, it might still be miserable.