To my understanding, the “Payment Entry” is more or less a simplified version of a Journal Entry. (According to the documentation: “Using Journal Entry requires an understanding of which Account will get Debited or Credited. In the Payment Entry, it is managed in the backend, hence simpler for the User.”)
It seems the Payment Entry is, currently, only designed for paying invoices/receiving payments from suppliers/customers. Currently, the Payment Entry (“Payment type: Pay”) can only be used to book against payable accounts (such as a creditor account). Is there a reason, one cannot directly book against an expense account?
Use cases would be: e.g. paying a bill directly into the respective expense account.
What are possible cons to extend the Payment Entry to allow booking against expense accounts?
(I know that such a booking can be done with the Journal Entry, but as stated above, Payment Entries are a bit easier for non-accountants to use)
Stop me if you’ve heard/seen this before but wouldn’t using a Sales Invoice for a Generic Item called Expense (which is not a stock item) be the optimum option for this? You could use the Include Payment option and finish the whole thing in a single entry. At the item level (You can pull it into the Item Table grid) you can pick the Expense account you want this charge to hit.
But if you absolutely are dead against using the Sales Invoice option (Quickbooks users usually are), yes, your Payment Entry option seems to be a good approach, but that requires customization. And if you had to do customization, you could do a new DocType for making expenses and the DocType could include the payment and also make a charge. But that would hit the General Ledger and my guess is that using a new DocType to hit the General Ledger will mean a lot of coding in a lot of places. So, you are better off using the Journal Entry option or the Sales Invoice Option.
Thanks for the advice. That’s an interesting solution I haven’t thought about, yet. The form for Purchase/Sales Invoice is more complicated though than submitting a Payment Entry.
It seems it wouldn’t be a big change to the Payment Entry doctype to make my suggestion to work. I was thinking about submitting a Github issue because I think the current setup is an unnatural restriction to the Payment Entry doctype. However, I wasn’t sure whether I understood the Payment Entry, correctly. IMHO Payment Entry should allow to record expenses/incomes.
Thanks for your suggestion using the Purchase Invoice though. I will discuss with my team whether this is an option. (Thanks also for telling me about the “Include Payment” option. I did not see that before. That could be handy.)
Thanks @Fred1 . Unfortunately, this solution hasn’t been published to the Frappe Cloud Market Place. So, this solution (although I like it) is not available for Frappe Cloud user. I asked the creator of the app whether he could add it to the market place.
Payment Entry is really designed to handle settlement for payable and receivable accounts in an accrual system. It writes to the ledger, so in principle you could have it do anything you wanted, but I’m not sure that doing expenses this way is really in the spirit of what the doctype is there for. It’s possible, but it feels to me like a bit of a hack.
I agree very much, though, that the invoice doctypes can be absolutely overwhelming for simple purchases. The challenge is that, for many companies, purchasing and selling can be at times very complicated and at other times very simple. An invoice could involve dozens of approval steps and elaborate terms of payment, or it could be the box of donuts a manager bought for a meeting. Those two possibilities are in some ways the exact same thing and in other ways completely different.
One solution to this problem would be to create a new doctype, like how it’s done in the lovely app @adam26d crated. Another approach would be to create a streamlined interface that would let users enter just basic information and then generate a full sales/purchase invoice on the backend. The Journal Entry doctype has something like this. When you create a new journal entry, there’s a button in the top right called “Quick Entry”, and if you click on that a modal pops up with just a few different fields. It’s a nice tool, and it makes entering simple transactions extremely quick. Something similar could be created relatively easily for sales and purchase invoices.
Understood. Thanks for the detailed explanation. That helps. (Would be nice if the Expense Doctype was available in Frappe Cloud or added to the core). This is not a super urgent thing as we can book such things with a Journal Entry or Purchase Invoice as suggested above, but a quicker/simpler way to input data is appreciated.
I experimented a bit with the “Quick Entry” options before. They are quite neat and help in terms of UX. Might make sense if ERPnext had by default a few more Quick Entry forms for other doctypes such as for the invoices. I guess the new way how things are rendered with Tabs in V14 also will help (I only tested the PR at the time of development but haven’t worked with them operationally).
Many years back we copied the SAP method of directly making a GL entry for daily expenses plus tax if paid. No need of making an invoice for every payment.
The code is inside our app. Maybe you can pull the code to make it into an independent app out of the code.