Michael:
Since you ask,
On 2022-05-17 7:16 a.m., Michael or Penny Novack wrote:
… These [business system] components would communicate to each other,
send "feeds" of "transactions" to each other…. One of the BIG
decisions when putting pieces together is where are the best places
for the division of labor. So I will ask Jim, have you carefully
considered that "right place" because this can have a huge affect on
the amount of "duplicate work".…
The answer to your question is "no". I have not carefully considered the
"right place" for a FreshBooks-GnuCash integration.
I imagine that FreshBooks sets its scope by what it thinks will make
profitable business for its target market: small businesses with no
internal financial app development. That led it to start with invoicing,
expand to time tracking, then later to accounting, and recently to
API-level integration with other apps. I imagine that GnuCash sets its
scope by what the volunteers contributing to it judge to be sensible and
achievable given the resources available. It seems that led them to
start with bookkeeping, and put a toe into the water of invoicing. I use
each of them because it is expedient. I don't imagine that it is easy to
turn these two apps into modules of a coherent architecture of the sort
you describe.
I don't know more about FreshBooks besides it being able to do hours
invoicing and accounting but you want the main accounting to be in
gnucash. But in deciding the dividing point, maybe you want more of
the accounting in FreshBooks and less in gnucash. In other words, move
SUMMARY data from FreshBooks to gnucash, not each transaction. Jim, in
the old days one of the simplifications of bookkeeping was "cashbook
accounting" where the majority of transactions were entered directly
into a journal-less mini-ledger and then once every so often (daily,
weekly, quarterly, etc.) a normal transaction transferring the TOTALS
(of this mini -ledger) to the main books. Meanwhile any transactions
that didn't qualify for the "cashbook" were entered normally into the
main books. So if in the period, the number of transactions entered
into the cashbook was C and the number entered directly into the main
books was M, the number of transactions entered into the main books
would be M+1 instead of M+C << when this method was used, it was
because C was ten times to a hundred times larger than M >>
Could something like this help your work flow?
Well, I understand that this can be a solution to some sets of problems
in general, but it is not the solution I prefer to my personal
situation. I don't have many invoices, so the effort of duplicate data
entry is low, and the savings from a software integration between
Freshbooks and GnuCash is low. I see value in having the main accounting
in GnuCash, because that way my data is under my control even after I
stop paying Freshbooks their annual feed, and because it is simpler to
generate reports when my data is all in one place. So maybe the answer
to your question is "yes". Duplication of invoice data entry is the
"right place" for my manual "integration".
My primary goal in starting this thread was to make other users of both
FreshBooks and GnuCash aware of a new potential for ad hoc integration
in their workflows. I just used my workflow as an example. But, if
someone happens to have an integration which I can re-use, I am happy to
know about it.
Best regards,
—Jim DeLaHunt
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
