Dears, the General Ledger report was based on both Ledger currency and Account currency. That is gone which affect nearly all Accounting Views.
The way Trial Balance was reported is also affected. The accounts show meaningless entries like - values in Debit or Credit fields.
Being the only user in Turkey (I think) since April 2017 I am having trouble getting the same speed in synching with my accountant and I think it will not be possible unless I get the old views.
not saying the reports were removed. Changed but not to the better and the results involving foreign currency are inaccurate:
Trial Balance
General Ledger
Before, I was able to see the debit and credit and balance in both G/L currency and account currency, now it is in single and is inaccurate. I guess the values are not being read from the specific document’s accounting entries but calculated based on an exchange rate where I don’t know where.
A debit value is shown as -something. Why isn’t it simply a credit value?
Problems still continue with multiple currency reporting. The transaction ledger is correct when retrieved from the transaction however the general ledger shows only the correct values in company currency. When general ledger is queried in transaction currency, the results are wrong. When retrieved using trial balance, the correct values in company currency is show.
All updates to accounting module should be carefully reviewed. These transactions may lead companies to serious errors and fines as a results.
Surely for serious at risk user companies, options or initiatives exist within their reach and means @Tufan_Kaynak2, for their own sake and to benefit the whole community too -
One reasonable recourse is to collaborate via this forum on a collective action plan to contribute their support. The idea is to connect with others who share the same problem!
Clearly define and articulate individual multi-currency problem test cases in terms of actual and expected results, and submit these for all to review and respond to here Issues · frappe/erpnext · GitHub
Certainly the code is best served by a plethora of automated tests, necessary and sufficient to gain and maintain quality control and insight to detect and fix code problems. But that will only result from committed users who recognize and support this requirement.
Your concerns are valid and appreciated but maybe rethink how to resolve your problem?
Quite gibberish for an ERP implementor worked for Oracle and SAP internationally. Trolling is not a good way to get there.
The situation is already presented to little attention.
These “whinings” are signs that there is something wrong with the coding and testing quality. Moreover, if the users are complaining that things are going worse with an update, it is worthwhile to listen. When a feature is removed and users need it back, it is generally not a good sign about the direction that the development is heading.
I suggest a conference call for the interested parties. Surely the problems will be understood better.
Yes exactly that, do recognize that ERPNext requires but lacks automated testing so chat about that if you are serious…
edit: Just to correct and clarify here - ERPNext promotes and encourages a test driven regime, nonetheless coverage is haphazard and thin with many gaps so that quality suffers.
The idea is that as the production side code evolves, the test side code should grow to keep pace and detect breaking changes, to avoid surprises as your case illustrates.
one possible action was to upvote this issue and likewise raising attention. The official way to upvote an issue in the ERPNext context is to give it a thumbs up (+1) in the emoji field on the upper right of the original issue’s description. I just did that.
Upvoting definitely helps, if someone wants to go deeper:
Fix it
Pay someone to fix it.
Both options exist.
Regarding maintaining old features, no product is absolute and cannot satisfy everyone. Features will be removed and added for various reasons (and not based on bad faith).
On behalf of Frappe, we are committed to fix issues reported by our paid users. The benefit of which is to everyone in the community. Unfortunately we cannot fix every known bug based on the size of our team and the activities we support.
Another option or next step - this adheres to test driven development practice mantra - is to reproduce a pesky bug in code as a test case: That neatly illustrates and defines the problem, to target the required fix to ‘production side’ code.
Quality takes discipline and commitment. One sure path to grow and sustain that is to support test infected code. The benefit and need for unit and functional tests is a reasonable and effective goal.
I’d like to propose moving to pytest as well, as it has so many extra features, is backwards compatible with unittest, and separating it out into a separate folder structure, so that the tests and the src code is not intermingled.
That way it can be built up side by side with the current testing, and not actually affect it. Moving to a XP/TDD ethos will really increase the quality of the code, as you mentioned, and a worthy task I think for the future of erpnext/frappe to really increase its uptake. I’m currently stuck with an ERP from a close sourced vendor which has exactly the same problems, because testing was not a first class citizen.