Re: You MUST be kidding me!

Hi Ario;

On Thu, May 23, 2013 at 5:59 AM, ario <..hidden..> 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