Imported invoices and other problems...

jomali jomali3945 at gmail.com
Fri May 1 17:13:04 EDT 2009


It amazes me to see that some people who choose to use *free* software,
developed and maintained by volunteers, become as demanding as those who pay
for commercial software. Gnucash has been in development for many years by a
small but very capable team. That team is very responsive to users who need
help and they eventually incorporate desired features that make sense to a
significant portion of the user base. If the current features don't fit your
needs, perhaps a commercial package will.

John

On Fri, May 1, 2009 at 11:07 AM, defaria <Andrew at defaria.com> wrote:

>
>
> 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.
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>


More information about the gnucash-user mailing list