Hi Paul, Please see my comments inline.
On Tue, Nov 21, 2017 at 3:30 PM, Paul Foxworthy <p...@cohsoft.com.au> wrote: > Hi Suraj, > > Yes, that information is valuable, and you should be able to find it. I > still don't think it all belongs in the FinAccountTrans. > > You are right that a credit card payment or a store account payment will > almost certainly be for one order. But other FinAccountTrans instances will > be more complicated than that. There may be more than one reason for the > FinAccountTrans. > > I might receive ten cheque payments from ten different customers. If I > deposit them in the bank all at once, that's one deposit and one > FinAccountTrans associated with ten Payments. Each payment might be for > several orders. Each order might have several shipments, and each shipment > might be invoiced separately. Each payment might have several > PaymentApplications for several Invoices. The world is more complicated, > and the right thing to do is to have separate FinAccountTrans, Payment, > PaymentApplication, Order, Shipment and Invoice entities. There are > one-to-many relationships between these. > I think in this case, one *FinAccountTrans* record will be created when you receive a cheque payments from a customer with DEPOSIT purpose which marks *paymentId* in *FinAccountTrans *entity. And moving further when certain amount from that payment is applied to any invoice, another *FinAccountTrans *will be created with corresponding orderId/shipmentId with WITHDRAWAL purpose. In this manner I think we can track every transaction happened with the *FinAccount.* Is this making sense you as well or am I missing something? > > These entities and the resulting flexibility are already there in OFBiz. > There is no harm in the simpler situation where there is only one order, > shipment, return. Well, the only harm is if your business seems simpler, > all these entities seem more complicated than you need. However, each of > the entities have distinct semantics and will be needed by some companies > implementing OFBiz. > > If your organisation will only ever encounter a simpler FinAccountTrans, by > all means define a screen to prompt for only one order and so on, and a > view to bring together the FinAccountTrans and associated entities.But > please don't make the OFBiz data model less flexible than it currently is. > > Cheers > > Paul Foxworthy > > > -- Thanks and Regards, *Suraj Khurana* | Sr. Enterprise Software Engineer *HotWax Commerce* by *HotWax Systems* Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010 > On 21 November 2017 at 19:16, Suraj Khurana <suraj.khurana@hotwaxsystems. > com > > wrote: > > > Hello all, > > > > Just adding some thoughts, *FinAccount* is also used for various other > > types as well such as *STORE_CREDIT_ACCT, CREDIT_CARD_ACCOUNT *etc. and > > IMO, recording these transactions (orderId, returnId, shipmentId etc.) > for > > such accounts is a valuable information to be stored to track reason > behind > > every transaction. > > > > Hello Paul, > > >> So a FinAccountTrans may have several associated orders, and several > > associated > > shipments. > > > > I think every order must have a unique FinAccountTrans which is already > > available OOTB in case of *STORE_CREDIT_ACCT* or *CREDIT_CARD_ACCOUNT * > > (Not > > sure about other types) > > > > -- > > Best Regards, > > *Suraj Khurana* | Sr. Enterprise Software Engineer > > *HotWax Commerce* by *HotWax Systems* > > Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010 > > > > > > On Tue, Nov 21, 2017 at 1:05 PM, Jacques Le Roux < > > jacques.le.r...@les7arts.com> wrote: > > > > > +1 > > > > > > Jacques > > > > > > > > > > > > Le 21/11/2017 à 08:27, Scott Gray a écrit : > > > > > >> I agree with Paul that FinAccountTrans shouldn't reference orderId or > > >> returnId. I have nothing to add, his reasoning is spot on. > > >> > > >> Regards > > >> Scott > > >> > > >> On 21 November 2017 at 16:56, Paul Foxworthy <p...@cohsoft.com.au> > > wrote: > > >> > > >> Hi Vaibhav, > > >>> > > >>> I'm really uncomfortable about this. > > >>> > > >>> As Pierre said, FinAccountTrans is for a transaction for a financial > > >>> account (likely a bank account), rather than a transaction on an > > account > > >>> in > > >>> the accounting sense, i.e. an account in your chart of accounts. > > >>> > > >>> So a FinAccountTrans records a deposit or withdrawal to a financial > > >>> account. > > >>> > > >>> It has a foreign key for a Payment. The Payment has related > > >>> PaymentApplications, each of which apply some of the payment to an > > >>> invoice. > > >>> An order may have one or more invoices, and an order may have one or > > more > > >>> shipments. > > >>> > > >>> So a FinAccountTrans may have several associated orders, and several > > >>> associated shipments. Wouldn't it be an oversimplification to carry > one > > >>> and > > >>> only one shipmentId in a FinAccountTrans? And if there was one in > > >>> FinAccountTrans and anything in OFBiz used it, that would break the > > more > > >>> flexible data model that we have at the moment. > > >>> > > >>> By the same token, I think a FinAccountTrans should not have an > orderId > > >>> either - there might be more than one. > > >>> > > >>> Am I missing something? Maybe what you really need is a view that > > >>> conveniently shows the shipment or shipments related to a > > >>> FinAccountTrans . > > >>> > > >>> Thanks > > >>> > > >>> Paul Foxworthy > > >>> > > >>> > > >>> On 20 November 2017 at 23:41, Vaibhav Jain < > > >>> vaibhav.j...@hotwaxsystems.com > > >>> wrote: > > >>> > > >>> Hello all, > > >>>> > > >>>> Currently, orderId field is available and returnId, shipmentId > fields > > >>>> can > > >>>> be introduced in the FinAccountTrans entity. > > >>>> > > >>>> These fields are useful while recording fin account transactions. > > >>>> > > >>>> Please let me know your thoughts on it. > > >>>> > > >>>> Thanks in advance > > >>>> > > >>>> Vaibhav Jain > > >>>> Hotwax Systems, > > >>>> vaibhav.j...@hotwaxsystems.com > > >>>> > > >>>> > > >>> > > >>> -- > > >>> Coherent Software Australia Pty Ltd > > >>> PO Box 2773 > > >>> Cheltenham Vic 3192 > > >>> Australia > > >>> > > >>> Phone: +61 3 9585 6788 > > >>> Web: http://www.coherentsoftware.com.au/ > > >>> Email: i...@coherentsoftware.com.au > > >>> > > >>> > > > > > > > > > -- > Coherent Software Australia Pty Ltd > PO Box 2773 > Cheltenham Vic 3192 > Australia > > Phone: +61 3 9585 6788 > Web: http://www.coherentsoftware.com.au/ > Email: i...@coherentsoftware.com.au >
