Imported invoices and other problems...

Fri May 1 18:23:40 EDT 2009

Keep in mind that the QIF format is almost completely undocumented. To
support importing of QIF invoices, we'd first have to know what that even
looks like. I've worked on GnuCash's QIF importer for over a year (two?) and
I've never seen a single example. My guess is that you will not find any
decent explanation of this anywhere. Even worse, I'd bet that invoices are
not really exported from Quicken with all the required information, making
it impossible to import what Quicken cannot export.
However, if you would like to provide a sample QIF file containing invoices,
that might be very helpful.

Cheers,
Charles

On Fri, May 1, 2009 at 2:13 PM, jomali <jomali3945 at gmail.com> wrote:

> 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.
> >
> _______________________________________________
> 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.
>