Thanks, Paul and everyone for the detailed description. -- 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 Wed, Nov 22, 2017 at 1:51 PM, Vaibhav Jain <vaibhav.jain@hotwaxsystems. com> wrote: > Hello all, > > Thank you very much to all of you for sharing this valuable information. > > As we can conclude this conversation here. > > 1. Payment entity already has a field finAccountTransId. So there is no > need of paymentId in the FinAccountTrans entity. > 2. A financial account transaction may have multiple order so there is > no need of orderId and orderItemSeqId in FinAccountTrans entity. > > If the following points are looking good then I will create a JIRA for > this. > > Thanks & Regards, > > Vaibhav Jain > Hotwax Systems, > vaibhav.j...@hotwaxsystems.com > > On Tue, Nov 21, 2017 at 6:05 PM, Paul Foxworthy <p...@cohsoft.com.au> > wrote: > > > On 21 November 2017 at 21:48, Suraj Khurana <suraj.khurana@hotwaxsystems. > > com > > > wrote: > > > > > > > > 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. > > > > > > > Yes, there's a paymentId in the FinAccountTrans entity. That assumes > there > > will be one and only one Payment for the FinAccountTrans. That assumption > > is flawed to my mind. There is also a finAccountTransId in the Payment. > If > > we dropped the paymentId, we would have a one-to-many between > > FinAccountTrans and Payment, instead of one-to-one. That would be an > > improvement. > > > > If you pay my invoice by direct deposit to my bank account, that should > be > > recorded with both a Payment and a FinAccountTrans in OFBiz. If you send > me > > a cheque, that should be recorded with a Payment. When I deposit a batch > of > > cheques, there should be a FinAccountTrans for that. > > > > Think of the statement you receive from the bank and you want to > reconcile > > against your own records. As far as the bank is concerned, there was one > > deposit of a total amount. That's the amount you want to reconcile > against > > your FinAccountTrans. A payment from a customer is not necessarily the > same > > thing or the same amount as a FinAccountTrans. > > > > 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. > > > > > > > Nope. I receive a payment from a customer, and deposit the money in my > bank > > account. Applying the payment to a sale invoice does *not* reduce my bank > > balance. It does mean the invoice has been paid. There are two separate > > balances: the Accounts Receivable balance in an account in my GL, and the > > balance of my account with the financial institution. > > > > The accounting transaction that varies the Accounts Receivable balance is > > not a FinAccountTrans. It's an AcctgTrans. > > > > Any shipment will already be associated with an order. Storing the > > shipmentId a second time in FinAccountTrans is redundant. There may be > more > > than one shipment anyway, so a single shipmentId attribute in > > FinAccountTrans is not enough to hold the truth and would be misleading. > > > > > > > In this manner I think we can track every transaction happened with the > > > *FinAccount.* > > > > > > > I do not dispute the need to track all this. Where I disagree is which > > entities should be doing the tracking. Are you thinking any accounting > > transaction is a FinAccountTrans? I think FinAccountTrans is more > > specialised than that. A FinAccountTrans should correspond to and be > > reconciled against a single line in a statement from a bank or other > > financial institution. > > > > If you want to know the order or orders for a FinAccountTrans, go > > > > FinAccountTrans -> Payment -> PaymentApplication -> Invoice -> > InvoiceItem > > -> OrderItem -> OrderHeader > > > > If you want to know the shipment or shipments for a FinAccountTrans, go > > > > FinAccountTrans -> Payment -> PaymentApplication -> Invoice -> > InvoiceItem > > -> OrderItem -> ItemIssuance -> Shipment > > > > As I said, if you know that in your organisation there will always be > only > > one shipment, create custom screens and views to hide that complexity. > But > > the entities should be able to handle more complex organisations too. > > > > Cheers > > > > Paul Foxworthy > > > > -- > > 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 > > >
