[PROPOSAL] Extend returnId and shipmentId in FinAccountTrans entity

[Vaibhav Jain]

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,
[hidden email]

[Pierre Smits]

Hi Valibhav,

Which version of OFBiz are you talking about? I looked in data
model.entitydef.accounting-entitymodel.xml and this entity did not show up.
I may be overlooking something..

Best regards,



Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OEM - The OFBiz Extensions Marketplace1
http://oem.ofbizci.net/oci-2/
1 not affiliated to (and not endorsed by) the OFBiz project

On Mon, Nov 20, 2017 at 1:41 PM, Vaibhav Jain <
[hidden email]> 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,
> [hidden email]
>

[Vaibhav Jain]

Hello Pierre,

I am talking about OFBiz trunk.

Here is the path of the file:
applications/datamodel/entitydef/accounting-entitymodel.xml:462

Just for more information, you can directly access this entity from
entityengine
https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=FinAccountTrans

Thanks & Regards

Vaibhav Jain
Hotwax Systems,
[hidden email]

On Mon, Nov 20, 2017 at 6:35 PM, Pierre Smits <[hidden email]>
wrote:

> Hi Valibhav,
>
> Which version of OFBiz are you talking about? I looked in data
> model.entitydef.accounting-entitymodel.xml and this entity did not show
> up.
> I may be overlooking something..
>
> Best regards,
>
>
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OEM - The OFBiz Extensions Marketplace1
> http://oem.ofbizci.net/oci-2/
> 1 not affiliated to (and not endorsed by) the OFBiz project
>
> On Mon, Nov 20, 2017 at 1:41 PM, Vaibhav Jain <
> [hidden email]> 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,
> > [hidden email]
> >
>

[Pierre Smits]

Hey Vaibhav,

Grin. I indeed must have overlooked something.

So the orderId field is present in that entity. With that we can derive
anything related, including shipments, returns, invoices, return shipments,
etc.

If we're going to include the fields you suggest, I surmise that before
long someone else comes along with another addition he/she finds convenient
to have in that table. As the name of the entity suggest. This is about
Financial Transactions (meaning cashflow related), not generic accounting
transactions related.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OEM - The OFBiz Extensions Marketplace1
http://oem.ofbizci.net/oci-2/
1 not affiliated to (and not endorsed by) the OFBiz project

On Mon, Nov 20, 2017 at 2:25 PM, Vaibhav Jain <
[hidden email]> wrote:

> Hello Pierre,
>
> I am talking about OFBiz trunk.
>
> Here is the path of the file:
> applications/datamodel/entitydef/accounting-entitymodel.xml:462
>
> Just for more information, you can directly access this entity from
> entityengine
> https://demo-trunk.ofbiz.apache.org/webtools/control/
> FindGeneric?entityName=FinAccountTrans
>
> Thanks & Regards
>
> Vaibhav Jain
> Hotwax Systems,
> [hidden email]
>
> On Mon, Nov 20, 2017 at 6:35 PM, Pierre Smits <[hidden email]>
> wrote:
>
> > Hi Valibhav,
> >
> > Which version of OFBiz are you talking about? I looked in data
> > model.entitydef.accounting-entitymodel.xml and this entity did not show
> > up.
> > I may be overlooking something..
> >
> > Best regards,
> >
> >
> >
> > Pierre Smits
> >
> > ORRTIZ.COM <http://www.orrtiz.com>
> > OFBiz based solutions & services
> >
> > OEM - The OFBiz Extensions Marketplace1
> > http://oem.ofbizci.net/oci-2/
> > 1 not affiliated to (and not endorsed by) the OFBiz project
> >
> > On Mon, Nov 20, 2017 at 1:41 PM, Vaibhav Jain <
> > [hidden email]> 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,
> > > [hidden email]
> > >
> >
>

[Vaibhav Jain]

Hello Pierre,

For reference,
In inventoryItemDetail entity, we are recording orderId, returnId and
shipmentId to track the transaction of inventory item.

Comments Inline

Grin. I indeed must have overlooked something.
>
> So the orderId field is present in that entity. With that we can derive
> anything related, including shipments, returns, invoices, return shipments,
> etc.
>
Yes we can derive all the related shipment, return, invoices and return
Shipment from the order id but it is not recorded at financial transaction
level which create a gap that why this transaction happen. We should record
this type of references on transaction level.

>
> If we're going to include the fields you suggest, I surmise that before
> long someone else comes along with another addition he/she finds convenient
> to have in that table. As the name of the entity suggest. This is about
> Financial Transactions (meaning cashflow related), not generic accounting
> transactions related.
>

Yes, FinancialAccountTrans entity is used to record the financial
transaction(Cashflow related) of any party. And in OFBiz
financial transaction may be generated by various operations like Order,
Shipment and Return e.t.c. So we should have information like why this
transaction happens.

WDYT?

> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OEM - The OFBiz Extensions Marketplace1
> http://oem.ofbizci.net/oci-2/
> 1 not affiliated to (and not endorsed by) the OFBiz project
>
> On Mon, Nov 20, 2017 at 2:25 PM, Vaibhav Jain <
> [hidden email]> wrote:
>
> > Hello Pierre,
> >
> > I am talking about OFBiz trunk.
> >
> > Here is the path of the file:
> > applications/datamodel/entitydef/accounting-entitymodel.xml:462
> >
> > Just for more information, you can directly access this entity from
> > entityengine
> > https://demo-trunk.ofbiz.apache.org/webtools/control/
> > FindGeneric?entityName=FinAccountTrans
> >
> > Thanks & Regards
> >
> > Vaibhav Jain
> > Hotwax Systems,
> > [hidden email]
> >
> > On Mon, Nov 20, 2017 at 6:35 PM, Pierre Smits <[hidden email]>
> > wrote:
> >
> > > Hi Valibhav,
> > >
> > > Which version of OFBiz are you talking about? I looked in data
> > > model.entitydef.accounting-entitymodel.xml and this entity did not
> show
> > > up.
> > > I may be overlooking something..
> > >
> > > Best regards,
> > >
> > >
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM <http://www.orrtiz.com>
> > > OFBiz based solutions & services
> > >
> > > OEM - The OFBiz Extensions Marketplace1
> > > http://oem.ofbizci.net/oci-2/
> > > 1 not affiliated to (and not endorsed by) the OFBiz project
> > >
> > > On Mon, Nov 20, 2017 at 1:41 PM, Vaibhav Jain <
> > > [hidden email]> 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,
> > > > [hidden email]
> > > >
> > >
> >
>

[Pierre Smits]

Hi Vaibhav,

Thank you for providing the entity. When looking at the demo data in
demo-trunk I don't see anything that relates back to an order. Maybe that
is an incompleteness regarding the demo data....

I wonder which of the Financial Transaction related screens and services
work with the orderId field.

And I suggest that you bring forward how/when/where (use cases/user
stories) a shipment to a customer or from a supplier or receiving the goods
returned or sending goods back to a supplier lead to a financial
transaction other than through banking or cash transaction (as a result of
an order or RMA leading to a invoice or a credit note).


Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OEM - The OFBiz Extensions Marketplace1
http://oem.ofbizci.net/oci-2/
1 not affiliated to (and not endorsed by) the OFBiz project

On Mon, Nov 20, 2017 at 3:16 PM, Vaibhav Jain <
[hidden email]> wrote:

> Hello Pierre,
>
> For reference,
> In inventoryItemDetail entity, we are recording orderId, returnId and
> shipmentId to track the transaction of inventory item.
>
> Comments Inline
>
> Grin. I indeed must have overlooked something.
> >
> > So the orderId field is present in that entity. With that we can derive
> > anything related, including shipments, returns, invoices, return
> shipments,
> > etc.
> >
> Yes we can derive all the related shipment, return, invoices and return
> Shipment from the order id but it is not recorded at financial transaction
> level which create a gap that why this transaction happen. We should record
> this type of references on transaction level.
>
> >
> > If we're going to include the fields you suggest, I surmise that before
> > long someone else comes along with another addition he/she finds
> convenient
> > to have in that table. As the name of the entity suggest. This is about
> > Financial Transactions (meaning cashflow related), not generic accounting
> > transactions related.
> >
>
> Yes, FinancialAccountTrans entity is used to record the financial
> transaction(Cashflow related) of any party. And in OFBiz
> financial transaction may be generated by various operations like Order,
> Shipment and Return e.t.c. So we should have information like why this
> transaction happens.
>
> WDYT?
>
>
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM <http://www.orrtiz.com>
> > OFBiz based solutions & services
> >
> > OEM - The OFBiz Extensions Marketplace1
> > http://oem.ofbizci.net/oci-2/
> > 1 not affiliated to (and not endorsed by) the OFBiz project
> >
> > On Mon, Nov 20, 2017 at 2:25 PM, Vaibhav Jain <
> > [hidden email]> wrote:
> >
> > > Hello Pierre,
> > >
> > > I am talking about OFBiz trunk.
> > >
> > > Here is the path of the file:
> > > applications/datamodel/entitydef/accounting-entitymodel.xml:462
> > >
> > > Just for more information, you can directly access this entity from
> > > entityengine
> > > https://demo-trunk.ofbiz.apache.org/webtools/control/
> > > FindGeneric?entityName=FinAccountTrans
> > >
> > > Thanks & Regards
> > >
> > > Vaibhav Jain
> > > Hotwax Systems,
> > > [hidden email]
> > >
> > > On Mon, Nov 20, 2017 at 6:35 PM, Pierre Smits <[hidden email]>
> > > wrote:
> > >
> > > > Hi Valibhav,
> > > >
> > > > Which version of OFBiz are you talking about? I looked in data
> > > > model.entitydef.accounting-entitymodel.xml and this entity did not
> > show
> > > > up.
> > > > I may be overlooking something..
> > > >
> > > > Best regards,
> > > >
> > > >
> > > >
> > > > Pierre Smits
> > > >
> > > > ORRTIZ.COM <http://www.orrtiz.com>
> > > > OFBiz based solutions & services
> > > >
> > > > OEM - The OFBiz Extensions Marketplace1
> > > > http://oem.ofbizci.net/oci-2/
> > > > 1 not affiliated to (and not endorsed by) the OFBiz project
> > > >
> > > > On Mon, Nov 20, 2017 at 1:41 PM, Vaibhav Jain <
> > > > [hidden email]> 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,
> > > > > [hidden email]
> > > > >
> > > >
> > >
> >
>

