Yeah I guess it would help with that, although you still could still pay an invoice directly with it (no billingAccountId on the Invoice), but you couldn't associate the Payment with more than one billing account unless you went for a many to many relationship. But that's fine, I just thought I'd ask as it was the first thing I saw that didn't make sense to me.
Thanks Scott On 01/11/2007, Jacopo Cappellato <[EMAIL PROTECTED]> wrote: > Hi Scott, > > Scott Gray wrote: > > Hi Jacopo > > > > I decided to have a look at this stuff and it doesn't make sense to me > > why we have the billingAccountId on PaymentApplication rather than on > > Payment itself? > > I agree with you that having the billingAccountId in the Payment entity > would have made things simpler. I did not design this, it was already > there when I've refactored/fixed the billing account processes. > However, having the billingAccountId in the PaymentApplication improve > the flexibility: I could receive a Payment and use one part of it to pay > an invoice (not associated to a billing account) and use the remaining > to 'fill' a billing account. > > Jacopo > > > It seems like the logic is pretty much the same > > except we're doing it in a roundabout sort of way by creating a > > PaymentApplication with null invoiceId just to maintain the link. > > > > Thanks > > Scott > > >
