Re: You MUST be kidding me!

[ario <..hidden..>]

Hello Chris,

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

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.

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.

Not being an accountant, nor being well introduced in business
administration and cases, I didn't realise the extra-ordinary character
of my setup. 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. 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.

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.


> 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 you consider the lax payment requirements an 'agreement', yes, then
one could categorise them as that.

>   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?

>  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.

>         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.

>         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.
Ario


>         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 ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel