Dev - change status of a fully applied invoice to 'paid.' automatically

[Hans Bakker]

currently the invoice status is changed to "paid' when the payment is set to
'received' by a seca when the invoice is fully applied. As you know, error
reporting from a Seca is not working well. I get the error message:
 
Error calling event: org.ofbiz.webapp.event.EventHandlerException: Service
invocation error (Commit transaction failed)

The reason is that the invoice has the status "in_process" and a seca rule is
starting a service to get the status to 'paid' what is not allowed because it
should be set to 'ready' first.

Currently we have all status changes of an invoice and payment centralized;
one for a payment and one for an invoice. Isn't it better to do the
application checking and status change in these 2 services instead of using a
separate service and seca?

if no objections i will change that in the next few days....

--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc

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

[Si Chen-2]

Hans,

Why is your invoice not READY when you start applying payments to it?

How would changing it from a SECA to a direct service call help things?  You would still have the same status change issue.  If you just need to make IN_PROCESS invoices to PAID, why don't you just add your own StatusValidChange in your version?

Finally, I made the SECA so that there could be a manual approval process before the invoice is automatically marked PAID.  Do we really want to make it so that it has to be automated? 

David, anyone else -

any thoughts?

Si

Hans Bakker wrote:

currently the invoice status is changed to "paid' when the payment is set to 
'received' by a seca when the invoice is fully applied. As you know, error 
reporting from a Seca is not working well. I get the error message:
 
Error calling event: org.ofbiz.webapp.event.EventHandlerException: Service 
invocation error (Commit transaction failed)

The reason is that the invoice has the status "in_process" and a seca rule is 
starting a service to get the status to 'paid' what is not allowed because it 
should be set to 'ready' first.

Currently we have all status changes of an invoice and payment centralized; 
one for a payment and one for an invoice. Isn't it better to do the 
application checking and status change in these 2 services instead of using a 
separate service and seca?

if no objections i will change that in the next few days....

  

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

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

[Si Chen-2]

Hans,

I don't disagree that things should be as easy as possible.  However, I think the issue is that accounting systems need to offer a high level of control as well, so data can't be just entered or changed.  This is especially important to larger companies which use OFBiz.  When you modify lower level services to eliminate controls or steps, it makes it hard to enforce those kinds of approval.

Si

Hans Bakker wrote:

Si,

we seem to have different viewpoints, that is normal and is no problem, 
however...
when you state:

  

Do we really want to make it so that it has to be automated?
    

that is is indeed my goal to make the accounting as easy as possible. You know 
why? Most, if not all enterpreneurs view accounting as a burden and should 
take as less time as possible.

concerning the issue below, do not worry, i will implement this in the 
opentravel system only, i get a bit tired to spend so much time on convincing 
you. I rather spend the time to make the system better.

  

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

[Si Chen-2]

Hans,

On this note, can we reverse your changes of r 7172 for now?

Si

Si Chen wrote:

Hans,

I don't disagree that things should be as easy as possible.  However, I think the issue is that accounting systems need to offer a high level of control as well, so data can't be just entered or changed.  This is especially important to larger companies which use OFBiz.  When you modify lower level services to eliminate controls or steps, it makes it hard to enforce those kinds of approval.

Si

Hans Bakker wrote:

Si,

we seem to have different viewpoints, that is normal and is no problem, 
however...
when you state:

  

Do we really want to make it so that it has to be automated?
    

that is is indeed my goal to make the accounting as easy as possible. You know 
why? Most, if not all enterpreneurs view accounting as a burden and should 
take as less time as possible.

concerning the issue below, do not worry, i will implement this in the 
opentravel system only, i get a bit tired to spend so much time on convincing 
you. I rather spend the time to make the system better.

  

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

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

[David E. Jones]

Hans,

I also think is an important point. It is fine for applications to make assumptions about the best value to put in but generally only in higher level services whose job it is to make assumptions to simplify things, or in the user interface itself where the user can see the assumption and verify it or not.

As a general practice this is a good pattern to make code less error prone to reuse, and less error prone in general for both programmers customizing it and end users using it.

For this particular feature I think it's a great idea, but it should be implemented "higher up".

This is of course a discussion and others are free to join in, and it would be great to hear more of your thoughts on this (including if you think we are totally off base and as many details about why as you can include).

Thanks,
-David


Si Chen wrote:

> Hans,
>
> On this note, can we reverse your changes of r 7172 for now?
>
> Si
>
> Si Chen wrote:
>> Hans,
>>
>> I don't disagree that things should be as easy as possible.  However,
>> I think the issue is that accounting systems need to offer a high
>> level of control as well, so data can't be just entered or changed.  
>> This is especially important to larger companies which use OFBiz.  
>> When you modify lower level services to eliminate controls or steps,
>> it makes it hard to enforce those kinds of approval.
>>
>> Si
>>
>> Hans Bakker wrote:
>>> Si,
>>>
>>> we seem to have different viewpoints, that is normal and is no problem,
>>> however...
>>> when you state:
>>>
>>>  
>>>> Do we really want to make it so that it has to be automated?
>>>>    
>>>
>>> that is is indeed my goal to make the accounting as easy as possible. You know
>>> why? Most, if not all enterpreneurs view accounting as a burden and should
>>> take as less time as possible.
>>>
>>> concerning the issue below, do not worry, i will implement this in the
>>> opentravel system only, i get a bit tired to spend so much time on convincing
>>> you. I rather spend the time to make the system better.
>>>
>>>  
>> ------------------------------------------------------------------------
>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[Jacques Le Roux]

