Imported invoices and other problems...

[defaria]

Derek Atkins wrote:
> 
> Oh, I understood just fine.  You're just confused about what you told
> gnucash to do.  You provided a QIF file that has an account that contains
> all your invoice transactions.  There's nothing special about that account
> in the QIF file, nothing that says that there's extra metadata.  In other
> words, this is data you don't want imported, so don't try to import it.

I had no reason to expect that Gnucash would not handle it. Indeed, my
expectation would be that it would work, not not work. I think such an
expectation is reasonable. As a heuristic Gnucash could at least warn about
importation of accounts that contain the string "Invoice" in their name. Not
foolproof I admit but helpful.


GnuCash is doing exactly what you're telling it to do.  The "corruption" is
in the QIF file itself that apparently contains data you don't want
imported.

No I do want the data imported - I just want it properly imported. I had the
expectation that it would be. I did not know that it was not supported.


What I'm suggesting is that you hand-enter the not-yet-paid invoices as your
migration path.  You're welcome to keep around the old data so if you need
to look at historical data you can still do so, but just use GnuCash going
forward.

That's not a very good solution.

Did you run:  apt-get build-dep gnucash
> And then try to build GnuCash?

Now why didn't I think of that? Oh yes, because it's not what most people
would naturally think to do... I guess I could get in the business of
building Gnucash, even though I only wanted to be in the business of using
Gnucash.



>  It's called convenience and ease of use. It's called what the customer
> wants and the customer is... Well you know.
> 
> You're not a customer, you're a user.  If you were a customer then you
> would be paying my salary (directly or indirectly).  You're not, so you're
> not a customer.

You could make that distinction but you'd be unwise to do so IMHO. I've been
working in business now for 30 years. We consider other people in the
company who use our services our applications as "customers" - internal
customers. It's a service attitude, not a distinction of payment. You'd be
wise to adopt such an attitude. This is why programs like Gnucash and Linux
in general will never be taken seriously or be anything other than a niche
market by the vast majority of people out there. A lack of respect for
"customers" or users of their product. Oh yes, application, not product.
Products are paid for...


As for convenience, well, the menu item is always available..  And seriously
a UI with hundreds of buttons everywhere just clutters the window.  Or you
wind up with a row of dozens of tiny little icons that honestly don't mean
anything at all to the novice user.

Your committing a fallacy by blowing things out of proportion. I didn't ask
for "hundreds of buttons" I asked for one. Vastly different situation! Other
programs, ones that people will actually bother to purchase, have such
things without driving paying customers away. How do they manage to do that?
Answer is, in the end, hundreds of buttons are not required, only a smaller
set are, and, if intelligently design, with the customer or end user in
mind, it adds to the appeal of both current users and new potential users
alike. Such phenomena has been observed countless times in the real business
world... But let's just through out this little suggestion as the guy is
asking for hundreds of buttons!


It's very easy (and quite well documented) that all business functions are
available under the Business menu.

Geeze! Remind me not to ask for an enhancement with you...



>  How is moving something cluttering a UI? You know you could move it.
> Also, having multiple places to do the same thing is something that
> abundant in many software systems. Why the economy here? It really is not
> that difficult to handle the concept of being able to edit terms in
> multiple places. If the "we should limit things to only one place to avoid
> cluttering up UIs" mentality were taken to the extreme the the only way to
> remove a file should be to drop into a command line and issue an rm
> command - yet Nautilus and countless other applications allow you to
> delete things. Indeed some might consider the UI less cluttered if such
> occasionally done things were not on the main UI itself under the menu but
> rather buried down to where you are actually using terms. You see, there
> are many ways to look at things...
> 
> Of course, but not all ways of looking at things are correct.  :-D

And yet many ways are not incorrect and are indeed useful many people yet
you seem to dismiss it out of hand without much consideration. Different
people work in different ways. You are choosing a path of alienation instead
of consideration.


If you disagree you're welcome to send in a patch to make it work the way
you think it should.

Oh yes! That's why I'm here. To do development work on yet another piece of
software I'd much rather just use... You've already shown you are not open
to doing it in a different way so my changes would probably not be
incorporated into the main branch.  I would have to spend my time maintain
my own version... Hmmm... I think I'll pass...
-- 
View this message in context: http://www.nabble.com/Imported-invoices-and-other-problems...-tp23279778p23334608.html
Sent from the GnuCash - User mailing list archive at Nabble.com.