I also got same error. It seems mandatory to have one item line for using purchase invoice document. It is not allowing only ledger account under charges and taxes table.
Can you please confirm, post replicating this
I also got same error. It seems mandatory to have one item line for using purchase invoice document. It is not allowing only ledger account under charges and taxes table.
Can you please confirm, post replicating this
But why even an item name, when there is no item
Item name can be anything, like rent etc… you can keyin anything in item name field
yes, this is working for me now. We had some customization but we fixed it so we can still enter anything item name.
its working for you!
do you mean you are using Purchase Invoice to book the expense of non-item type. For eg- Rent expense or Office Stationary etc?
Could you please share a screencast of submitted expense doc using PI for review?
This is a personal frustration of mine, so I fixed it. I am working on getting it into the core, but I have other dependencies in front of it that need to make it in, which is currently an open pull request. @lalnco Liyakat, it’d be good to review what I’m up to with another credits-and-debits guy before I make a pull request.
@tmatteson there is not debit and credit relation with line items.
But having said that such feature of expenses is needed by many small businesses. I have seen some accounting softwares giving feature like “Business Expenses”, which where they enter the expenses without line items, and an account headers is created in the ledger, etc.
I suggest rather than merging it with existing Purchase, there should be a seperate DocType like Business Expenses like Expense Claim- (which is basically for employees, we dont want that, we want business expenses)
I too feel such thing is needed badly. I am willing to contribute as well. Let me know if we can collaborate for this feature or PR.
Regards,
Parth Joshi
@joshiparthin You could create a new select field with option “business expense” and “normal” perhaps. Restrict Purchase document for employee against business expense only. You can create a generic item and tag its default account to the expense ledger of ur choice.
This simple front end customization should simulate what your looking for
@vivek it works but not intuitive for booking expenses especially in Trading Businesses.
I have never heard anyone “Purchase” their “telephone expenses”
I use Journal Entry for booking expenses now
Ideally @joshiparthin comment need to be implemented for booking expenses
@Savad_Ibrahim What I suggest my clients even in trading business is the same, they have a category called Utility Suppliers, with the companies providing services for telephone, electricity , rent etc in Supplier master with all details filled in. When they receive the invoice from these suppliers the same is created as purchase invoices with payment details on the same invoice itself. They scan the physical copy and attach it with the same document. Many of my clients arent familiar with Journal Entry - debit & credit for them its more intuitive to use a simpler document like Purchase Invoice. But at the end of the days its simply preference and familiarity. But my point in the earlier post was to avoid the redundancy of creating a new doctype when the same can be done effective via purchase invoice
So,the reports will be showing your stock purchases along with your Electricity bill before you filter them. That is again a problem for me .
To avoid redundancy,i would love if we can have two list views for same doctype Purchase Invoice for item Purchase and Expense entry.
Similarily i always wished to have seperate list views for Payment in and Out .
The point is , in these cases the logic may be the same for Purchase and expenses but the usage pattern,frequency and reporting needs are not same
How do you do this? Have disabled the mandatory filed of from the 'Purchase Invoice Item" table and there by it is allowing you to save the submit of invoice without any entry of item?
And i believe you might be putting the accounting ledger into the ‘charges and taxes’ section, right?
There should not be a work around for something that so many people intuit a different workflow from.
This really summarizes the silliness of not having a tool that books the expenses to A/P correctly. There is a balance here between being enterprise software and being software for a small businesses (that a business person who is likely not an accountant needs to operate).
Technically, there’s a credit to A/P (increase) and a credit to the Expense Account (increase). This is later reduced by paying the bill (a debit to A/P and a credit to the bank account). But I agree with the larger point you’re making: the user shouldn’t have to worry about getting this right in the journal entry, there should be a tool that does it.
So I made one:
From my personal experience doing bookkeeping I know that I’ll get into a flow and will sometimes start a document that correlates to the purchase of an Item, so I added the ‘Convert to Purchase Invoice’ bailout. It should also have the ‘Make’ menu that Purchase Invoice has, where it uses the document mapper class to create a Payment Entry or a Subscription. There’s a case there should be Debit Note on that list too, but I just thought of it at this very moment.
So the work that remains to be done @joshiparthin (and friends):
I am using the new_doc(“Journal Entry”) pattern in the background, which is not appropriate in the long term; it should be posting directly to the GL. I’m working through that now.
The ‘Make’ UI is there but none of the wiring.
For my customer’s purpose, they wanted Cost Center in the first column and a required field (which is a strong statement the importance of analysis and I applaud it), but I don’t think that’s the way most people will be using it.
I need to refactor to be compliant with the 10 line requirement for contributed code.
I need to write the tests, but there are so many ready examples of this use-case it should be a piece of cake.
In order for others to contribute, I need to pull this out of the application it is in and move it to an ERPNext branch. I’ll post the link for that before my end of day.
Oh! Another point about terminology, since I know this will be a point of discusson. I landed on “Indirect Expense” for a couple of reasons.
I’ve had a lot of good, passionate discussions with Alain (@Tropicalrambler) about terminology in our work on the Agriculture module and while we spend a lot of time trying to find the right terminology (and agriculture is full of jargon and none of it is categorically “right”, worse than accounting, but not dissimilar) you should just use the custom translation feature if you really hate it (or your customer really hates it). Arguments about a more perfect name for something are ultimately about one’s personal understanding of the meaning of a specific word, the word itself has no innate meaning.
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.