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. 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 On 21 November 2017 at 19:16, Suraj Khurana <suraj.khur...@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
