Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/26/07, Ed W <[EMAIL PROTECTED]> wrote: > Unrelated to the original question, but I actually have a use for more > document handling. In my case I need to get some signed agreements > from each customer, which for various reasons have a bearing on their > tax status and hence need to be easi

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

> 2) Do we need document management capabilities in the software? > > I would vote "yes" for the second, though it may be some time before > we have it. There are a few corner cases where not storing the > document as the document itself could be problematic. > Unrelated to the original ques

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

Just adding a point about normalization here. On 6/21/07, David Tangye <[EMAIL PROTECTED]> wrote: > See below. > > On 6/22/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: > > David Tangye wrote: > > > Its not crazy at all. Its correct analysis. And its not necessarily a > > > case of duplicate data

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

Josh, On reflection, see my previous post about intersects. Your post arrived while I was writing it. I think Chris, you and I are in agreement in this: Invoice addresses cannot be changed. The intersects I described will help ensure that if each address, once linked to almost any entity, invoice

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

See below. On 6/22/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: David Tangye wrote: > Its not crazy at all. Its correct analysis. And its not necessarily a > case of duplicate data. Its a snapshot of an event whose information is > often represented by the same data values each time. That is

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

See replies below. Actually, the way it will probably work is that there is a location table which includes all address info, a table handling a many-many relationship of locations to contacts Almost: the intersect we need here is between the Address to Customer intersect (as per your descri

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

David Tangye wrote: > See responses below. > > On 6/21/07, *Stroller* <[EMAIL PROTECTED] > > wrote: > Its not crazy at all. Its correct analysis. And its not necessarily a > case of duplicate data. Its a snapshot of an event whose information is > often represented by

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

See responses below. On 6/21/07, Stroller <[EMAIL PROTECTED]> wrote: On 20 Jun 2007, at 22:57, Ed W wrote: > > I think we are all agreed that snapshotting the invoice is a > requirement. But: > > - lets assume that most invoices contain the same address time and > time again, > - hence we sta

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/21/07, Stroller <[EMAIL PROTECTED]> wrote: > > On 20 Jun 2007, at 22:57, Ed W wrote: > > > > I think we are all agreed that snapshotting the invoice is a > > requirement. But: > > > > - lets assume that most invoices contain the same address time and > > time again, > > - hence we start think

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/21/07, David Tangye <[EMAIL PROTECTED]> wrote: > I have followed this thread with amusement. We went through all this 15 > years ago, and I am sure others did 15 years before that. The answer is > still the same irrespective of the technology du jour. > > Without boring you all with pages of w

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/21/07, Stroller <[EMAIL PROTECTED]> wrote: > > On 20 Jun 2007, at 22:57, Ed W wrote: > > > > I think we are all agreed that snapshotting the invoice is a > > requirement. But: > > > > - lets assume that most invoices contain the same address time and > > time again, > > - hence we start think

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 20 Jun 2007, at 22:57, Ed W wrote: > > I think we are all agreed that snapshotting the invoice is a > requirement. But: > > - lets assume that most invoices contain the same address time and > time again, > - hence we start thinking about normalising that address record > rather than dup

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

I have followed this thread with amusement. We went through all this 15 years ago, and I am sure others did 15 years before that. The answer is still the same irrespective of the technology du jour. Without boring you all with pages of waffle: 1. In system analysis and design, logical and physic

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/20/07, Jeff Kowalczyk <[EMAIL PROTECTED]> wrote: > --- Ed W <[EMAIL PROTECTED]> wrote: > > contacts with a structured history trail > > (...) > > I think it's helpful to review the > > kind of "use cases" that I sketched out and perhaps dream up some more - > > I think it helps figure out if w

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

--- Ed W <[EMAIL PROTECTED]> wrote: > contacts with a structured history trail > (...) > I think it's helpful to review the > kind of "use cases" that I sketched out and perhaps dream up some more - > I think it helps figure out if we have got the model right if we see > that we can do all the o

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

Jeff Kowalczyk wrote: --- [EMAIL PROTECTED] wrote: +1. An argument could even be made that an invoice, once produced, should become an opaque blob of data. I can't think of any reason to modify a produced invoice. Any amending of an invoice should surely create a new, separate documen

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/20/07, Jeff Kowalczyk <[EMAIL PROTECTED]> wrote: > > --- [EMAIL PROTECTED] wrote: > > +1. An argument could even be made that an invoice, once produced, > > should become an opaque blob of data. I can't think of any reason to > > modify a produced invoice. Any amending of an invoice should

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

--- [EMAIL PROTECTED] wrote: > +1. An argument could even be made that an invoice, once produced, > should become an opaque blob of data. I can't think of any reason to > modify a produced invoice. Any amending of an invoice should surely > create a new, separate document? True, that rev

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

Quoting Shaun Laughey <[EMAIL PROTECTED]>: > +1 to Stroller - every good system I've used, designed or pleased to pay > for has had the invoice address and other details recorded against the > invoice not the customer. > > It may copy them from the customer at invoice time but after that they >

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On Wed, 2007-06-20 at 11:52 +0100, Stroller wrote: > On 20 Jun 2007, at 06:04, Chris Travers wrote: > > ... > > I understand what you are saying, but I still disagree. Instead I > > think we are talking two different things. > > > > 1) Invoices need to be entirely self-contained. They need to sto

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 20 Jun 2007, at 06:04, Chris Travers wrote: > ... > I understand what you are saying, but I still disagree. Instead I > think we are talking two different things. > > 1) Invoices need to be entirely self-contained. They need to store > all information required to recreate and track them. We

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/19/07, Ed W <[EMAIL PROTECTED]> wrote: > > Hi > > > I was with you up until you said "linked list" which isn't really > meaningful in this context. More likely you would have a list of > records which would have a valid_to attribute describing when they > were no longer used. > > > Well, I

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/19/07, David Bandel <[EMAIL PROTECTED]> wrote: > On 6/19/07, Chris Travers <[EMAIL PROTECTED]> wrote: > > On 6/19/07, Ed W <[EMAIL PROTECTED]> wrote: > > > > > > > > One other issue which occured to me which is significant to think about > > > right now is as follows: > > > > > > - Invoices re

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

