The solution proposed by @vivek looks good to me. It is by no mean a workaround. In fact, it shows the comprehensive use of functionality built into ERPNext.
I do not agree with this statement. Every science has its own terminology and so do accounting as well. If one tried to make logic out of technical nomenclature with how a language or common usage sounds, it will look like this statement.
Moreover, ERPNext has its own boundaries and the design convention. One has to adopt it as long as it’s solving the larger problem. If not, everyone will keep making their own customization and we will lose monolith purpose of ERPNext.
that’s ok and sounds good that you made one more option available for people to go for simplifies version (this is subjective) to book expenses, instead of going via item table.
I guess this could have been done by rearranging child table or adding additional filed into the child table. To make the first column as Cost Center, that’s more an ‘in list view’ setting and realignment work. For this, I do not see a need of creating additional doc_type
Are you proposing using an existing doctype for this child table? If so, that’s a nice idea. Which one did you have in mind? If I’m misunderstanding you, yes, it’s just reordering the doctype/ list view settings.
This is the solution you prefer? Just trying to make sense of this thread. My counter argument to this would be that the Purchase Invoice is already one of the most complicated and information-dense UIs in ERPNext. Making more than one workflow for the same document I think of as evidence of a poor UI. I do agree that @vivek’s design makes the best of what’s there.
I replicated what Vivek suggested here. Used some details from your screen. I have reordered ‘in list view’ for filed inside the ‘Purchase Invoice Item’ table.
Thanks Liyakat. There’s a bit of a mismatch here between accounts and Items, which I didn’t explain very well.
The child table in the Indirect Expense design is for splitting accounts. The child table in your design/ Vivek’s design is for Items. Items should be associated with an account by default but they don’t represent an account.
Using the electricity example from above, you may want to allocate some portion of the electric bill to a manufacturing expense and some portion to a general overhead type of expense. I find this to be a common use case for this interface. It is the default interface to pay bills in QuickBooks (which has no real concept of Items so it’s maybe not the best example).
One of the features that is “missing” from Purchase Invoice is the ability to book an Expense to more than one account head. (This can be done retroactively with Landed Cost Voucher, but it’s not designed for non-stock items and it just a gets to be a mess). Adding this feature would get you into an attribution problem (Items to Accounts) as soon as you have more than one item on the Purchase Invoice. In an SQL backed system there isn’t a great solution for a many-to-many relationship and it’s a very difficult thing to represent in a UI anyway. I think it’s better being sidestepped as often as possible, which has been the Frappe team’s solution.
I guess my larger point is that I see an Indirect Expense or Business Expense as more Journal-Entry-like than Purchase-Invoice-like and that that is a stronger start point to add this feature. Sorry for all the tangents; to me anyway, this is a deep, non-trivial problem.
this is interesting. Precisely in costing terminology this is called ABC (activity based costing). If you working on something like this with separate doc_type, then its a great feature to add.
I like that ABC term, I would have otherwise just called it “cost accounting”. The scope of the Indirect Expense feature does not relate to Items, only non-stock expenses. I haven’t tried pulling the electricity-example-expense into a Landed Cost Voucher, but that’s worth looking into and makes this design all that much more useful. Thanks for the suggestion.
This is a useful discussion and I agree there should be an easier way to input business costs than creating a heap of purchase invoices. Do you know if anything happened with this?
The use-case I have in mind is: let’s say the business director (or it could be a sole trader) goes on a shopping spree for setting up a new office. They buy the following, but don’t want to input separate Suppliers, Items, Purchase Invoices or Payments, and VAT should be the actual from the receipt:
Office desk - paid by business credit card, hits ‘Administration and Office Expenses’ expense and credit card current liability, main cost centre
Business cards - paid in cash, hits ‘Advertising and Promotions’ expense and cash current asset, marketing cost centre
Expensive printer - paid cash deposit the rest as credit, hits ‘Machinery’ expense, is an asset to be depreciated, accounts payable liability & cash current asset, main cost centre
Lunch meeting - paid by credit card, hits ‘Travel & Subsistence’ expense and credit card current liability, business development cost centre
Okay, I’m willing to admit line 3 should be done properly as a purchase invoice because of the account payable and asset, but the other 3 lines remain valid.
Employee expense claim is close but doesn’t allow input of VAT actuals or cost centres or assets or which asset/liability account to hit for payment.
If this were created as some sort of indirect/business expense doctype, it would ease migration from another ERP by allowing the import of (say) a year’s worth of expenses.
You can do a basic customization on purchase invoice item table as shown in the screenshot. And without creating an item on item list You can record the expenses by mentioning item name and expense head.
I see here the discussion mixes up between Purchase and Expense, which correlate
with Invoice and Receipt respectively.
I think the long-waited is the Expense booking voucher. Some companies call it Expense Voucher or Petty Cash Voucher or the like.
The difference:
Purchase Invoice creates AP which needs to be paid. Bills from utilities can use this becasue one can book it at start of month but pay it at the month end.
While Expense Voucher is directly paid (or has been paid), sort of Expense Claim (but this is specific for employee because it also creates AP from company to the employee).
So in my opinion booking Expenses should not use PI. It should have its own doctype and form. And using JE directly is not safe for non-accounting person.
I posted a feature request on GitHub for this #23307
Expenses in a monthly (or whatever else period) basis - Could be linked with some contracts… (create a rent contract - input all the information, as value, period…, and generate all the JV entries, bills…
Expenses as reinbursments - The way you are suggesting and doing is amazing!
