ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vaibhav Jain <vaibhav.j...@hotwaxsystems.com>
Subject Re: [PROPOSAL] Extend returnId and shipmentId in FinAccountTrans entity
Date Wed, 22 Nov 2017 08:21:07 GMT
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,

On Tue, Nov 21, 2017 at 6:05 PM, Paul Foxworthy <paul@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: info@coherentsoftware.com.au

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message