Hi Ario;
On Thu, May 23, 2013 at 5:59 AM, ario <[email protected]> wrote:
> Hello Chris,
>
>
>
> I think I understand and agree with your position.
> For you this is business, albeit open source, so clearly your time is
> very valuable and also scarce.
>
It's not just that. It's that given the level of detail we can reasonably
get into on the email list, I can't at all be sure my suggestions really
meet your needs. What I can do at this point here is to give a general
idea of what to look at. It brings me benefits in the sense of better
exposure, more business, etc, so I don't mind helping out on the email
list. In general though detailed, specific help or touching someone's
servers requires consulting time though. I made the offer because I though
there significant chance that understanding your exact use case might allow
us to come up with a working solution with much less time and frustration.
Obviously of course it's just an offer and suggestion. Whether it makes
sense for you to go that route is something you have to decide.
Just keep in mind that at this point I don't understand your use case
enough to know whether the suggestions are on the mark or not. Otherwise
you get to figure out what questions to ask ;-). The question is, "would
an hour or so on the phone, over skype, chat, or the like allow us to come
up with a better solution faster and with less time, frustration, and cost
than would be possible otherwise?" I don't know about the cost
considerations on your side, so I can't answer that.
I did not write for help from you specifically, but was also thinking of
> a possible reply by Erik, _and_ assumed I was confronted with a
> non-desirable 'feature' of the Payment forms which led to my unintended
> manipulation of many records instead of a few. This it-is-a-bug
> assumption was what made me feeling having the 'right' to raise the
> issue, instead of just restarting from the latest previous backup.
>
First this feedback is helpful. There's a general realization that the
screen is not as intuitive as we'd like and so we do need to work on it.
I jumped in on this quickly because it seemed urgent from your viewpoint
and I wanted to help you get control over your books as quickly as possible.
>
> Not being an accountant, nor being well introduced in business
> administration and cases, I didn't realise the extra-ordinary character
> of my setup.
Just a couple of observations.
If you are trying to pay a couple invoices out of 600, this is going to be
somewhat error prone in all cases. The fundamental question is what can be
done to filter out the invoices that you don't want to pay. Hopefully the
features I mentioned get you most of the way there.
> So, not restrained by too much knowledge it was not
> difficult for me to complain about what happened in the manner as I did.
> However, as you explained before, it's not common (although not
> 'unheared of' :) to have so many unpaid invoices hanging around.
What is particularly uncommon here is to be so selective out of the
invoices you are paying with that many open. The question is what can be
done to help make the problem more manageable for you.
> I agree
> with that and would be perfectly happy if you'd spend your time with
> improving the software instead of looking for ways to help this case,
> let alone with making changes to lsmb based on this case.
>
First, in general my view on this is to ensure that changes that go into
LedgerSMB are generally applicable, so a general change would not likely be
made just to support your workflow. In my view, the fundamental questions
generally are:
1. What can be done to use existing features to meet your business needs?
2. What can be done outside of LedgerSMB to make this more manageable
(say, in how the invoices are entered, or the like)?
3. Are there other sides of the problem that need some adjustment in
LedgerSMB to meet in generally applicable ways?
In the end it is through looking at these sorts of issues that the software
is made better, because it broadens our understanding of how LedgerSMB is
used.
>
> What I mean to say is: don't bother. Really, I mean that. I'd be
> perfectly happy in keeping things simple until a thorough description is
> written down in the manual, so that pple wouldn't need individual help
> anymore to find out how to process things.
>
In that case, if you could maybe email me (and/or the other core team
members, Erik and Havard) on- or off-list with a description of your use
case (i.e. what your business does, how these invoices come in, etc.
> If you consider the lax payment requirements an 'agreement', yes, then
> one could categorise them as that.
>
The agreement can be "we want these paid separately." The one thing is you
need to know how to categorize the invoices at invoice creation time. If
you don't know about this at this time, then the on hold functionality
(basically telling LedgerSMB "this invoice is not available for payment").
>
> > If so set up one vendor account per payment agreement.
>
> In fact, there is no other agreement with those 'vendors', so it is
> already in the 'main account'. Or are you referring to the various
> departments in the vendor company?
>
If the departments are paid separately, they should have separate vendor
accounts.
>
> > Note multiple vendor agreements can be put under the same company,
> > but in 1.3 they cannot share billing/shipping address or contact info
> > (this is changing in 1.4 btw). Note that payment thresholds and the
> > like can be set per vendor agreement.
> >
> > >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.
> >
> >
> > Ok. There are some other features you can use to track these as well.
> > In particular payment threshold and setting invoices to be on hold (if
> > they are not to be paid now). With a large number of small
> > transactions, particularly if they are automated, I highly recommend
> > going with batch workflows. In this way there is basically an extra
> > review process between entry and hitting the books. Particularly in
> > automated environments this puts a human in control. In non-automated
> > environments, it lets you put someone in charge of data entry who
> > cannot modify the books directly.
>
> OK
>
> > 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'.
> >
> >
> > Actually, these sorts of complex invoicing environments are things we
> > try to support. In fact most of 1.3's development was sponsored by a
> > company who processes up to 5000 invoices per payment workflow (batch
> > payments), and where some vendors split payments in specific ways,
> > where fees are charged for issuing payments, and other things. So I
> > wouldn't say "unheard of." Without spending some time on the other
> > features used for invoice management, I can't tell you what if
> > anything needs to be changed in our interfaces to handle your specific
> > cases though.
>
> Ok, but I would still divert from the 'specific case' though, and refer
> to my original suggestion that in general forms that by default would
> manipulate a lot of data without any user input other than hitting
> 'Post', still might be undesirable.
>
The specific case may show something about the more general case.
>
> > 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.
> >
> >
> > Here are some features to take a look at carefully:
> >
> >
> > 1. Putting invoices "on hold"
> > 2. Multiple vendor accounts per company
> > 3. Batch workflows (these are batched for review).
> >
> >
> > It may be that these three features in some combination may meet your
> > needs. If not, then we should figure out what else is needed.
>
> Yes, thanks for the suggestions. I will let them 'sink in' and see how
> and when to implement them.
>
Sure. take your time.
>
> > 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.).
> >
> >
> > Hmmm actually as it occurs to me the better solution would be to go
> > through Cash/Vouchers/Payment Reversal (it does create a batch you
> > need to review but this is good because if you reverse the wrong
> > payment at least you catch it. And this is transparent from an
> > accounting viewpoint.
>
> Ok, Payment Reversal, I will see whether that works for me.
>
> Thanks again for your time, and for your explanations.
My pleasure,
Chris Travers
------------------------------------------------------------------------------
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
