Users - Error in Data Load with financials component

[David E. Jones]

I don't know if this is the best place to discuss this, but... it's an interesting issue. Note that this is on the users list because it really concerns use of OFBiz (even if on a technical level) and not development of OFBiz.

If you have OpenSourceStrategies' financials component in place there is an error during the data load. The new PaymentsInvoices.xml loads some payments and evidently in the proper status to trigger an Entity ECA rule in the financials component, causing the postPaymentToGl service to run and fail as not all data is setup at that point.

Si or Leon could probably answer this best: what was the point of using an Entity ECA rule in the first place?

Now to the point: While any type of ECA can be used whenever, there are _major_ downsides to using Entity ECAs for anything process related. I very highly recommend against it in fact.

To avoid problems Entity ECA rules should be used for data maintenance purposes only. For example, in the inventory stuff the InventoryItem fields totalAvailableToPromise and totalQuantityOnHand are  calculated from the corresponding fields on the InventoryItemDetail entity. So, they should never be set directly but rather maintained automatically through a service triggered by an EECA rule.

-David

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Si Chen-2]

David,

I just came up on this.  The reason we used EECA was because there were
many places where Payments are created directly with the delegator
rather than with the createPayment/updatePayment service--too many for
us to fix at once.  I agree with you 100% this is not a good long term
solution and when we get a chance to fix it in the other modules we'll
change it as well.

More specifically, what is the data loading error?  I've tried it a few
times myself and don't see it.

Si

David E Jones wrote:

> I don't know if this is the best place to discuss this, but... it's an interesting issue. Note that this is on the users list because it really concerns use of OFBiz (even if on a technical level) and not development of OFBiz.
>
> If you have OpenSourceStrategies' financials component in place there is an error during the data load. The new PaymentsInvoices.xml loads some payments and evidently in the proper status to trigger an Entity ECA rule in the financials component, causing the postPaymentToGl service to run and fail as not all data is setup at that point.
>
> Si or Leon could probably answer this best: what was the point of using an Entity ECA rule in the first place?
>
> Now to the point: While any type of ECA can be used whenever, there are _major_ downsides to using Entity ECAs for anything process related. I very highly recommend against it in fact.
>
> To avoid problems Entity ECA rules should be used for data maintenance purposes only. For example, in the inventory stuff the InventoryItem fields totalAvailableToPromise and totalQuantityOnHand are  calculated from the corresponding fields on the InventoryItemDetail entity. So, they should never be set directly but rather maintained automatically through a service triggered by an EECA rule.
>
> -David
>
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>
>
>  

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[David E. Jones]

Si,

The data load error happened on a new database with the current revisions of OFBiz and financials. The error was with a Payment create in the new test data that Hans put in and the error is the one that complains when no GL account was found for the payment (because the accounting data loads after).

BTW, this brings up another interesting point about the original accounting design that I guess isn't implemented yet... and that is to create skeleton AcctgTrans records in place in an exceptions journal with everything possible populated and leave the rest for manual posting. Is that still on the radar for your efforts on the financials component?

-David


Si Chen wrote:

> David,
>
> I just came up on this.  The reason we used EECA was because there were
> many places where Payments are created directly with the delegator
> rather than with the createPayment/updatePayment service--too many for
> us to fix at once.  I agree with you 100% this is not a good long term
> solution and when we get a chance to fix it in the other modules we'll
> change it as well.
>
> More specifically, what is the data loading error?  I've tried it a few
> times myself and don't see it.
>
> Si
>
> David E Jones wrote:
>> I don't know if this is the best place to discuss this, but... it's an interesting issue. Note that this is on the users list because it really concerns use of OFBiz (even if on a technical level) and not development of OFBiz.
>>
>> If you have OpenSourceStrategies' financials component in place there is an error during the data load. The new PaymentsInvoices.xml loads some payments and evidently in the proper status to trigger an Entity ECA rule in the financials component, causing the postPaymentToGl service to run and fail as not all data is setup at that point.
>>
>> Si or Leon could probably answer this best: what was the point of using an Entity ECA rule in the first place?
>>
>> Now to the point: While any type of ECA can be used whenever, there are _major_ downsides to using Entity ECAs for anything process related. I very highly recommend against it in fact.
>>
>> To avoid problems Entity ECA rules should be used for data maintenance purposes only. For example, in the inventory stuff the InventoryItem fields totalAvailableToPromise and totalQuantityOnHand are  calculated from the corresponding fields on the InventoryItemDetail entity. So, they should never be set directly but rather maintained automatically through a service triggered by an EECA rule.
>>
>> -David
>>
>>  
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/users
>>
>>
>>  
>
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Hans Bakker]

David,

On Saturday 29 April 2006 17:55, David E Jones wrote:
> Si,
>
> The data load error happened on a new database with the current revisions
> of OFBiz and financials. The error was with a Payment create in the new
> test data that Hans put in and the error is the one that complains when no
> GL account was found for the payment (because the accounting data loads
> after).

I tested the data and did a retest this morning and found that the payment
seca's I disabled by accident. I reactivated them, got a new copy from svn
and did a run-install....everything worked fine, no errors.

Hans

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Si Chen-2]

David,

Hopefully Hans answered #1.

Regarding #2 -  There is a file data/DemoOrgBalanceSheet.xml which has an initial balance sheet, inventory valuation, and sample transactions data.  Right now everything needs to be posted manually, but I guess we could change or enhance it so some are already considered "posted".  Is that what you meant?

Si

David E Jones wrote:

Si,

The data load error happened on a new database with the current revisions of OFBiz and financials. The error was with a Payment create in the new test data that Hans put in and the error is the one that complains when no GL account was found for the payment (because the accounting data loads after).

BTW, this brings up another interesting point about the original accounting design that I guess isn't implemented yet... and that is to create skeleton AcctgTrans records in place in an exceptions journal with everything possible populated and leave the rest for manual posting. Is that still on the radar for your efforts on the financials component?

-David


Si Chen wrote:
  

David,

I just came up on this.  The reason we used EECA was because there were 
many places where Payments are created directly with the delegator 
rather than with the createPayment/updatePayment service--too many for 
us to fix at once.  I agree with you 100% this is not a good long term 
solution and when we get a chance to fix it in the other modules we'll 
change it as well.

More specifically, what is the data loading error?  I've tried it a few 
times myself and don't see it.

Si

David E Jones wrote:
    

I don't know if this is the best place to discuss this, but... it's an interesting issue. Note that this is on the users list because it really concerns use of OFBiz (even if on a technical level) and not development of OFBiz.

If you have OpenSourceStrategies' financials component in place there is an error during the data load. The new PaymentsInvoices.xml loads some payments and evidently in the proper status to trigger an Entity ECA rule in the financials component, causing the postPaymentToGl service to run and fail as not all data is setup at that point.

Si or Leon could probably answer this best: what was the point of using an Entity ECA rule in the first place?

Now to the point: While any type of ECA can be used whenever, there are _major_ downsides to using Entity ECAs for anything process related. I very highly recommend against it in fact.

To avoid problems Entity ECA rules should be used for data maintenance purposes only. For example, in the inventory stuff the InventoryItem fields totalAvailableToPromise and totalQuantityOnHand are  calculated from the corresponding fields on the InventoryItemDetail entity. So, they should never be set directly but rather maintained automatically through a service triggered by an EECA rule. 

-David

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users


  
      

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users
    

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users


  

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users