[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: You MUST be kidding me!
- Subject: Re: You MUST be kidding me!
- From: herman vierendeels <..hidden..>
- Date: Sat, 25 May 2013 11:59:21 +0200
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
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
>> 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
>> > 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.
>> 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