Re: [GNC-dev] Fwd: [GNC] UK VAT and "Making Tax Digital"

2019-05-05 Thread Christopher Lam
Just wondering -- barring the capital purchase issue (which is easily
resolved by expanding the sales/purchases account selection to *all*
account types), is the GST report able to handle EC VAT splits? I think it
does...

Opinion welcome at
https://github.com/Gnucash/gnucash/pull/500#issuecomment-489482829 ...

On Fri, 3 May 2019 at 02:13, Maf. King  wrote:

> Hi Christopher,
> thanks, I've just subscribed to -devel
>
> I can see no reason for anything other than GBP in a UK VAT return!
> sensible
> restriction.
>
> Maf.
>
>
> On Thursday, 2 May 2019 16:44:59 BST Christopher Lam wrote:
> > Maf's reply forwarded to devel.
> >
> > I think a sensible restriction to vat-report will be: all amounts *must*
> be
> > converted into a report-currency... which will then ensure there's only 1
> > currency for grand-total, therefore 1 heading + 1 grand-total = 1 csv
> row.
> >
> > -- Forwarded message -
> > From: Maf. King 
> > Date: Thu, 2 May 2019 at 13:36
> > Subject: Re: [GNC] UK VAT and "Making Tax Digital"
> > To: Christopher Lam 
> > Cc: gnucash-devel 
> >
> >
> > Hi Christopher,
> >
> > responses inline:
> >
> > On Thursday, 2 May 2019 12:36:06 BST Christopher Lam wrote:
> > > Are you referring to the Multicolumn report with multiple embedded
> >
> > reports?
> >
> > > This one would be very annoying to create CSV export from... each
> embedded
> > > report exposes its html output only.
> >
> > That was the report I was thinking of, not surprised that CSV would be
> hard
> > to
> > generate.
> >
> > > The links I attached earlier (replacing transaction.scm and
> > > income-gst-statement.scm) would enable CSV export, exposing the headers
> >
> > and
> >
> > > the grand-totals.
> >
> > Correct, that is what I see.  but the totals are wrong because the report
> > can't consider the asset purchases.
> >
> > > Meanwhile I'm rather more interested in generating a proper solution
> :-)
> > >
> > > For UK VAT I'd think the more complex requirements here would warrant a
> > > customised solution based on the existing VAT account structure, rather
> > > than to try shoehorn hacks on the existing report.
> >
> > Fair enough.  I guess the GST report was written with Oz in mind and then
> > generalised a bit.
> >
> > > If you can create a sample datafile based on the CoA as suggested by
> > > New-account wizard,
> >
> > No problem, will take your template file and try to get that sorted over
> > the
> > weekend or early next week.
> >
> > thanks,
> > Maf.
>
>
> --
> Maf. King
> PGP Key fingerprint = 8D68 A91F 733B 2C1F 43B7  2B7C E591 E8E1 0DE7 C542
>
>
>
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] How to contribute to GnuCash?

2019-05-05 Thread John Ralls
Yes, that's it. Sorry, I misunderstood the buttons at the top and thought I was 
looking at weekly data instead of daily. I'll leave it to you to explore the 
stats.

Regards,
John Ralls

