There is another, simpler, option, such as:
Sales
and that's it.
If you're using the Business Features and will be creating Invoices for
your sales, then the invoice line items will contain the individual
product sales data. (you also might have separate sub-accounts under
Assets:Inventory for each item) By default, this is not exposed for
reporting, but if you unset the preference to 'consolidate splits on
posting' then each line item will appear in affected registers. From
there, you can craft Transaction Reports that filter based on say, the
name of the product allowing you to create an aggregate sales report.
(you can do this per invoice, or set a global preference)
I'm not sure what your use of 'Shop A' and 'Shop B' is in the real
world. Are these just separate physical locations of the same business?
If not, and these are distinct business entities, the usual
recommendation is they should have their own individual books.
If they are just different sales locations, you can put that info in the
Invoice line items as noted, and use the Transaction Report filter tab
on that text as well. Or, you can go so far as to create:
Sales:
Shop A
Shop B
The line items will contain the product data, and the posting account
will segregate the sales locations. These can be selected per invoice.
There is also a custom 'Tag' version of that report floating around on
this list. Look for the user 'flywire' to find posts linking to it.
(it's on Github I think)
If you aren't going to use the business features and will simply be
doing manual sales transactions (imported, or created individually),
then you can use a similar approach with filtering and/or tagging and
put the 'shop' location either in the Description, Notes, or Action
field. (use Double Line view mode to see Notes) Or as above, create
sub-accounts under Sales.
The only report that can't filter/tag nicely at present is the
P&L/Income Statement, but you could craft something via the Transaction
Report to get close.
Further possibilities open up if you export said reports to a
spreadsheet app for further manipulation if you can't get exactly what
you want within GnuCash.
Any of the above approaches would remove the either/or situation you're
contemplating and open up more flexibility down the road should you need
it without having to refactor your historical transactions or account
structure as you find your needs change.
Regards,
Adrien
On 5/1/24 3:30 AM, Patrick Skelton wrote:
I am about to structure a new set of accounts for a business. GnuCash uses
a hierarchy, which I am currently trying to decide upon. Two
part-hierarchies come to mind:
*FIRST*
Sales
Shop A
Product 1
Product 2
Shop B
Product 1
Product 2
*SECOND*
Sales
Product 1
Shop A
Shop B
Product 2
Shop A
Shop B
The first would make it easy to see sales for each shop but harder to find
out the sales for each product. The second would make it easy to see sales
for each product but harder to find out the sales for each shop.
Both of these seem like reasonable questions to be able to ask of the
accounts. How do I choose which hierarchy to go with and is there any way I
can answer both of these questions?
Any advice would be most welcome as I am no accounting expert and have only
basic knowledge of GnuCash.
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
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.
