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 <[email protected]>: > Hi Ario; > > > On Thu, May 23, 2013 at 5:59 AM, ario <[email protected]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel > ------------------------------------------------------------------------------ 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