> On May 5, 2019, at 10:20 AM, John  wrote:
> 
> I am a little bit confused. are you saying this one: 
> https://sourceforge.net/projects/gnucash/files/stats/timeline? why it shows 
> different numbers as you said? do you have any internal report instead of 
> this public information?
> 
> Thanks,
> John
> 
> On Sat, May 4, 2019 at 6:22 PM John Ralls  wrote:
> I don't have most of that info. We don't have any analytics on the website. 
> SourceForge reports a pretty consistent ~1000 downloads per week with spikes 
> to ~5000 right after releases, mostly for Windows. We've had a further 1400 
> downloads from Github since the release at the end of March. We have no 
> visibility of installs from Linux or BSD package managers.
> 
> GnuCash for Android has had 809 downloads from Github since the last release 
> in June 2018, but most GfA installs will be from the Play Store and you'd 
> have to ask Ngewi about that, I don't have access to that information.
> 
> Regards,
> John Ralls
> 
> 
> > On May 4, 2019, at 5:44 PM, John  wrote:
> > 
> > Thanks for the details. That will help a lot. Before jumping into the code, 
> > we still have some questions about the project popularity, can you guys 
> > share some info about gnucahs.orghomepage user traffic like daily access or 
> > monthly access number? also what is android app total download number so 
> > far, and the number for daily download, daily or monthly active users? hope 
> > you guys don't mind we ask these info.
> > 
> > Best,
> > John
> > 
> > 
> > On Tue, Apr 30, 2019 at 1:56 PM John Ralls  wrote:
> > Guile is a Scheme interpreter built into GnuCash, see 
> > https://www.gnu.org/software/guile/. You don't need to worry about it.
> > 
> > You should start by looking at Ngewi's GfA code at 
> > https://github.com/codinguser/gnucash-android to get an idea of how he 
> > handled it.
> > 
> > If you want to use GnuCash code directly in your app you need to figure out 
> > what the app is going to do, what accounting objects you'll create, and how 
> > you want to instantiate them, then look at the corresponding accounting 
> > objects in https://github.com/Gnucash/gnucash/libgnucash/engine. Those 
> > objects are loaded from storage, either XML or SQL, with 
> > https://github.com/Gnucash/gnucash/libgnucash/backend.
> > 
> > There's some API documentation at https://code.gnucash.org/docs/MAINT.
> > 
> > Regards,
> > John Ralls
> > 
> > > On Apr 30, 2019, at 11:00 AM, John  wrote:
> > > 
> > > Thanks for all the info. We are new to Gnucash code. what is guile? how 
> > > to set up the engine code? what exact source code files should we start 
> > > to look at for this iOS companion app? how to quickly understand the code?
> > > 
> > > Thanks,
> > > John
> > > 
> > > On Sat, Apr 27, 2019 at 7:29 AM Geert Janssens 
> > >  wrote:
> > > Op zaterdag 27 april 2019 16:05:42 CEST schreef John Ralls:
> > > > > On Apr 26, 2019, at 10:55 PM, Geert Janssens 
> > > > > 
> > > > > wrote:> 
> > > > > Op zaterdag 27 april 2019 01:01:38 CEST schreef John Ralls:
> > > > >> What Geert meant is that our current engine code *isn't* particularly
> > > > >> portable, though I think that since it compiles OK on MacOS it 
> > > > >> shouldn't
> > > > >> have too much trouble with iOS either. It's a mix of C and C++ and 
> > > > >> the
> > > > >> main
> > > > >> dependencies are Boost and Gnome Glib; the XML file backend also 
> > > > >> depends
> > > > >> on
> > > > >> libxml2 and the SQL backend depends on libdbi.
> > > > >> 
> > > > >> The public mirror for our git repository is at
> > > > >> https://github.com/gnucash/gnucash. Note that the stable branch is
> > > > >> "maint".
> > > > >> Doxygen API docs are at https://code.gnucash.org/docs/MAINT.
> > > > >> 
> > > > >> Regards,
> > > > >> John Ralls
> > > > > 
> > > > > The devil is in the details... The engine code currently still 
> > > > > depends on
> > > > > guile as well, which is a scripting language. Doesn't Apple impose
> > > > > restrictions on that ?
> > > > > I currently don't have a full overview of where guile is used in the
> > > > > engine
> > > > > code. I know the option system is heavily dependent on it, but that's
> > > > > primarily used by the report system.
> > > > 
> > > > There's no guile in the backends, and only a little in engine, core 
> > > > utils,
> > > > and gnc-module for facilitating the wrappers. App-utils is heavy with
> > > > scheme but that's to support application features like options and the
> > > > financial functions for scheduled transactions, and price-quote is 
> > > > scheme.
> > > > I think John's team can set up a build of just engine and the backends 
> > > > they
> > > > want to support without swigging and so without guile. That should be
> > > > enough for a companion project similar to G

[GNC-dev] Use trading accounts only for currency conversion

2019-05-05 Thread cicko
As I've written in https://bugs.gnucash.org/show_bug.cgi?id=797227:

I suspect that the purpose of the trading accounts was to account for the
loss/gain in currency conversion (only). Not sure if applying the trading
accounts for other commodities makes sense. These should be accounted for
through Capital Gains/Losses accounts.
I find that mixing other commodities trades in trading accounts almost
destroys their usefulness.
Limiting their implementation to Currency commodities only would make more
sense. What do others think?



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel