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 <[email protected]> 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
>
>
------------------------------------------------------------------------------
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
