Hello dave.
> 
> 1) Is it possible that items on an invoice will be shipped to two different 
> addresses
No, thats not possible.


> 2) Is it possible that one item on the invoice will be shipped to two 
> different addresses
Nop, the invoice will be shipped all in one to the same place, in case they 
need to ship to another place they need to create a different invoice.

> 3) If a customer's address changes, should it have any impact on the 
> addresses of historical orders, invoices, etc.
This is the main question.. I will have to ask the accountant to see what he 
thinks. 

> 
> Keep in mind that the people that should answer this question may not be the 
> ones actually using the app. It may be the decision of the Chief Financial 
> Officer or Comptroller as to what data must be tracked for historical 
> purposes, but it may be a staff accountant that actually uses the app.
> 
> Good luck. I think this is the fun part of writing an app!
> 
Yeeah yeah, lifting req can be sometimes a PITA.
G.


> Dave
> 
> 
> 
> 
> On Nov 16, 2009, at 9:26 AM, Gustavo Pizano wrote:
> 
>> Hello.
>> 
>> Aha, i see, what about  instead of having a single Address table with 
>> duplicates, I have 2 Address table, one for the person and one for the 
>> invoice, let's called InvoicedAddress, so when creating the invoice, I as 
>> you say, make a copy of the selected User address and assign it to 
>> InovoicedAddress instead? this will create the record on that table when 
>> saveChanges(); isn't  it?
>> 
>> G.
>> 
>> 
>> On Nov 16, 2009, at 3:20 PM, David Avendasora wrote:
>> 
>>> Hi Gustavo,
>>> 
>>> This is one of those situations where the business rules contradict 
>>> Normalization rules for the DB.
>>> 
>>> The Business rules override the normalization rules.
>>> 
>>> Invoice should have it's own relationship to Address, and it should not 
>>> point to the same object as the person does. When you create an invoce and 
>>> give it an address, you should duplicate the person's address object and 
>>> then add the duplicate to the Invoce. You will end up with multiple copies 
>>> of the same address in the DB, but if the Invoice must maintain the address 
>>> without changes, you can't relate it to the same object.
>>> 
>>> Duplicating EOs is simple using the method outlined in Practical WO, and I 
>>> think the copyable interface described there has been added to 
>>> ERXGenericRecord so you should be able to do this with very little work.
>>> 
>>> Having multiple instances of the same object is usually a no-no from both 
>>> the WO and DB perspective, but in the situation you describe, duplicate 
>>> instances _is_ the way to go, because they are only duplicates by 
>>> coincidence, not by business rule.
>>> 
>>> Dave
>>> 
>>> 
>>> On Nov 16, 2009, at 6:22 AM, Gustavo Pizano wrote:
>>> 
>>>> Hello all.
>>>> 
>>>> I know this is off topic, but you guys have helped me in the past with 
>>>> such a questions, so I hope Im not bothering anybody.
>>>> 
>>>> Im building a Invoicing app, so I have my EOModel and this is what I have.
>>>> 
>>>> Person: 
>>>> Client: Parent is Person
>>>> User: Parent is Person.
>>>> 
>>>> Person < >> Address  (toAddress)
>>>> 
>>>> Invoice << > User (toUser)
>>>> Invoice<< > Client (toClient)
>>>> InvoiceItem<< >>  Invoice
>>>> InvoiceStatus< >> Invoice
>>>> 
>>>> now... what happens if the Person changes address?, it will change the 
>>>> address of all already created invoices, which for record purposes its not 
>>>> allowed, it think. (I mean my already created invoices should stay as they 
>>>> where created)
>>>> 
>>>> So is it correct to add a relation from Invoice << > Address ?, so when I 
>>>> add a new address to Person the invoice will kept the old address. right?
>>>> 
>>>> how can I avoid when modifying the address, if I do this, then the invoice 
>>>> toAddress will change also.
>>>> 
>>>> Thanks
>>>> 
>>>> 
>>>> G. _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list      ([email protected])
>>>> Help/Unsubscribe/Update your Subscription:
>>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>>> 
>>>> This email sent to [email protected]
>>>> 
>>>> 
>>> 
>>> David Avendasora
>>> Senior Software Engineer
>>> K12, Inc.
>>> 
>>> *****
>>> WebObjects Documentation Wiki : 
>>> http://wiki.objectstyle.org/confluence/display/WO/
>>> *****
>>> WebObjects API: 
>>> http://developer.apple.com/legacy/mac/library/documentation/MacOSXServer/Reference/WO54_Reference/index.html
>>> *****
>>> 
>> 
>> 
>> 
> 
> David Avendasora
> Senior Software Engineer
> K12, Inc.
> 
> *****
> WebObjects Documentation Wiki : 
> http://wiki.objectstyle.org/confluence/display/WO/
> *****
> WebObjects API: 
> http://developer.apple.com/legacy/mac/library/documentation/MacOSXServer/Reference/WO54_Reference/index.html
> *****
> 

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to