Ed W wrote: > Hi > >> Ok, I look at normalization as a mathematical method of ensuring that >> the data can represent anything it needs to. > Address should probably be nomalised out of the entity in order to allow > having multiple addresses per entity (eg two delivery addresses) Addresses (lo

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

Hi I was with you up until you said "linked list" which isn't really meaningful in this context. More likely you would have a list of records which would have a valid_to attribute describing when they were no longer used. Well, I was thinking of linked list in the sense that you have an C

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/19/07, Chris Travers <[EMAIL PROTECTED]> wrote: > On 6/19/07, Ed W <[EMAIL PROTECTED]> wrote: > > > > > One other issue which occured to me which is significant to think about > > right now is as follows: > > > > - Invoices really should have delivery and billing addresses locked down > > Only

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/19/07, Ed W <[EMAIL PROTECTED]> wrote: > > One other issue which occured to me which is significant to think about > right now is as follows: > > - Invoices really should have delivery and billing addresses locked down Only caveat is "billing address" may be somewhat ambiguous in this case :

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/19/07, Ed W <[EMAIL PROTECTED]> wrote: > Hi > > > Ok, I look at normalization as a mathematical method of ensuring that > > the data can represent anything it needs to. > > > > Interface and physical model are not tightly coupled. > > > > Agreed. > > One other issue which occured to me which i

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

Hi > Ok, I look at normalization as a mathematical method of ensuring that > the data can represent anything it needs to. > > Interface and physical model are not tightly coupled. > Agreed. One other issue which occured to me which is significant to think about right now is as follows: - In

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/14/07, Ed W <[EMAIL PROTECTED]> wrote: > > Hi > > > > - Normalisation is often good, but it's also painful sometimes. I need > to cut and paste addresses in and out of the system and right now it > needs loads of work to paste into each field. > > What are you cutting and pasting out of and

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

Ed W wrote: > Joshua D. Drake wrote: >> Here is the current model: >> http://ledger-smb.svn.sourceforge.net/viewvc/ledger-smb/trunk/sql/Pg-database.sql?view=markup&pathrev=1244 >> >> > > Just shooting from the hip here: > > - Would be useful to be able to "expire" a contact completely so that

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

>> Joshua D. Drake wrote: >> >>> Here is the current model: >>> http://ledger-smb.svn.sourceforge.net/viewvc/ledger-smb/trunk/sql/Pg-database.sql?view=markup&pathrev=1244 >>> Many of the data insertions in the model makes sense. But salutation not only needs localization, but the set

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

Ed W wrote: > Joshua D. Drake wrote: >> Here is the current model: >> http://ledger-smb.svn.sourceforge.net/viewvc/ledger-smb/trunk/sql/Pg-database.sql?view=markup&pathrev=1244 >> >> > > Just shooting from the hip here: > > - Would be useful to be able to "expire" a contact completely so that

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

Joshua D. Drake wrote: > Here is the current model: > http://ledger-smb.svn.sourceforge.net/viewvc/ledger-smb/trunk/sql/Pg-database.sql?view=markup&pathrev=1244 > > Just shooting from the hip here: - Would be useful to be able to "expire" a contact completely so that they are no longer active

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 5/31/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: > Yes, like 'Sell', ie a vendor, or 'Buy' ie a customer. That is what I am > saying. Except that it is not. Sell is a task performed just as Buy is. A vendor or customer is a class of entity. Agreed. I meant to say this, replying to what

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

David Tangye wrote: > > > On 5/30/07, *Chris Travers* <[EMAIL PROTECTED] > > wrote: > > Ok. Think of an entity as a "legal person" (corporate or natural) and > a contact as a "natural person." > > > Yes, I assume that a 'Contact' is a contact for an Entity.

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 5/30/07, Chris Travers <[EMAIL PROTECTED]> wrote: Ok. Think of an entity as a "legal person" (corporate or natural) and a contact as a "natural person." Yes, I assume that a 'Contact' is a contact for an Entity. So Chris Travers can be the contact for Chris Travers. As a physical design

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 5/29/07, David Tangye <[EMAIL PROTECTED]> wrote: > That seems to be going in the right direction. It would be nice to > have comments on the columns, but the usage of most can be guessed by > good naming. > > Two questions: > 1. Column "entity_class (not null)" in TABLE "entity": is it > someth

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

That seems to be going in the right direction. It would be nice to have comments on the columns, but the usage of most can be guessed by good naming. Two questions: 1. Column "entity_class (not null)" in TABLE "entity": is it something like "current_default/primary_class", whatever that might be?

[Ledger-smb-devel] For those interested in the CRM/Entity management

Here is the current model: http://ledger-smb.svn.sourceforge.net/viewvc/ledger-smb/trunk/sql/Pg-database.sql?view=markup&pathrev=1244 -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive