I am taking a look and seeing what can be done regarding a current patch.
I think this is assuming (I didn't write this interface or design it so
this is necessarily conjecture on my part) that by default when paying a
vendor one would want to pay what one owed. On the batch interface we make
this assumption too (defaults to no vendors paid but when you select a
vendor, defaults to all invoices for that vendor).
So based on what we do in the batch interface, here's my proposed fix:
1) Radio button: Pay some/all, defaults to all (consistent with batch
payment interface). "All" disables removal links (see below) and grays
out amounts to pay. "Some" enables both.
2) Replace the checkboxes with [X] hyperlinks which are more obvious in
function.
Now this would make things more consistent across interfaces, but I am not
sure it would meet your specific needs based on what you are saying. 600
interfaces would be unusual (though not unheard of) for a single vendor to
be outstanding at any given time. Could you go into more detail regarding
your payment scenario? I would like to see what we can do to support it,
but I am afraid I am thinking maybe I don't understand what is leading to
this point as well as I would like.
Best Wishes,
Chris Travers
On Wed, May 22, 2013 at 7:20 AM, ario <[email protected]> wrote:
> On Tue, 2013-05-21 at 06:51 -0700, Chris Travers wrote:
> > Hi Ario;
> >
> > Checking the checkbox on the right says not to pay a specific invoice.
> You
> > can then click update and the invoice will disappear.
>
> In my opinion, a form with a number of possible entries should not (if
> not never) default to 'All' when a user didn't select anything yet but
> (maybe inadvertently) hits an execute button (or 'Post', as in lsmb).
> Nothing, except for a warning appearing like "You didn't select anything
> yet", should happen in that case. See it as one of Asimov's laws, but
> then for forms instead of robotics.
> Of course this is just my opinion, but if a program does not adhere to
> such a basic 'safety' rule, users might be in a permanent state of fear
> for even possibly dropping their whole db without wanting it, if they
> don't watch their steps very carefully. I think users should be allowed
> to feel safe while using a program, confident that nothing will happen
> as long as they don't select/choose/enter anything before hitting
> 'OK'/'Enter'/'Post' or whatever.
>
> So, what the Payment form should have in my opinion, is a 'Select
> All' (or 'Pay All' in lsmb) for the user who really wants to process all
> entries at once, not a 'Deselect All' (or 'Disappear' as in lsmb) if you
> don't want to process them all.
> After all, there is already a list of 'Amount Due's, so a checkbox
> saying: "select all lines for payment", subsequently filling all 'To
> Pay' fields with the 'Amount Due's (like there also is a checkbox
> saying: "select all lines for disappearing") should be possible, and in
> my view would be more appropriate then having all Amount Due's selected
> for payment by default.
>
> Also the name 'To Pay' (one of the possible meanings of that expression
> is exactly--and potentially confusingly--the same as 'Amount Due') could
> be chosen a bit less ambiguously, as for instance 'Paying now', 'Going
> to pay now', 'Marked for payment', or something like that.
>
> Just my opinion, thanks for reading it.
> ... wait, there's more below.
>
> > Here is what to do:
> >
> > SELECT * from payment order by id desc limit 1;
> >
> > Make sure this looks right before proceding.
> >
> > If you want to check the line items:
>
> Check 600 items... wouldn't that be a lot of work? Or do I misunderstand
> the procedure...
> Would it be more efficient to just undo all payments done on May 21,
> 2013 with some SQL statement, i.e.:
>
> 'select * from payment where date = 2013-05-21 ...'
>
> or something like that, and then to re-enter by hand the (very) few (I
> think it's more like 4 or so) that _were_ intended to be processed for
> that date?
> All transactions entered are tracked by session, and just before the
> mishap a complete backup was made and a new session was started, so that
> wouldn't be much (in fact very little) work.
>
> > SELECT amount, trans_id, transdate
> > from acc_trans
> > WHERE entry_id IN (select entry_id from payment_links where
> payment_id =
> > (select max(id) from payment));
> >
> > If that shows what you expect then:
> > DELETE FROM acc_trans WHERE entry_id IN (select entry_id from
> payment_links
> > where payment_id = (select max(id) from payment));
> >
> > DELETE FROM payment_links where payment_id = (select max(id) from
> payment);
> > DELETE FROM payment where id = (select max(id) from payment);
> >
> > Naturally do this in a transaction and make sure the results seem sound
> > before committing.
>
> I don't understand the 'do this in a transaction' part.
> I also don't understand the 'committing'.
> Is that like typing "COMMIT <ENTER>"?
>
> > Best Wishes,
> > Chris Travers
> >
> > PS, you may find cash/vouchers/payments more to your liking than the
> single
> > payment interface. Just make sure to approve the payment batches.
>
> My intention is just to process just one or a few payments, not to 'run
> batches'.
> I'm aware of the fact that this might sound a bit like nagging, or like
> resisting innovation or whatever, maybe just an insecure user, but when
> I want to do something, and a screen pops up asking me to 'start new
> batch', then it already scares me off as in:
> "What am I going to mess up _this_ time when creating a 'batch', and
> what is this batch going to do. And if I decide to not want to 'execute'
> the batch, will it ever go away, or will it stay there forever?"
>
> Sorry for your time, thanks for your guidance.
> Ario
>
>
> > On Tue, May 21, 2013 at 6:41 AM, ario <[email protected]>
> wrote:
> >
> > > Boys! What are you doing to me!
> > >
> > > I wanted to process a payment.
> > > So I go to 'Cash|Payment', give a 'Vendor Name' and click Continue.
> > > Ok, there comes the list with 600 [sic!] (see what's coming??) payments
> > > due.
> > > I select ONE payment, open the drop down, select the check box
> following
> > > the 'Source' field and click 'Update'.
> > > Ok, nothing happens (after all this is 1.3.29), so I click on 'Post'!
> > > BAM! 600 transactions paid! Disappeared!
> > > No! Not paid! Just disappeared, lsmb THINKS I paid them.
> > > wt.?
> > >
> > > You can't be serious with this.
> > > In the previous lsmb I used checking a checkbox meant paying THIS ONE,
> > > not all!
> > >
> > > <despair>
> > > Oh man...
> > >
> > > .
> > > .
> > > </despair>
> > >
> > > So, now what?
> > >
> > > Is there any way to roll this back?
> > > Or do I have to re-install lsmb, import the latest backup and re-enter
> > > all transactions after the last pre-backup session?
> > >
> > > Thanks for this exciting experience :)
> > >
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > Try New Relic Now & We'll Send You this Cool Shirt
> > > New Relic is the only SaaS-based application performance monitoring
> service
> > > that delivers powerful full stack analytics. Optimize and monitor your
> > > browser, app, & servers with just a few lines of code. Try New Relic
> > > and get this awesome Nerd Life shirt!
> http://p.sf.net/sfu/newrelic_d2d_may
> > > _______________________________________________
> > > Ledger-smb-devel mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
> > >
> >
> ------------------------------------------------------------------------------
> > Try New Relic Now & We'll Send You this Cool Shirt
> > New Relic is the only SaaS-based application performance monitoring
> service
> > that delivers powerful full stack analytics. Optimize and monitor your
> > browser, app, & servers with just a few lines of code. Try New Relic
> > and get this awesome Nerd Life shirt!
> http://p.sf.net/sfu/newrelic_d2d_may
> > _______________________________________________ Ledger-smb-devel mailing
> list [email protected]
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Ledger-smb-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
