@bluesky@dannyfoo I think the key here is use case. The fact is different organisations might decide to use different methods to settle expenses. Some would prefer payment entry, others would prefer journal entry. In my opinion, no solution is a waste as someone somewhere would like and want to use it.
I modified the cash advance and expense claim doctypes to manage both Employee and general expenses as my use case demanded that an Employee be responsible for all expenses not paid directly to recognised suppliers/vendors using invoicing (cash and open market expenses like flight tickets, prepaid bills payment, e.t.c). So while some might argue this is not right, I have justification for using it and it helps my financial reporting so it works for me. It may not work for you but it works for me and that’s the beauty of ERPNext… you can bend it to your will if you need to.
So kudos to @bluesky for not only coming up with a solution to fit his use case, he shared it with the community so whoever shares his use case can benefit.
In our app POS Bahrain we have made a simple payment entry method wherein user can just mention the amount and ledger. No need to make purchase invoice or item. Tax also can be added so it shows up in the custom built tax report for our country. The method was copied from SAP. It was during our ERPNext installation work where KPMG was the software consultant that KPMG showed us this feature of SAP. The code is below. It’s part of an app so someone can extract the code into another app.
Actually, this is not unnecessary. It is a must-have feature!
Not all the expenses are paid right away. However, they should be “accrued” at the time of the obligation according to all accepted accounting conventions. And recording it as a “purchase invoice” or a “journal entry” is not a good practice.
There are many weak points in simple things in the Accounting module of ERPNext that hinder its power as a fully-fledged ERP such as the incorrect format of profit and loss account, Incorrect gross profit reports etc. Which I will hope improve in future versions.
I don’t think it is impractical. I think the opposite. Use of purchase invoice to record general invoices is the last thing you want in an organized environment.
Yes. It is different. Not all the expenses in a business are employee-related. There are general expenses like rent, electricity etc. These need to be accounted for separately and most importantly accrued at the period ends.
On Expense Claim
-Add a link to “Purchase Taxes and Charges Template” renamed to “Expense Taxes and Charges Template” where it will prefill the “Expense Taxes and Charges” table base on the template.
Add a client script to apply calculations. Sanction amount should be less to the taxes and charges as the employee will not compute for it and so is the Taxes and Charges.
I see, I think it’s pulling from the default company… I can do some private support and add a company field so that we can solve this for you… for a small price of two coffee’s
For now try using Session Defaults to change your company like so:
i have checked your expense entry and these are my observations.
The expense entry is not posting into the General ledger because you specified it should only post to GL only and when the doc.status === 'Approved" in your code. The issue with this is that if any organization like mine has multiple approval level. for example imagine a scenerio of 3 approvals with different approval level A, B and C
A can approve when if the total amount is <= 200,000.00
B can approve if the amount >200,000 but less than 1,000,000.000001
C can approve from 1,000,0000 and above.
If the organization wants to capture the approval above and also because you have to differentiate between the approvals. lets say you have;
for A, doc status will read “Approved by A”
for B, doc status will read “Approved by B”
and for C, the doc status will read “Approved by C”
Neither of these 3 approvals even though they are set to 1 in the doc status, will never be posted to the General ledger which was the problem i faced.
It would rather be best if you change it to submit or define it as on_submit.