[Paul Foxworthy]

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 <[hidden email]>
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,
> [hidden email]
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[Scott Gray-3]

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 <[hidden email]> 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 <[hidden email]
> >
> 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,
> > [hidden email]
> >
>
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Australia
>
> Phone: [phone]
> Web: http://www.coherentsoftware.com.au/
> Email: [hidden email]
>

[Jacques Le Roux]

+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 <[hidden email]> 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 <[hidden email]
>> 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,
>>> [hidden email]
>>>
>>
>>
>> --
>> Coherent Software Australia Pty Ltd
>> PO Box 2773
>> Cheltenham Vic 3192
>> Australia
>>
>> Phone: [phone]
>> Web: http://www.coherentsoftware.com.au/
>> Email: [hidden email]
>>

[Suraj Khurana]

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 <
[hidden email]> 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 <[hidden email]> 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 <
>>> [hidden email]
>>> 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,
>>>> [hidden email]
>>>>
>>>>
>>>
>>> --
>>> Coherent Software Australia Pty Ltd
>>> PO Box 2773
>>> Cheltenham Vic 3192
>>> Australia
>>>
>>> Phone: [phone]
>>> Web: http://www.coherentsoftware.com.au/
>>> Email: [hidden email]
>>>
>>>
>

[Paul Foxworthy]

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 <[hidden email]
> 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 <
> [hidden email]> 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 <[hidden email]>
> 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 <
> >>> [hidden email]
> >>> 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,
> >>>> [hidden email]
> >>>>
> >>>>
> >>>
> >>> --
> >>> Coherent Software Australia Pty Ltd
> >>> PO Box 2773
> >>> Cheltenham Vic 3192
> >>> Australia
> >>>
> >>> Phone: [phone]
> >>> Web: http://www.coherentsoftware.com.au/
> >>> Email: [hidden email]
> >>>
> >>>
> >
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[Suraj Khurana]

Hi Paul,

Please see my comments inline.

On Tue, Nov 21, 2017 at 3:30 PM, Paul Foxworthy <[hidden email]> wrote:

> 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.
>

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.
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.

In this manner I think we can track every transaction happened with the
*FinAccount.*

Is this making sense you as well or am I missing something?

>
> 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
>
>
>

--
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 21 November 2017 at 19:16, Suraj Khurana <suraj.khurana@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 <
> > [hidden email]> 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 <[hidden email]>
> > 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 <
> > >>> [hidden email]
> > >>> 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,
> > >>>> [hidden email]
> > >>>>
> > >>>>
> > >>>
> > >>> --
> > >>> Coherent Software Australia Pty Ltd
> > >>> PO Box 2773
> > >>> Cheltenham Vic 3192
> > >>> Australia
> > >>>
> > >>> Phone: [phone]
> > >>> Web: http://www.coherentsoftware.com.au/
> > >>> Email: [hidden email]
> > >>>
> > >>>
> > >
> >
>
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Australia
>
> Phone: [phone]
> Web: http://www.coherentsoftware.com.au/
> Email: [hidden email]
>

[Paul Foxworthy]

On 21 November 2017 at 21:48, Suraj Khurana <[hidden email]
> 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: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[Vaibhav Jain]

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,
[hidden email]

On Tue, Nov 21, 2017 at 6:05 PM, Paul Foxworthy <[hidden email]> 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: [phone]
> Web: http://www.coherentsoftware.com.au/
> Email: [hidden email]
>

[Suraj Khurana]

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,
> [hidden email]
>
> On Tue, Nov 21, 2017 at 6:05 PM, Paul Foxworthy <[hidden email]>
> 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: [phone]
> > Web: http://www.coherentsoftware.com.au/
> > Email: [hidden email]
> >
>

[Vaibhav Jain]

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,
[hidden email]

On Thu, Nov 23, 2017 at 11:39 AM, Suraj Khurana <
[hidden email]> 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,
> > [hidden email]
> >
> > On Tue, Nov 21, 2017 at 6:05 PM, Paul Foxworthy <[hidden email]>
> > 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: [phone]
> > > Web: http://www.coherentsoftware.com.au/
> > > Email: [hidden email]
> > >
> >
>