----- Original Message -----
From: "David E. Jones" <[hidden email]>
To: "OFBiz Project Development Discussion" <[hidden email]>
Sent: Wednesday, April 05, 2006 6:23 PM
Subject: Re: [OFBiz] Dev - change status of a fully applied invoice to 'paid.'
automatically


>
> Hans,
>
> I also think is an important point. It is fine for applications to make
assumptions about the best value to put in but generally only in higher level
services whose job it is to make assumptions to simplify things, or in the user
interface itself where the user can see the assumption and verify it or not.
>
> As a general practice this is a good pattern to make code less error prone to
reuse, and less error prone in general for both programmers customizing it and
end users using it.
>
> For this particular feature I think it's a great idea, but it should be
implemented "higher up".
>
> This is of course a discussion and others are free to join in, and it would be
great to hear more of your thoughts on this (including if you think we are
totally off base and as many details about why as you can include).

>
> Thanks,
> -David
>
>
> Si Chen wrote:
> > Hans,
> >
> > On this note, can we reverse your changes of r 7172 for now?
> >
> > Si
> >
> > Si Chen wrote:
> >> Hans,
> >>
> >> I don't disagree that things should be as easy as possible.  However,
> >> I think the issue is that accounting systems need to offer a high
> >> level of control as well, so data can't be just entered or changed.
> >> This is especially important to larger companies which use OFBiz.
> >> When you modify lower level services to eliminate controls or steps,
> >> it makes it hard to enforce those kinds of approval.
> >>
> >> Si

Perhaps an issue here is to use the old IA concept of profil.
. Hans tends to privilege an esay way for user
. Si recalls that accouting is a serious thing (audit) and that no account
writings can be ripped off.

The issue may be to propose at least 2 profils for store (and here accounting
related of coursr) : Strict (Si point of viwe), Cool (Hans point of view)

In a Cool profil the user must be warned that he may used option that may cause
problem in case of an audit.

