I often get accused (not just here) of leaving something critical out.
Jumping over the obvious, just not so obvious to all.
On 7/26/2018 11:21 AM, John Ralls wrote:
All sharing the same feed format << and each "make" dependent on THAT
but not each other, or for that matter gnucash except with regard to
the format of the feed >>
THIS is perhaps what I am not making clear enough. We have been seeing
calls for gnucash to be able to handle inventory, pos, and here payroll,
etc. Functions important to businesses, functions which for some would
be simple systems but for others very complex. Functions which are doing
many things unrelated to accounting. But which share IN COMMON that they
all would create transactions for accounting.
That is the main reason I don't think of these as much suited to be
"plug ins" as independent systems that create feeds for the accounting
system (send transactions to the accounting system) because the
accounting system then only needs ONE method of receiving feeds from
whatever outside systems exist. And businesses that have grown beyond a
couple employees, grown to the point where employee X does payroll/hr,
employee Y does inventory, etc. but none of those employees should
necessarily have access even to look at the company books.
This would also allow for multiple solutions for these "outside"
functions, simple ones for those whose needs are simple, and complex
ones for those whose needs are complex (assuming that somebody would
create powerful versions). Thus in this discussion with regard to
payroll, some say "well I can do it with a spreadsheet, how hard could
it be" while other see the need for a powerful system able to deal with
all sorts of complication (exempt, vs non-exempt, differing
jurisdictions applying, standard taxes vs voluntary larger amounts
withheld, etc. on an employee by employee basis) << inventory and pos
have similar simple vs complex issues -- thus for pos, not only do
different jurisdictions have different tax rates but differ on what is
taxable (and at what rate) and may depend on where the customer
lives/goods delivered and on the tax status of the customer << and if a
tax exempt organization, is the paperwork submitted for this transaction
--- a complication not obvious those who do not interact with tax exempt
entities* >>
Michael D Novack
* As somebody who keeps books for exempt organizations, obvious to me
form the customer end of things (what paperwork needed to be submitted
so NOT charged sales tax on an otherwise taxable purchase) but not on
the vendor's side of that problem, how their system enters the
transaction. And BTW, even things like "where" not so obvious -- mailing
address for a location might not indicate the correct state for sales
tax purposes as postal routes do NOT respect state boundaries << thus
where I used to work, customer records kept both "mailing" and "legal"
state as insurance law is state by state >>
_______________________________________________
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.
