On 4/29/07, David Tangye <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-04-28 at 09:40 -0700, Chris Travers wrote:
> > Hi Ed;
> >
> >
> > > I can't help wondering if the current Quotes/Order/Invoice model isn't
> > > slightly too few states for some business.
> > >
> > > My model is: [snip]
> Its a bit
On Sat, 2007-04-28 at 09:40 -0700, Chris Travers wrote:
> Hi Ed;
>
>
> > I can't help wondering if the current Quotes/Order/Invoice model isn't
> > slightly too few states for some business.
> >
> > My model is: [snip]
Its a bit of a problem in a way, that the implied business operational
model
Hi Ed;
> I can't help wondering if the current Quotes/Order/Invoice model isn't
> slightly too few states for some business.
>
> My model is:
>
> - Customer calls and gets quote
> - Customer calls back and places order
> - Customer either hands over CC details on the phone or enters them into
> t
> Sales orders and invoices are both potentially legal documents.
>
> Invoices are financial transactions while orders are not.
>
> Again, information-wise they can still be part of the same physical
> layout, but the order will not have the financial component.
>
I can't help wondering if th
Chris Travers wrote:
> Hi David;
>
> The model was a vague one with only minimal items shown for
> illustration (hence the reference that the table model could be far
> more complex than mentioned).
>
> Most of the database design work is being done by Josh Drake, and he
> is an expert in such th
On 4/27/07, Gerald Chudyk <[EMAIL PROTECTED]> wrote:
> On 4/27/07, John Hasler <[EMAIL PROTECTED]> wrote:
> > Ed W writes:
> > > One area though that I think is likely to drop out is that sales orders,
> > > sales invoices and sales quotes are all special cases of the same object.
> >
> > Invoices
On 4/26/07, David Tangye <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-04-26 at 19:36 -0700, Chris Travers wrote:
> > On 4/26/07, Gerald Chudyk <[EMAIL PROTECTED]> wrote:
> >
> > > Are you planning total integration between accounting modules? I
> > > designed a gl like this once. The issues with ar an
On 4/27/07, John Hasler <[EMAIL PROTECTED]> wrote:
> Ed W writes:
> > One area though that I think is likely to drop out is that sales orders,
> > sales invoices and sales quotes are all special cases of the same object.
>
> Invoices are accounting transactions. Sales orders and quotes are not.
>
On 4/27/07, John Hasler <[EMAIL PROTECTED]> wrote:
> Ed W writes:
> > One area though that I think is likely to drop out is that sales orders,
> > sales invoices and sales quotes are all special cases of the same object.
>
> Invoices are accounting transactions. Sales orders and quotes are not.
I
Ed W writes:
> One area though that I think is likely to drop out is that sales orders,
> sales invoices and sales quotes are all special cases of the same object.
Invoices are accounting transactions. Sales orders and quotes are not.
--
John Hasler
[EMAIL PROTECTED]
Elmwood, WI USA
--
On 4/27/07, Ed W <[EMAIL PROTECTED]> wrote:
> Hi
>
> Can I respectfully suggest that you missed the point that David was making?
>
> Sybase wrote some great DB design books that cover this stuff really
> well and no doubt there are other books. But basically:
In general, the process is similar
On 4/26/07, John Hasler <[EMAIL PROTECTED]> wrote:
> Gerald writes:
> > Of course changing a transaction in this environment will become
> > impossible, making auditors very happy and end-users looking for ways
> > around the system.
>
> It is quite possible to create a reversing entry and mark it
Hi
> Most of the database design work is being done by Josh Drake, and he
> is an expert in such things and if he doesn't do it, I am sure he will
> provide some strong feedback on the data model. One of our major
> tasks is making the database design follow the relational model
> properly. This
Heck, I'd kiss him too. This is an eminently sane idea.
Cheers,
Richard (who hasn't yet started inputting data into his 1.2.4 test
system, but will do Real Soon Now)
Quoting Charley Tiggs <[EMAIL PROTECTED]>:
> I have clients that would kiss you if they could have that 'un! :)
>
> Charley
>
On 4/26/07, John Hasler <[EMAIL PROTECTED]> wrote:
> Gerald writes:
> > Of course changing a transaction in this environment will become
> > impossible, making auditors very happy and end-users looking for ways
> > around the system.
>
> It is quite possible to create a reversing entry and mark it
Gerald writes:
> Of course changing a transaction in this environment will become
> impossible, making auditors very happy and end-users looking for ways
> around the system.
It is quite possible to create a reversing entry and mark it so that the
transaction appears to have been changed to the us
Hi David;
The model was a vague one with only minimal items shown for
illustration (hence the reference that the table model could be far
more complex than mentioned).
Most of the database design work is being done by Josh Drake, and he
is an expert in such things and if he doesn't do it, I am su
On Thu, 2007-04-26 at 19:36 -0700, Chris Travers wrote:
> On 4/26/07, Gerald Chudyk <[EMAIL PROTECTED]> wrote:
>
> > Are you planning total integration between accounting modules? I
> > designed a gl like this once. The issues with ar and ap are fairly
> > clear; each transaction is a db/cr to a f
On 4/26/07, Gerald Chudyk <[EMAIL PROTECTED]> wrote:
> Are you planning total integration between accounting modules? I
> designed a gl like this once. The issues with ar and ap are fairly
> clear; each transaction is a db/cr to a few well defined gl accounts
> with a reference to customer/vendor
On 4/26/07, Chris Travers <[EMAIL PROTECTED]> wrote:
> Hi all;
>
> I have been thinking a great deal about the data organization of
> financial transactions for 1.4 even though we are not there yet. I
> think we can all agree we need to have a central table which tracks
> every financial transacti
I have clients that would kiss you if they could have that 'un! :)
Charley
Chris Travers wrote:
> The other thing this would allow would be for a general journal report
> (a description of every transaction in chronological order of entry)
> with payments appearing in the proper places.
>
> Bes
The other thing this would allow would be for a general journal report
(a description of every transaction in chronological order of entry)
with payments appearing in the proper places.
Best Wishes,
Chris Travers
On 4/26/07, Charley Tiggs <[EMAIL PROTECTED]> wrote:
> Chris Travers wrote:
> > Hi a
Chris Travers wrote:
> Hi all;
>
> I have been thinking a great deal about the data organization of
> financial transactions for 1.4 even though we are not there yet. I
> think we can all agree we need to have a central table which tracks
> every financial transaction and which other tables may j
Hi all;
I have been thinking a great deal about the data organization of
financial transactions for 1.4 even though we are not there yet. I
think we can all agree we need to have a central table which tracks
every financial transaction and which other tables may join to. I
would propose that thi
24 matches
Mail list logo
