Hello All, Here is a link to ticket OFBIZ-9998 <https://issues.apache.org/jira/browse/OFBIZ-9998> raised on JIRA.
Thanks & Regards Vaibhav Jain Hotwax Systems, vaibhav.j...@hotwaxsystems.com On Thu, Nov 23, 2017 at 11:39 AM, Suraj Khurana < suraj.khur...@hotwaxsystems.com> wrote: > 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 > > > > > >
