Re: You MUST be kidding me!

Hi Ario;

Before I begin, I want to say there are a lot of new features in LedgerSMB for handling more complex business cases. I normally don't offer consulting to people writing the list for help outside of data corruption issues and the like, but in your case, there are a fair number of flags that indicate to me that it may be worthwhile to get some one on one time to go over business processes and how they map to new features. At least a very high level overview should be obtainable within an hour, and if you need more specific details, we could talk after that. I mention it because I suspect it will save you a lot of frustration later.

On Wed, May 22, 2013 at 9:56 AM, ario <..hidden..> wrote:

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.

So you need to group transactions by some sort of payment agreement? If so set up one vendor account per payment agreement. 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.

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.

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.

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.

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.

Best Wishes,

Chris Travers

Kind regards,
Ario