Dev - [Fwd: [OFBiz] SVN: r7172 - trunk/applications/accounting/
Locked
Dev - [Fwd: [OFBiz] SVN: r7172 - trunk/applications/accounting/
 
|
Re: Dev - [Fwd: [OFBiz] SVN: r7172 - trunk/applications/accounting/
|
|
Si,
The reason that i put this in, is that when a payment is applied to an invoice on the screens in invoice and in payment, one has to figure out what the maximum amount is: first look at the invoice and then at the payment. Now the systems figures it out for you. You are always free to specify it yourself. That the user should be informed accordingly about this fact, i will add that in just a minute.... -- 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 On Tuesday 04 April 2006 03:47, Si Chen wrote: > Hans, > > May I ask what this feature is for? It seems a bit dangerous to assume > when no value is given here. > > Si _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
attachment0 (196 bytes)
Re: Dev - [Fwd: [OFBiz] SVN: r7172 - trunk/applications/accounting/
|
|
Re: Dev - [Fwd: [OFBiz] SVN: r7172 - trunk/applications/accounting/
|
|
Si,
at the moment the invoiceId or paymentId is inputted this value is not known and cannot be calcualted before hand. So what you are asking for is not possible. Regards, Hans On Tuesday 04 April 2006 20:37, Si Chen wrote: > Hans, > > I think you should implement your feature then by setting the maximum > amount on the form in the screen. It is dangerous to do it at a lower > level in the service because other users who use the service may have > some other intended purpose. > > Here's an email quote from David which I think is a good principle in > this case: > > If it is needed for a certain business process to make things easier, it > should go in the code for that higher level business process (as the > assumption in the low level process does not seem safe or accurate). > > If the intent is to make things easier for user interaction, the default > should be put in the UI. > > These are probably pretty good general guidelines actually, ie to make > as few assumptions as possible in the low level code and push them > higher up if they are really needed. > > --- > > Si > > Hans Bakker wrote: > > Si, > > The reason that i put this in, is that when a payment is applied to an > > invoice on the screens in invoice and in payment, one has to figure out > > what the maximum amount is: first look at the invoice and then at the > > payment. Now the systems figures it out for you. You are always free to > > specify it yourself. > > > > That the user should be informed accordingly about this fact, i will add > > that in just a minute.... > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > 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 |
Re: Dev - [Fwd: [OFBiz] SVN: r7172 - trunk/applications/accounting/
|
|
Re: Dev - [Fwd: [OFBiz] SVN: r7172 - trunk/applications/accounting/
|
|
Si,
i am sorry, i can only repeat what i wrote earlier, if you do not understand, tell me what is unlear. I do not see any danger in automatically generating it, it will only be active after the empty field is filled with an invoiceid or paymentid and the amount is not supplied. I wrote: > >>> The reason that i put this in, is that when a payment is applied to an > >>> invoice on the screens in invoice and in payment, one has to figure out > >>> what the maximum amount is: first look at the invoice and then at the > >>> payment. Now the systems figures it out for you. You are always free to > >>> specify it yourself. Hans On Tuesday 04 April 2006 21:33, Si Chen wrote: > Can you tell me exactly what sequence or screens you are trying to work > with? I'm sorry, but all I see is a feature that could potentially > cause problems and do not know what it's trying to fix, so I couldn't > really help you figure out how best to implement it. > > Si > > Hans Bakker wrote: > > Si, > > > > at the moment the invoiceId or paymentId is inputted this value is not > > known and cannot be calcualted before hand. So what you are asking for is > > not possible. > > > > Regards, > > Hans > > > > On Tuesday 04 April 2006 20:37, Si Chen wrote: > >> Hans, > >> > >> I think you should implement your feature then by setting the maximum > >> amount on the form in the screen. It is dangerous to do it at a lower > >> level in the service because other users who use the service may have > >> some other intended purpose. > >> > >> Here's an email quote from David which I think is a good principle in > >> this case: > >> > >> If it is needed for a certain business process to make things easier, it > >> should go in the code for that higher level business process (as the > >> assumption in the low level process does not seem safe or accurate). > >> > >> If the intent is to make things easier for user interaction, the default > >> should be put in the UI. > >> > >> These are probably pretty good general guidelines actually, ie to make > >> as few assumptions as possible in the low level code and push them > >> higher up if they are really needed. > >> > >> --- > >> > >> Si > >> > >> Hans Bakker wrote: > >>> Si, > >>> The reason that i put this in, is that when a payment is applied to an > >>> invoice on the screens in invoice and in payment, one has to figure out > >>> what the maximum amount is: first look at the invoice and then at the > >>> payment. Now the systems figures it out for you. You are always free to > >>> specify it yourself. > >>> > >>> That the user should be informed accordingly about this fact, i will > >>> add that in just a minute.... > >>> > >>> > >>> ----------------------------------------------------------------------- > >>>- > >>> > >>> > >>> _______________________________________________ > >>> 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 |
Re: Dev - [Fwd: [OFBiz] SVN: r7172 - trunk/applications/accounting/
|
|
Re: Dev - [Fwd: [OFBiz] SVN: r7172 - trunk/applications/accounting/
|
|
Si,
Yes that are the screens, however sometimes you (at least me) like to apply to invoices or payments which are not shown because they came from other sources. they can be filled in at the bottom. if you leave the amount empty, it will take the higest possible value. I feel pretty strong about this, it saves me a lot of time. Hans On Tuesday 04 April 2006 22:03, Si Chen wrote: > Well, I'm looking at this screen: > https://192.168.1.101:8443/accounting/control/editPaymentApplications?payme >ntId=10056 > > and this screen > > https://192.168.1.101:8443/accounting/control/editInvoiceApplications?invoi >ceId=10051 > > and both list the invoices to apply against with amounts already filled > in. So I don't even know which screen you are talking about. > > Can you take a screen shot? > > Si > > Hans Bakker wrote: > > Si, > > > > i am sorry, i can only repeat what i wrote earlier, if you do not > > understand, tell me what is unlear. I do not see any danger in > > automatically generating it, it will only be active after the empty field > > is filled with an invoiceid or paymentid and the amount is not supplied. > > > > I wrote: > >>>>> The reason that i put this in, is that when a payment is applied to > >>>>> an invoice on the screens in invoice and in payment, one has to > >>>>> figure out what the maximum amount is: first look at the invoice and > >>>>> then at the payment. Now the systems figures it out for you. You are > >>>>> always free to specify it yourself. > > > > Hans > > > > On Tuesday 04 April 2006 21:33, Si Chen wrote: > >> Can you tell me exactly what sequence or screens you are trying to work > >> with? I'm sorry, but all I see is a feature that could potentially > >> cause problems and do not know what it's trying to fix, so I couldn't > >> really help you figure out how best to implement it. > >> > >> Si > >> > >> Hans Bakker wrote: > >>> Si, > >>> > >>> at the moment the invoiceId or paymentId is inputted this value is not > >>> known and cannot be calcualted before hand. So what you are asking for > >>> is not possible. > >>> > >>> Regards, > >>> Hans > >>> > >>> On Tuesday 04 April 2006 20:37, Si Chen wrote: > >>>> Hans, > >>>> > >>>> I think you should implement your feature then by setting the maximum > >>>> amount on the form in the screen. It is dangerous to do it at a lower > >>>> level in the service because other users who use the service may have > >>>> some other intended purpose. > >>>> > >>>> Here's an email quote from David which I think is a good principle in > >>>> this case: > >>>> > >>>> If it is needed for a certain business process to make things easier, > >>>> it should go in the code for that higher level business process (as > >>>> the assumption in the low level process does not seem safe or > >>>> accurate). > >>>> > >>>> If the intent is to make things easier for user interaction, the > >>>> default should be put in the UI. > >>>> > >>>> These are probably pretty good general guidelines actually, ie to make > >>>> as few assumptions as possible in the low level code and push them > >>>> higher up if they are really needed. > >>>> > >>>> --- > >>>> > >>>> Si > >>>> > >>>> Hans Bakker wrote: > >>>>> Si, > >>>>> The reason that i put this in, is that when a payment is applied to > >>>>> an invoice on the screens in invoice and in payment, one has to > >>>>> figure out what the maximum amount is: first look at the invoice and > >>>>> then at the payment. Now the systems figures it out for you. You are > >>>>> always free to specify it yourself. > >>>>> > >>>>> That the user should be informed accordingly about this fact, i will > >>>>> add that in just a minute.... > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>>-- - > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 |
Re: Dev - [Fwd: [OFBiz] SVN: r7172 - trunk/applications/accounting/
|
|
| Free forum by Nabble | Edit this page |