[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: You MUST be kidding me!

On Wed, 2013-05-22 at 07:50 -0700, Chris Travers wrote:
> 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.

There's a lot of this new lsmb version that I'm still not familiar with,
or even need to use. So I would warn against maken specific changes only
because of my special use case, because that's what it is.
Except for what I mentioned before with respect to protecting users
(like me :) who still don't know exactly what they are doing, against
doing something 'unintended' (to put it mildly).

The case I'm dealing with is a lot of AP and AR transactions between
3... how shall I say it... 'connected'?, 'befriended'?, 'companies',
which are not or partially paid. In each 'company' about 3 departments
are involved, and therefore not all transactions of 1 day can be put in
1 invoice. 
>From time to time one or some of the invoices are being partially paid,
hence the unusually large amount of unpaid invoices: a daily amount of
small transactions without cash exchange.
Yesterday was the first time I used my new (1.3.29) lsmb to process a
small number of those payments, with the result mentioned.

I don't know what you mean by '600 interfaces'. It's in my world a list
of 600 open invoices between 2 companies. But maybe that's the word you
meant to use: 'invoices'.

Reading your comments and re-thinking the situation I realise now that
this could indeed be categorised as 'unheard of'. So maybe a reason
indeed not to invest too much time, if at all, in improving your
software for a case that seldom occurs or maybe even shouldn't occur at
all in a professional accounting environment.

However, I'd still be very happy if you could elaborate a bit the
'recovery' procedure you suggested, but taking into consideration my
remarks (e.g. about using the date as an id for the payments to delete,
etc.).

Otherwise this still could be a good opportunity to install the newest
available debian lsmb package, upgrade it to 1.3.32, and import my
backup from 1 day ago, although I'd prefer to just 'fix' this with some
SQL statements, re-do some 4 or 6 payments, and upgrade just by
unpacking the newest version over the current one.

Kind regards,
Ario



> Best Wishes,
> Chris Travers
> 
> 
> On Wed, May 22, 2013 at 7:20 AM, ario <..hidden..> 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 <..hidden..>
> > 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
> > > > ..hidden..
> > > > 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 ..hidden..
> > 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
> > ..hidden..
> > 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 ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel