[Gnucash-changes] r13417 - gnucash/trunk - Bug#332802: fix Export Accounts; remove `price_lookup` and `export` functions from GncFileBackend.

[Josh Sled]

On Tue, 2006-02-28 at 08:06 +0000, Neil Williams wrote:

> The only problem with export is that it's now been moved into the QofBackend 
> where it is still deprecated, but I'm glad we're not using price_lookup 
> anymore (also deprecated). 

Well, at least now it's "deprecated but working" vs. before, when it was
"duplicated, deprecated (twice) and not working". :)  I did notice the
same thing while looking at this: there's no reason that this task needs
to be part of the the backend ... there's no reason the app alone can't
assemble the sub-graph of objects needed to fulfill the user request and
serialize it.  But as we approach a release, I just wanted the smallest
needed to get the thing to work.


> What's the functional difference between the two Export commands on the File 
> menu?

Export accounts exports just the accounts and commodoties as GnuCash
XML, easily File>Open-able.

Export Chart of Accounts exports the accounts and opening balance
transactions as QSF.


> Should we just export the Accounts as QSF - without any starting balance 
> Transactions and Splits?
[...]
> then ditch export completely?

Well, it's nice to have something which exports *just* the account tree,
if only to create the example account trees in the distribution.  Of
course, this could easily be done via post-processing of a datafile to
remove everything but the accounts.

Here, both versions of "export accounts" are poor substitutes for "Close
Books", and they both suck in their own special ways:

- Neither handle the business objects, scheduled transactions, or 
  budgets, reports, user-interface state...
- Neither exports any pricedb data that might be relevant.
- The old one doesn't transfer end-of-year balances.
- The new one doesn't export commodities.

I find the fact that the new one is in QSF to be a negative, but that's
arguable.


I think the real solution is to merge the two, support the full range of
data one might want to export at end-of-year, and have the user select
if they want a gnucash datafile (default) or QSF (or any other backend).
There's a temptation to make this a super-generic arbitrary data
exporter, but we shouldn't do that.

And, we should get book-closing to work.  I just played with it and it
seemed to do some non-obvious thing without much feedback and certainly
with some ui quirks.

In any case, the existing functionality works, and there are more
pressing concerns w.r.t. the release, so I'm probably going to leave
this alone for a while.

-- 
...jsled
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`