Ok he isn't in the office. but the other person told me that for point No 3. bellow, it should not happen, because if the tax office were to compare the invoicing company (user) and the invoiced client (client), the invoices shall be exactly the same. So historical data should not have impact.
So now thinking a little bit more, If I add a type attribute for "Shipping address, Billing Address" and also have a status attribute like "Active, Non Active", so in case the Billing or shipping addresses changes, I change the status also, so then when creating new invoices I will set it to the Active Billing Address and Shipping address of the User. and the old addresses will remain in the table, o the historical Invoices will still point to that one. What you think? G. > > >> 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. Here I made mistake, an Invoice and all its item can be shipped to one place only, if one of the items needs to be shipped to another location, then it must be another 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 (Webobjects-dev@lists.apple.com) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com >>>>> >>>>> This email sent to webobje...@avendasora.com >>>>> >>>>> >>>> >>>> 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
