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