Re: You MUST be kidding me!

[herman vierendeels <..hidden..>]

also list entity.name for x payments from certain date

SELECT ac.amount,ac.trans_id,ac.transdate,ap.invnumber,e.name from
acc_trans ac,ap ap,entity_credit_account eca,entity e WHERE
eca.entity_id=e.id and ap.entity_credit_account=eca.id and
ap.id=ac.trans_id and entry_id IN (select entry_id from payment_links
where payment_id IN (select id from payment where payment_date
>'2013-05-01' order by id desc limit 5));


in psql : transaction
BEGIN
sql statemens
....
COMMIT or ROLLBACK



2013/5/23 Chris Travers <..hidden..>:
> 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
>
> ------------------------------------------------------------------------------
> 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
>