This may or may not make a difference performance-wise, and you may not prefer the result, but there is no rule that a transaction be limited to only 2 splits.
That is, if each real-world transaction affects more than two accounts, even if they could be separated, you can certainly combine them into a single transaction in GnuCash. So each might have a split to sales balanced by splits to commissions, shipping, coupons, cash, inventory, etc. Another approach is to generate a summary transaction for each business day. Thus you’d have only 365/6 sales related transactions per year. Of course you wouldn’t have any individual sale level data in GnuCash but most accounting programs don’t track that anyway. That level of data storage to be used for reporting and analysis purposes is usually handled by other software. (point of sale, inventory, etc.) Which (or both) you choose or if you continue as you are going now just depends on your own needs and what you want GnuCash to handle. My personal rule of thumb is for each transaction to model the real-world activity as close as possible. If I broke up some transactions just to try to keep them at only 2 splits each, I’d have lots of extra transactions compared to reality and my activity would be harder to analyze or even audit if a mistake is found. If the transaction reflects actual activity as a single unit, it is much easier to deal with later. Regards, Adrien > On Nov 17, 2019 w47d321, at 10:34 PM, M. Rizwan Muzzammil > <m.riz...@gmail.com> wrote: > > Hi, > > I should clarify that when I mean transactions I am referring to double > entries. Each business transaction, from the e-commerce stuff I do, outputs > on average five double entries: one each for sales, commissions, shipping, > coupons and so on. > > So 500k double entries would yield around 100k actual business transactions > over 3 or so years. > > The software is not slow to the point of being non-functional or a even > frustration. It is only that I prefer a tad bit more sprightliness. Also it > seems to run perfectly well on my relatively slower laptop which just has > 6GB of RAM. > > Noted about the loading of transactions to memory. I will keep a closer eye > on the memory footprint. > > Unfortunately my programming experience is limited to VBA on MS Excel. I > have sadly not worked with apps, and with databases only very little. I am > not sure how I could contribute to the development over someone with actual > database experience. > > Thanks, > > Rizwan _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