I'm not sure if this idea is interesting in that case. But I find this kind of
open minded options always interesting. But yes, that means also more code...
:( Perhaps a way to better integrate Hans code (OTS) with "official" OFBiz ?

Please forget all that if I haven't really understood the problem, after all,
I'm french ;o)

Jacques

> >> Hans Bakker wrote:
> >>> Si,
> >>>
> >>> we seem to have different viewpoints, that is normal and is no problem,
> >>> however...
> >>> when you state:
> >>>
> >>>
> >>>> Do we really want to make it so that it has to be automated?
> >>>>
> >>>
> >>> that is is indeed my goal to make the accounting as easy as possible. You

know
> >>> why? Most, if not all enterpreneurs view accounting as a burden and should
> >>> take as less time as possible.
> >>>
> >>> concerning the issue below, do not worry, i will implement this in the
> >>> opentravel system only, i get a bit tired to spend so much time on
convincing

> >>> you. I rather spend the time to make the system better.
> >>>
> >>>
> >> ------------------------------------------------------------------------
> >>
> >>
> >> _______________________________________________
> >> Dev mailing list
> >> [hidden email]
> >> http://lists.ofbiz.org/mailman/listinfo/dev
> >
> > ------------------------------------------------------------------------
> >
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[Si Chen-2]

Actually, Hans - one good solution is for you to implement some additional services which you can link to the main ofbiz services via a seca in your open travel systems. 

Si

Jacques Le Roux wrote:

----- Original Message ----- 
From: "David E. Jones" [hidden email]
To: "OFBiz Project Development Discussion" [hidden email]
Sent: Wednesday, April 05, 2006 6:23 PM
Subject: Re: [OFBiz] Dev - change status of a fully applied invoice to 'paid.'
automatically


  

Hans,

I also think is an important point. It is fine for applications to make
    

assumptions about the best value to put in but generally only in higher level
services whose job it is to make assumptions to simplify things, or in the user
interface itself where the user can see the assumption and verify it or not.
  

As a general practice this is a good pattern to make code less error prone to
    

reuse, and less error prone in general for both programmers customizing it and
end users using it.
  

For this particular feature I think it's a great idea, but it should be
    

implemented "higher up".
  

This is of course a discussion and others are free to join in, and it would be
    

great to hear more of your thoughts on this (including if you think we are
totally off base and as many details about why as you can include).
  

Thanks,
-David


Si Chen wrote:
    

Hans,

On this note, can we reverse your changes of r 7172 for now?

Si

Si Chen wrote:
      

Hans,

I don't disagree that things should be as easy as possible.  However,
I think the issue is that accounting systems need to offer a high
level of control as well, so data can't be just entered or changed.
This is especially important to larger companies which use OFBiz.
When you modify lower level services to eliminate controls or steps,
it makes it hard to enforce those kinds of approval.

Si
        

Perhaps an issue here is to use the old IA concept of profil.
. Hans tends to privilege an esay way for user
. Si recalls that accouting is a serious thing (audit) and that no account
writings can be ripped off.

The issue may be to propose at least 2 profils for store (and here accounting
related of coursr) : Strict (Si point of viwe), Cool (Hans point of view)

In a Cool profil the user must be warned that he may used option that may cause
problem in case of an audit.

I'm not sure if this idea is interesting in that case. But I find this kind of
open minded options always interesting. But yes, that means also more code...
:( Perhaps a way to better integrate Hans code (OTS) with "official" OFBiz ?

Please forget all that if I haven't really understood the problem, after all,
I'm french ;o)

Jacques


  

Hans Bakker wrote:
        

Si,

we seem to have different viewpoints, that is normal and is no problem,
however...
when you state:


          

Do we really want to make it so that it has to be automated?

            

that is is indeed my goal to make the accounting as easy as possible. You
          

know
  

why? Most, if not all enterpreneurs view accounting as a burden and should
take as less time as possible.

concerning the issue below, do not worry, i will implement this in the
opentravel system only, i get a bit tired to spend so much time on
          

convincing
  

you. I rather spend the time to make the system better.


          

------------------------------------------------------------------------


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

------------------------------------------------------------------------


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

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

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


  

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

[Hans Bakker]

Si,

I do not know what you are doing, you are confusing several subjects.

Implementation 7172 is critical for my operations. On your request i have
added several user messages to this action later, i also updated the screen
on your request.

Further I protest that you publisize in this mailing list messages I send to
you privatly.

I strongly object that this change is taken out, this is causing me a lot of
not required work, is causing that the application screen is not working and
that there then not required messages in the system.

i am sorry, i am starting to question your intentions here.

further I apologize to the readers of this list that this message is public, i
normally try to handle these problems in privat.

Hans


On Wednesday 05 April 2006 22:11, Si Chen wrote:

> Hans,
>
> On this note, can we reverse your changes of r 7172 for now?
>
> Si
>
> Si Chen wrote:
> > Hans,
> >
> > I don't disagree that things should be as easy as possible.  However,
> > I think the issue is that accounting systems need to offer a high
> > level of control as well, so data can't be just entered or changed.
> > This is especially important to larger companies which use OFBiz.
> > When you modify lower level services to eliminate controls or steps,
> > it makes it hard to enforce those kinds of approval.
> >
> > Si
> >
> > Hans Bakker wrote:
> >> Si,
> >>
> >> we seem to have different viewpoints, that is normal and is no problem,
> >> however...
> >>
> >> when you state:
> >>> Do we really want to make it so that it has to be automated?
> >>
> >> that is is indeed my goal to make the accounting as easy as possible.
> >> You know why? Most, if not all enterpreneurs view accounting as a burden
> >> and should take as less time as possible.
> >>
> >> concerning the issue below, do not worry, i will implement this in the
> >> opentravel system only, i get a bit tired to spend so much time on
> >> convincing you. I rather spend the time to make the system better.
> >
> > ------------------------------------------------------------------------
> >
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev

--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc

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

[Si Chen-2]

Hans,

If you read the messages carefully, you would realize that r 7172 is a feature that neither David nor I agree with, but that I have not removed it.  The previous email was a courtesy to tell you in advance and give you time to prepare.

Unfortunately I think the feature is dangerous.  You are trying to make it easy for yourself so you don't have to enter an amount to apply.  Someone else could easily have a typo or a service error and thereby cause the maximum possible amount to be applied.  It is fine if you want to make the application easier, but please think about possible side effects. 

If you want this feature for your own version, that's fine, but I think given the discussion so far it does not belong in OFBiz. 

Finally, I don't know why you are sending my private emails, since we both work on an open source project.  I have asked you repeatedly before to keep all our discussions on the public list so others can see it.  I think that is only fair, since there are other users of OFBiz whom our work would affect.

If you'd really like to "know my intentions," I'd be happy to share them with you.

Si

Hans Bakker wrote:

Si,

I do not know what you are doing, you are confusing several subjects. 

Implementation 7172 is critical for my operations. On your request i have 
added several user messages to this action later, i also updated the screen 
on your request. 

Further I protest that you publisize in this mailing list messages I send to 
you privatly.

I strongly object that this change is taken out, this is causing me a lot of 
not required work, is causing that the application screen is not working and 
that there then not required messages in the system.

i am sorry, i am starting to question your intentions here.

further I apologize to the readers of this list that this message is public, i 
normally try to handle these problems in privat.

Hans


On Wednesday 05 April 2006 22:11, Si Chen wrote:
  

Hans,

On this note, can we reverse your changes of r 7172 for now?

Si

Si Chen wrote:
    

Hans,

I don't disagree that things should be as easy as possible.  However,
I think the issue is that accounting systems need to offer a high
level of control as well, so data can't be just entered or changed.
This is especially important to larger companies which use OFBiz.
When you modify lower level services to eliminate controls or steps,
it makes it hard to enforce those kinds of approval.

Si

Hans Bakker wrote:
      

Si,

we seem to have different viewpoints, that is normal and is no problem,
however...

when you state:
        

Do we really want to make it so that it has to be automated?
          

that is is indeed my goal to make the accounting as easy as possible.
You know why? Most, if not all enterpreneurs view accounting as a burden
and should take as less time as possible.

concerning the issue below, do not worry, i will implement this in the
opentravel system only, i get a bit tired to spend so much time on
convincing you. I rather spend the time to make the system better.
        

------------------------------------------------------------------------


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

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

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

[Hans Bakker]

David,
I completely agree with you here, however there is no 'higher up'

screens: (at the bottom)
https://localhost:8443/accounting/control/editInvoiceApplications?invoiceId=10000
https://localhost:8443/accounting/control/editPaymentApplications?paymentId=10000

on this particular screen, one has to input an invoiceId/paymentId and an
amount to apply, if the amount is empty or zero, nothing happens, no message,
nothing. The reason the screen is here is that payment can come from othere
sources then where the invoice was sendTo/receivedFrom en the lists above it
do not apply.

Before the chage, If you wanted to know the amount tp apply, you have to go
manually to the related invoice/payment, check wat can be applied, copy it,
go back and past the value. I cannot imagine that in 99.9% of the cases you
want a lower value.

Now with this change, the screen indicates that if the field is empty or 0 the
maximum possible value will be applied, and a success/error message tells you
what happened afterwards.

regards,
Hans

On Wednesday 05 April 2006 23:23, David E. Jones wrote:

> Hans,
>
> I also think is an important point. It is fine for applications to make
> assumptions about the best value to put in but generally only in higher
> level services whose job it is to make assumptions to simplify things, or
> in the user interface itself where the user can see the assumption and
> verify it or not.
>
> As a general practice this is a good pattern to make code less error prone
> to reuse, and less error prone in general for both programmers customizing
> it and end users using it.
>
> For this particular feature I think it's a great idea, but it should be
> implemented "higher up".
>
> This is of course a discussion and others are free to join in, and it would
> be great to hear more of your thoughts on this (including if you think we
> are totally off base and as many details about why as you can include).
>
> Thanks,
> -David
>
> Si Chen wrote:
> > Hans,
> >
> > On this note, can we reverse your changes of r 7172 for now?
> >
> > Si
> >
> > Si Chen wrote:
> >> Hans,
> >>
> >> I don't disagree that things should be as easy as possible.  However,
> >> I think the issue is that accounting systems need to offer a high
> >> level of control as well, so data can't be just entered or changed.
> >> This is especially important to larger companies which use OFBiz.
> >> When you modify lower level services to eliminate controls or steps,
> >> it makes it hard to enforce those kinds of approval.
> >>
> >> Si
> >>
> >> Hans Bakker wrote:
> >>> Si,
> >>>
> >>> we seem to have different viewpoints, that is normal and is no problem,
> >>> however...
> >>>
> >>> when you state:
> >>>> Do we really want to make it so that it has to be automated?
> >>>
> >>> that is is indeed my goal to make the accounting as easy as possible.
> >>> You know why? Most, if not all enterpreneurs view accounting as a
> >>> burden and should take as less time as possible.
> >>>
> >>> concerning the issue below, do not worry, i will implement this in the
> >>> opentravel system only, i get a bit tired to spend so much time on
> >>> convincing you. I rather spend the time to make the system better.
> >>
> >> ------------------------------------------------------------------------
> >>
> >>
> >> _______________________________________________
> >> Dev mailing list
> >> [hidden email]
> >> http://lists.ofbiz.org/mailman/listinfo/dev
> >
> > ------------------------------------------------------------------------
> >
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc

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

[Hans Bakker]

On Thursday 06 April 2006 03:40, Si Chen wrote:
> Actually, Hans - one good solution is for you to implement some
> additional services which you can link to the main ofbiz services via a
> seca in your open travel systems.

Yes, if you can send a success message and a proper message when it fails it
could be a solution. if you think that:

Error calling event: org.ofbiz.webapp.event.EventHandlerException: Service
invocation error (Commit transaction failed)

is a proper message then yes it could be a good solution.

However a much simpler solution would be to put this action in the service
that is changing the status. No SECA, less services and proper fail/success
message is possible then.

--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc

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

[Hans Bakker]

It seems that we cannot agree on a solution, so lets vote:

in favor: (+)
make the system easy to use with as less manual actions as required, but let
the user decide which amount to put in but inform the user accordingly what
is going to happen.

against: (-)
do not automate as much as possible but force the user to put in things  
manually and force the user to check more.



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

[cjhowe]

I'm sorry that I'm popping up in the middle of this,
you guys seem to be on a roll.

Hans,

I apologize if I'm not following this thread
correctly.  
Let me offer the following example and let me know if
I'm describing the function of these screens
correctly.

The following Invoices for one customer exists
1000 for 95.00
1001 for 1195.00
1002 for 250.00

One payment exists
1000 for 1275.00

With a memo to apply as follows
75.00 towards inv1000
950.00 towards inv1001
250.00 towards inv1002

You should only enter one payment.

If someone mistakenly submitted with empty values,
your default action would apply as follows:
95.00 towards inv1000
1180.00 towards inv1001
0.00 towards inv1002
1002 for 250.00

An investigation would begin on the wrong invoices
being shortpayed/nopayed

This is a very common receivables transaction.  It is
not limited to such a small percentage.  Which is why
I think I may not be following this thread correctly.

If I'm not following this thread correctly, just say
"Chris, that's not what we're talking about"

If I am following this correctly and a company is
willing to take this risk in order to make for easier
accounting, it only requires about 15 lines of code
using the differences app approach that is detailed in
the wiki.  That risk should be avoided though for the
majority of ofbiz users.


--- Hans Bakker <[hidden email]> wrote:

> David,
> I completely agree with you here, however there is
> no 'higher up'
>
> screens: (at the bottom)
>
https://localhost:8443/accounting/control/editInvoiceApplications?invoiceId=10000
>
https://localhost:8443/accounting/control/editPaymentApplications?paymentId=10000

>
> on this particular screen, one has to input an
> invoiceId/paymentId and an
> amount to apply, if the amount is empty or zero,
> nothing happens, no message,
> nothing. The reason the screen is here is that
> payment can come from othere
> sources then where the invoice was
> sendTo/receivedFrom en the lists above it
> do not apply.
>
> Before the chage, If you wanted to know the amount
> tp apply, you have to go
> manually to the related invoice/payment, check wat
> can be applied, copy it,
> go back and past the value. I cannot imagine that in
> 99.9% of the cases you
> want a lower value.
>
> Now with this change, the screen indicates that if
> the field is empty or 0 the
> maximum possible value will be applied, and a
> success/error message tells you
> what happened afterwards.
>
> regards,
> Hans
>
> On Wednesday 05 April 2006 23:23, David E. Jones
> wrote:
> > Hans,
> >
> > I also think is an important point. It is fine for
> applications to make
> > assumptions about the best value to put in but
> generally only in higher
> > level services whose job it is to make assumptions
> to simplify things, or
> > in the user interface itself where the user can
> see the assumption and
> > verify it or not.
> >
> > As a general practice this is a good pattern to
> make code less error prone
> > to reuse, and less error prone in general for both
> programmers customizing
> > it and end users using it.
> >
> > For this particular feature I think it's a great
> idea, but it should be
> > implemented "higher up".
> >
> > This is of course a discussion and others are free
> to join in, and it would
> > be great to hear more of your thoughts on this
> (including if you think we
> > are totally off base and as many details about why
> as you can include).
> >
> > Thanks,
> > -David
> >
> > Si Chen wrote:
> > > Hans,
> > >
> > > On this note, can we reverse your changes of r
> 7172 for now?
> > >
> > > Si
> > >
> > > Si Chen wrote:
> > >> Hans,
> > >>
> > >> I don't disagree that things should be as easy
> as possible.  However,
> > >> I think the issue is that accounting systems
> need to offer a high
> > >> level of control as well, so data can't be just
> entered or changed.
> > >> This is especially important to larger
> companies which use OFBiz.
> > >> When you modify lower level services to
> eliminate controls or steps,
> > >> it makes it hard to enforce those kinds of
> approval.
> > >>
> > >> Si
> > >>
> > >> Hans Bakker wrote:
> > >>> Si,
> > >>>
> > >>> we seem to have different viewpoints, that is
> normal and is no problem,
> > >>> however...
> > >>>
> > >>> when you state:
> > >>>> Do we really want to make it so that it has
> to be automated?
> > >>>
> > >>> that is is indeed my goal to make the
> accounting as easy as possible.
> > >>> You know why? Most, if not all enterpreneurs
> view accounting as a
> > >>> burden and should take as less time as
> possible.
> > >>>
> > >>> concerning the issue below, do not worry, i
> will implement this in the
> > >>> opentravel system only, i get a bit tired to
> spend so much time on
> > >>> convincing you. I rather spend the time to
> make the system better.
> > >>
> > >>
>

------------------------------------------------------------------------
> > >>
> > >>
> > >> _______________________________________________
> > >> Dev mailing list
> > >> [hidden email]
> > >> http://lists.ofbiz.org/mailman/listinfo/dev
> > >
> > >
>
------------------------------------------------------------------------

> > >
> > >
> > > _______________________________________________
> > > Dev mailing list
> > > [hidden email]
> > > http://lists.ofbiz.org/mailman/listinfo/dev
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> --
> Regards,
> Hans Bakker
> ANT Websystems Co.,Ltd
> (http://www.antwebsystems.com)
>
> If you want to verify that this message really
> originates from
> from the above person, download the public key from:
>

http://www.antwebsystems.com/hbakkerAntwebsystems.asc
> >  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[Hans Bakker]

Chris,
With the mentioned screens it is only possible to apply one and only one
specific paymentId to one and only one invoiceId

there are no other payment or invoices involved.

so the risk is minimal.

thanks anyway for your help.

regards,
Hans


On Thursday 06 April 2006 10:18, Chris Howe wrote:

> I'm sorry that I'm popping up in the middle of this,
> you guys seem to be on a roll.
>
> Hans,
>
> I apologize if I'm not following this thread
> correctly.
> Let me offer the following example and let me know if
> I'm describing the function of these screens
> correctly.
>
> The following Invoices for one customer exists
> 1000 for 95.00
> 1001 for 1195.00
> 1002 for 250.00
>
> One payment exists
> 1000 for 1275.00
>
> With a memo to apply as follows
> 75.00 towards inv1000
> 950.00 towards inv1001
> 250.00 towards inv1002
>
> You should only enter one payment.
>
> If someone mistakenly submitted with empty values,
> your default action would apply as follows:
> 95.00 towards inv1000
> 1180.00 towards inv1001
> 0.00 towards inv1002
> 1002 for 250.00
>
> An investigation would begin on the wrong invoices
> being shortpayed/nopayed
>
> This is a very common receivables transaction.  It is
> not limited to such a small percentage.  Which is why
> I think I may not be following this thread correctly.
>
> If I'm not following this thread correctly, just say
> "Chris, that's not what we're talking about"
>
> If I am following this correctly and a company is
> willing to take this risk in order to make for easier
> accounting, it only requires about 15 lines of code
> using the differences app approach that is detailed in
> the wiki.  That risk should be avoided though for the
> majority of ofbiz users.
>
> --- Hans Bakker <[hidden email]> wrote:
> > David,
> > I completely agree with you here, however there is
> > no 'higher up'
> >
> > screens: (at the bottom)
>
> https://localhost:8443/accounting/control/editInvoiceApplications?invoiceId
>=10000
>
> https://localhost:8443/accounting/control/editPaymentApplications?paymentId
>=10000
>
> > on this particular screen, one has to input an
> > invoiceId/paymentId and an
> > amount to apply, if the amount is empty or zero,
> > nothing happens, no message,
> > nothing. The reason the screen is here is that
> > payment can come from othere
> > sources then where the invoice was
> > sendTo/receivedFrom en the lists above it
> > do not apply.
> >
> > Before the chage, If you wanted to know the amount
> > tp apply, you have to go
> > manually to the related invoice/payment, check wat
> > can be applied, copy it,
> > go back and past the value. I cannot imagine that in
> > 99.9% of the cases you
> > want a lower value.
> >
> > Now with this change, the screen indicates that if
> > the field is empty or 0 the
> > maximum possible value will be applied, and a
> > success/error message tells you
> > what happened afterwards.
> >
> > regards,
> > Hans
> >
> > On Wednesday 05 April 2006 23:23, David E. Jones
> >
> > wrote:
> > > Hans,
> > >
> > > I also think is an important point. It is fine for
> >
> > applications to make
> >
> > > assumptions about the best value to put in but
> >
> > generally only in higher
> >
> > > level services whose job it is to make assumptions
> >
> > to simplify things, or
> >
> > > in the user interface itself where the user can
> >
> > see the assumption and
> >
> > > verify it or not.
> > >
> > > As a general practice this is a good pattern to
> >
> > make code less error prone
> >
> > > to reuse, and less error prone in general for both
> >
> > programmers customizing
> >
> > > it and end users using it.
> > >
> > > For this particular feature I think it's a great
> >
> > idea, but it should be
> >
> > > implemented "higher up".
> > >
> > > This is of course a discussion and others are free
> >
> > to join in, and it would
> >
> > > be great to hear more of your thoughts on this
> >
> > (including if you think we
> >
> > > are totally off base and as many details about why
> >
> > as you can include).
> >
> > > Thanks,
> > > -David
> > >
> > > Si Chen wrote:
> > > > Hans,
> > > >
> > > > On this note, can we reverse your changes of r
> >
> > 7172 for now?
> >
> > > > Si
> > > >
> > > > Si Chen wrote:
> > > >> Hans,
> > > >>
> > > >> I don't disagree that things should be as easy
> >
> > as possible.  However,
> >
> > > >> I think the issue is that accounting systems
> >
> > need to offer a high
> >
> > > >> level of control as well, so data can't be just
> >
> > entered or changed.
> >
> > > >> This is especially important to larger
> >
> > companies which use OFBiz.
> >
> > > >> When you modify lower level services to
> >
> > eliminate controls or steps,
> >
> > > >> it makes it hard to enforce those kinds of
> >
> > approval.
> >
> > > >> Si
> > > >>
> > > >> Hans Bakker wrote:
> > > >>> Si,
> > > >>>
> > > >>> we seem to have different viewpoints, that is
> >
> > normal and is no problem,
> >
> > > >>> however...
> > > >>>
> > > >>> when you state:
> > > >>>> Do we really want to make it so that it has
> >
> > to be automated?
> >
> > > >>> that is is indeed my goal to make the
> >
> > accounting as easy as possible.
> >
> > > >>> You know why? Most, if not all enterpreneurs
> >
> > view accounting as a
> >
> > > >>> burden and should take as less time as
> >
> > possible.
> >
> > > >>> concerning the issue below, do not worry, i
> >
> > will implement this in the
> >
> > > >>> opentravel system only, i get a bit tired to
> >
> > spend so much time on
> >
> > > >>> convincing you. I rather spend the time to
> >
> > make the system better.
>
> ------------------------------------------------------------------------
>
> > > >> _______________________________________________
> > > >> Dev mailing list
> > > >> [hidden email]
> > > >> http://lists.ofbiz.org/mailman/listinfo/dev
>
> ------------------------------------------------------------------------
>
> > > > _______________________________________________
> > > > Dev mailing list
> > > > [hidden email]
> > > > http://lists.ofbiz.org/mailman/listinfo/dev
> > >
> > > _______________________________________________
> > > Dev mailing list
> > > [hidden email]
> > > http://lists.ofbiz.org/mailman/listinfo/dev
> >
> > --
> > Regards,
> > Hans Bakker
> > ANT Websystems Co.,Ltd
> > (http://www.antwebsystems.com)
> >
> > If you want to verify that this message really
> > originates from
> > from the above person, download the public key from:
>
> http://www.antwebsystems.com/hbakkerAntwebsystems.asc
>
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc

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

[davidnwelton]

I'll poke my nose in:

>  Finally, I don't know why you are sending my private emails, since we both
> work on an open source project.  I have asked you repeatedly before to keep
> all our discussions on the public list so others can see it.  I think that
> is only fair, since there are other users of OFBiz whom our work would
> affect.

Speaking as 'the apache guy': I think this is very important for open
source projects.  Everything possible should happen out in the open so
that:

1) Other people can see it and participate (correct mistakes, given
opinions, or simply be informed)

2) Google can see it.

3) There's an archive of it.

Speaking as a potential OFBiz user: I don't understand the details of
what Hans is working on, but I 'feel his pain' to a certain degree.  I
don't have any specific examples on hand, but I get a feeling that
OFBiz could assist users more, throughout.  Actually, one example does
come to mind:

In the find orders page, there is a space for a party ID.  I can
guarantee, after listening to our phone support people, that customers
don't call with that sort of information in hand.  The prepared ones
call with the order ID directly, and everything is easy.  Most of the
others just have a name, and maybe the day they placed the order.
Having to click on the 'lookup party' link would cost time and money.

"Optimizing" the UI would be very beneficial, IMO.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[BJ Freeman]

Hans:
I am in the same boat as you, as far as features. Even the changes you
suggest are not adequate for my requirements.

However, my approach to this is not to try to force the ad hoc community
to accept what I need, but to implement them in my modules the provide
functionality I need.

This allows the Core code to remain as is but  allow me to provide the
processes I need.

I think you can see the mess that would happen, if every developer tried
to input changes that they may need, but the community as a whole does not.



Hans Bakker sent the following on 4/5/06 5:51 PM:

> Si,
>
> I do not know what you are doing, you are confusing several subjects.
>
> Implementation 7172 is critical for my operations. On your request i have
> added several user messages to this action later, i also updated the screen
> on your request.
>
> Further I protest that you publisize in this mailing list messages I send to
> you privatly.
>
> I strongly object that this change is taken out, this is causing me a lot of
> not required work, is causing that the application screen is not working and
> that there then not required messages in the system.
>
> i am sorry, i am starting to question your intentions here.
>
> further I apologize to the readers of this list that this message is public, i
> normally try to handle these problems in privat.
>
> Hans
>
>
> On Wednesday 05 April 2006 22:11, Si Chen wrote:
>
>>Hans,
>>
>>On this note, can we reverse your changes of r 7172 for now?
>>
>>Si
>>
>>Si Chen wrote:
>>
>>>Hans,
>>>
>>>I don't disagree that things should be as easy as possible.  However,
>>>I think the issue is that accounting systems need to offer a high
>>>level of control as well, so data can't be just entered or changed.
>>>This is especially important to larger companies which use OFBiz.
>>>When you modify lower level services to eliminate controls or steps,
>>>it makes it hard to enforce those kinds of approval.
>>>
>>>Si
>>>
>>>Hans Bakker wrote:
>>>
>>>>Si,
>>>>
>>>>we seem to have different viewpoints, that is normal and is no problem,
>>>>however...
>>>>
>>>>when you state:
>>>>
>>>>>Do we really want to make it so that it has to be automated?
>>>>
>>>>that is is indeed my goal to make the accounting as easy as possible.
>>>>You know why? Most, if not all enterpreneurs view accounting as a burden
>>>>and should take as less time as possible.
>>>>
>>>>concerning the issue below, do not worry, i will implement this in the
>>>>opentravel system only, i get a bit tired to spend so much time on
>>>>convincing you. I rather spend the time to make the system better.
>>>
>>>------------------------------------------------------------------------
>>>
>>>
>>>_______________________________________________
>>>Dev mailing list
>>>[hidden email]
>>>http://lists.ofbiz.org/mailman/listinfo/dev
>
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[Si Chen-2]

So coming back to this:

Why is there this section on the bottom of the screen anyway, where you can manually enter the invoiceId and paymentId?  Isn't there already a list of payments to apply higher up on the invoice applications screen, and a list of invoices to apply higher up on the payment screen?  When do you ever have to enter the invoiceId and paymentId anyway?

Si

Hans Bakker wrote:

David,
I completely agree with you here, however there is no 'higher up'

screens: (at the bottom)
https://localhost:8443/accounting/control/editInvoiceApplications?invoiceId=10000
https://localhost:8443/accounting/control/editPaymentApplications?paymentId=10000

on this particular screen, one has to input an invoiceId/paymentId and an 
amount to apply, if the amount is empty or zero, nothing happens, no message, 
nothing. The reason the screen is here is that payment can come from othere 
sources then where the invoice was sendTo/receivedFrom en the lists above it 
do not apply.

Before the chage, If you wanted to know the amount tp apply, you have to go 
manually to the related invoice/payment, check wat can be applied, copy it, 
go back and past the value. I cannot imagine that in 99.9% of the cases you 
want a lower value.

Now with this change, the screen indicates that if the field is empty or 0 the 
maximum possible value will be applied, and a success/error message tells you 
what happened afterwards.

regards,
Hans

On Wednesday 05 April 2006 23:23, David E. Jones wrote:
  

Hans,

I also think is an important point. It is fine for applications to make
assumptions about the best value to put in but generally only in higher
level services whose job it is to make assumptions to simplify things, or
in the user interface itself where the user can see the assumption and
verify it or not.

As a general practice this is a good pattern to make code less error prone
to reuse, and less error prone in general for both programmers customizing
it and end users using it.

For this particular feature I think it's a great idea, but it should be
implemented "higher up".

This is of course a discussion and others are free to join in, and it would
be great to hear more of your thoughts on this (including if you think we
are totally off base and as many details about why as you can include).

Thanks,
-David

Si Chen wrote:
    

Hans,

On this note, can we reverse your changes of r 7172 for now?

Si

Si Chen wrote:
      

Hans,

I don't disagree that things should be as easy as possible.  However,
I think the issue is that accounting systems need to offer a high
level of control as well, so data can't be just entered or changed.
This is especially important to larger companies which use OFBiz.
When you modify lower level services to eliminate controls or steps,
it makes it hard to enforce those kinds of approval.

Si

Hans Bakker wrote:
        

Si,

we seem to have different viewpoints, that is normal and is no problem,
however...

when you state:
          

Do we really want to make it so that it has to be automated?
            

that is is indeed my goal to make the accounting as easy as possible.
You know why? Most, if not all enterpreneurs view accounting as a
burden and should take as less time as possible.

concerning the issue below, do not worry, i will implement this in the
opentravel system only, i get a bit tired to spend so much time on
convincing you. I rather spend the time to make the system better.
          

------------------------------------------------------------------------


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

------------------------------------------------------------------------


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

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

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

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

[David E. Jones]

Hans,

It is simply not correct that there is no higher up. We are talking about a service that is called as a control servlet request event, and that is called from a form in another page.

So, there are various things on a higher level than this service that could be done. These _should_ be done instead of changing that service because the service changed (updatePaymentApplicationBd) is a fairly complex one that is used in other places and while isn't as big as some other issues I've seen in the past, or even that exist now, it is in general not a good pattern to follow because it introduces as assumption that is error prone in that assumptions may be made that the user might not notice and might not like later on...

This may not be the case with the specific form that you added that uses this default value, but it might creep in from calls to the service in other places and such.

That is why there is an objection to this change. It is nothing personal, in fact it has nothing to do with you or what you are trying to do. I would hope that objections would surface from such changes regardless of who they come from, including me.

So, maybe more detail is needed about what I meant by higher level changes to put in a default value instead of lower level ones. A couple of ideas:

1. UI layer approach: add a field to the UI for the amount to apply, and fill it in with this amount, perhaps after an initial submission so you know the IDs

2. logic layer approach: instead of changing a service that is used in other places to put in a default value that might not be desired, create a "wrapper" service that calls the other service with the default value; then just this new form would call this new service that introduces the default, and the more generic and lower level service isn't affected

I hope that helps.

-David



Hans Bakker wrote:

> David,
> I completely agree with you here, however there is no 'higher up'
>
> screens: (at the bottom)
> https://localhost:8443/accounting/control/editInvoiceApplications?invoiceId=10000
> https://localhost:8443/accounting/control/editPaymentApplications?paymentId=10000
>
> on this particular screen, one has to input an invoiceId/paymentId and an
> amount to apply, if the amount is empty or zero, nothing happens, no message,
> nothing. The reason the screen is here is that payment can come from othere
> sources then where the invoice was sendTo/receivedFrom en the lists above it
> do not apply.
>
> Before the chage, If you wanted to know the amount tp apply, you have to go
> manually to the related invoice/payment, check wat can be applied, copy it,
> go back and past the value. I cannot imagine that in 99.9% of the cases you
> want a lower value.
>
> Now with this change, the screen indicates that if the field is empty or 0 the
> maximum possible value will be applied, and a success/error message tells you
> what happened afterwards.
>
> regards,
> Hans
>
> On Wednesday 05 April 2006 23:23, David E. Jones wrote:
>> Hans,
>>
>> I also think is an important point. It is fine for applications to make
>> assumptions about the best value to put in but generally only in higher
>> level services whose job it is to make assumptions to simplify things, or
>> in the user interface itself where the user can see the assumption and
>> verify it or not.
>>
>> As a general practice this is a good pattern to make code less error prone
>> to reuse, and less error prone in general for both programmers customizing
>> it and end users using it.
>>
>> For this particular feature I think it's a great idea, but it should be
>> implemented "higher up".
>>
>> This is of course a discussion and others are free to join in, and it would
>> be great to hear more of your thoughts on this (including if you think we
>> are totally off base and as many details about why as you can include).
>>
>> Thanks,
>> -David
>>
>> Si Chen wrote:
>>> Hans,
>>>
>>> On this note, can we reverse your changes of r 7172 for now?
>>>
>>> Si
>>>
>>> Si Chen wrote:
>>>> Hans,
>>>>
>>>> I don't disagree that things should be as easy as possible.  However,
>>>> I think the issue is that accounting systems need to offer a high
>>>> level of control as well, so data can't be just entered or changed.
>>>> This is especially important to larger companies which use OFBiz.
>>>> When you modify lower level services to eliminate controls or steps,
>>>> it makes it hard to enforce those kinds of approval.
>>>>
>>>> Si
>>>>
>>>> Hans Bakker wrote:
>>>>> Si,
>>>>>
>>>>> we seem to have different viewpoints, that is normal and is no problem,
>>>>> however...
>>>>>
>>>>> when you state:
>>>>>> Do we really want to make it so that it has to be automated?
>>>>> that is is indeed my goal to make the accounting as easy as possible.
>>>>> You know why? Most, if not all enterpreneurs view accounting as a
>>>>> burden and should take as less time as possible.
>>>>>
>>>>> concerning the issue below, do not worry, i will implement this in the
>>>>> opentravel system only, i get a bit tired to spend so much time on
>>>>> convincing you. I rather spend the time to make the system better.
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [hidden email]
>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>> ------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[David E. Jones]

As I described in my other reply the issue is not between these 2 choices. The issue is not what was done but how it was done.

-David


Hans Bakker wrote:

> It seems that we cannot agree on a solution, so lets vote:
>
> in favor: (+)
> make the system easy to use with as less manual actions as required, but let
> the user decide which amount to put in but inform the user accordingly what
> is going to happen.
>
> against: (-)
> do not automate as much as possible but force the user to put in things  
> manually and force the user to check more.
>
>
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[David E. Jones]

Hans,


This does seem to be a problem, and the problem would be in the framework with the Service ECA funtionality and how error handling is done.

Depending on what the error is changing it from an SECA trigger to a direct service call may not actually help the error message since it is coming from the transaction manager. However, there is code in the TransactionUtil class to help get the original error and display that instead of the transaction error, so using that would be the proper way to go.

I think that not using SECA rules because the error messages aren't good isn't a good idea. That leads to just never using the SECA rules period, and I think they are an extremely valuable and important part of the OFBiz framework.

So, the proper solution is to fix the error message issue so that the improvement can help all of the SECA calls.

I'd be happy to look at this, but my time is limited right now so a brief list of steps to reproduce this from a clean OFBiz build and database would be extremely helpful.

-David


Hans Bakker wrote:

> On Thursday 06 April 2006 03:40, Si Chen wrote:
>> Actually, Hans - one good solution is for you to implement some
>> additional services which you can link to the main ofbiz services via a
>> seca in your open travel systems.
>
> Yes, if you can send a success message and a proper message when it fails it
> could be a solution. if you think that:
>
> Error calling event: org.ofbiz.webapp.event.EventHandlerException: Service
> invocation error (Commit transaction failed)
>
> is a proper message then yes it could be a good solution.
>
> However a much simpler solution would be to put this action in the service
> that is changing the status. No SECA, less services and proper fail/success
> message is possible then.
>
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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