Tables, Fields, GL, etc... (continued)

[Alejandro Imass]

--- Derek Neighbors <address@hidden> wrote:
> Alejandro,
> 
> > Which table definition document should we follow:
> > 
> > The modue design proposal
> 
> This one. :)  The other one needs to be deleted.

good. I was focusing on this anyway.


> 
> That should be in the proposal if its not that is
> mine or Reinhard's
> fault. :)  As we have discussed it several times. :)
>  But yes we do NOT
> want any kind of auto increment as its not portable
> or scalable on most
> dbs.  Rather we would handle internally through a
> seed table.
> 

OK. So in the model I will not bther w/ this issue,
since I guess the basic Interface definition for all
GNUE objects will have some methods like:
getpkey() and createpkey()

My model will only bother and define business-oriented
pkeys. BTW I already got a basic model for
inventory!!! :-)

I mean basic! I want to contruct a working proof of
concept with the BASIC Inventory Model that will
include componentes, objects and tables.

Once this is actually working, other people can jump
in very quickly to add code and functionality. I plan
for this to happen very soon. If we have a working
Inventory prototy, I would like to move on w/ you
(Derek) to Purchasing. I have a partly built model for
this. I'm sure we can tie our specs and create a
working prototype for Purchasing also.


> 
> Yes needs to be done.  No one else is working on it
> per say.  I started
> some of it in my purchase order proposal, but didnt
> get into details on
> it.  I see some issues with it.  Basically I feel we
> must be careful of
> module dependencies as I should be able to use your
> inventory system with
> my own CRM or my own GL etc... I have some ideas on
> this, but doing a
> contact system is part of that so sounds good. :)


OK. Gotcha. In general, anything not directly tied w/
Inventory will assume generic methods for interacting
w/ this information. Which can be inside GNUE or in
another system.


> Account Structures are holy wars.  I think we should
> define number of
> elements with elment lengths.  I work with VERY
> large system.  It has like
> 15 elements with each element having 5 slots (alpha
> or numeric)  Then each
> element has supporting hierarchy tables that roll at
> least 3-5 levels
> deep.  I am thinking something similar would be be
> prudent.  Though I can
> see issues as that is really only GL side.   
> 
> I just URGE all out there that the idea of GNUe is
> that its flexible, so
> if there are several good ways to do accounting for
> different institutions
> that is good case for packaging/templating by
> industry. :)


OK. This has to be worked on a little further. I will
think about it and let you know. 

IDEA:

Perhaps GNUE should have a centralized chart of
accounts that is independent of the GL or
Finance/Budgeting system in use. This chart of
accounts will handle a basic definition (something
like a 30 segment indefinite chars) and would have a
valid combination table, and basic validation
routines.

This centralized chart of accounts could be used by
any module as it would have basic validation routines,
so that each module can report specific cost elements
and stuff.

The centralizaed chart of accounts will be fed
periodically by the GL and Finance (predominatly
Finance or Budget since these account combinations
will be alot more than just a GL account. they will
include stuff like cost-center and cost-element,
sub-account, etc. )system in use, but every GNUE
module will have one-and-only accounting view, which
is this centralized chart-of-accounts.

The centralized chart of accounts system would mannage
the appropiate translation from GNUE
account-combinations to Finance and GL accounts.

Please if you would like me to expand on this let me
know. 



> 
> Derek Neighbors
> GNU Enterprise
> http://www.gnue.org
> address@hidden
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/