Re: Redeveloping the system - was Thoughts on payment handling in 1.4.x

["David Bandel" <..hidden..>]

On 4/29/07, David Tangye <..hidden..> wrote:
> On Fri, 2007-04-27 at 19:47 -0700, Chris Travers wrote:
> > Actually, I would slightly quibble with this point.  Rather than
> > define terms precisely (since natural language is descriptive rather
> > than prescriptive), it is a good idea to discuss what we mean by what
> > we say and challenge eachother to find better words.  But we see the

Folks,

I think we're picking nits that aren't really addressing our needs.
Sets/members/tuples, tables/columns/rows, financial/legal.  Let's put
all this aside for a moment.

What we (hopefully) are trying to do is design a system to allow us to
track things of interest to us (trees).  So we need to define in needs
in terms of what it is we want to track.  I don't care if an order is
a legal, financial, or both transaction.  I need to know what I want
to track regarding the transaction. Defining all the separate items I
want to track and the relationships between them will help me decide
how to build:  the database, the input screens, the output screens
(the forest).

I want to be able to enter requests for quotes to vendors (who, what,
quantity needed).
I need to enter quotes (who, what, quantity, price/discount, shipping)
I need to enter orders (who, what, quote reference, price, etc.) based
on quotes.
I need to enter inventory (what/quantity/serial # received) against an order
I need to capture back orders, cancel unfulfilled orders, etc.
I need to check vendor invoices against orders and inventory received
I need to create payables against invoices, then pay.
I need a shortcut for the above for CC/petty cash purchases

etc.

Knowing what the customers' requirements are (independent of them
being legal, financial, etc.), i.e., what needs to be captured, and
what needs to be referenced against another capture, will tell me how
to create the backend.  Then I just need to design a pretty screen to
display/print/etc. that infomation.

For example:
We currently have vendors and clients.  Not sure why both.  I have
companies who are both (not all, but a few).  Some have one address
for everything (small business), some have different
addresses/contacts for different purposes (billing, payments, ship to,
etc.) with different names/addresses for each.  But to me, company A
is company A.  I have some AR from them, but possibly I want to
balance AP against the same folks (or not).

Once we have defined what we want to track and what relationships
those tracked items have with each other, we can begin to work on
something.  Again, few will care about legal vs financial, they just
want to track data.

Now, back to our regular scheduled program.

Thanx for listening.

David A. Bandel
--
Focus on the dream, not the competition.
           - Nemesis Air Racing Team motto