Try ERPNext Buy Support Partners Foundation

What happened to the good old reports?

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.

1 Like

Can you share specific screenshots? No reports were “removed” in version 11.

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?

Do you still need the screenshots?

1 Like


A view from my Trial Balance run. See the Closing (Dr) column

2 Likes

Expand All and Collapse All buttons and functionality under the Trial Balance report has vanished…

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.

Hi, the same for as.

We’ve been reporting a series of severe issues in multi-currency, and this one we don’t see as minor.

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 https://github.com/frappe/erpnext/issues

For users that lack skills or resources, to expedite their problem resolution, they can engage the help they require
https://erpnext.org/erpnext-jobs
https://erpnext.org/service-providers

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?

Anyone willing to discuss this over a Skype meeting where we can showcase our systems?
The problems are obvious and no need for gibberish.

Yes it’s simply gibberish unless you take action :wink:

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.

1 Like

The problem has been reported 7months ago on GitHub,
https://github.com/frappe/erpnext/issues/15398. No action has been taken except to mark it as bug.

-Amit

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.

1 Like

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.

1 Like

Upvoting definitely helps, if someone wants to go deeper:

  1. Fix it
  2. 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.

2 Likes

it’s an honest and fair answer.

And for quality sake why not include a test too with your fix - the report tests are basic and need your 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.

2 Likes

ClarkeJ, totally agree. I’d like to propose a complete re-design of the testing framework, as it is not really usable from a testing perspective as mentioned https://github.com/frappe/frappe/issues/7126 and https://github.com/frappe/frappe/issues/7370

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.

3 Likes

Ola y muchas gracias @froldan!

Your timely list of report related bugs - plagiarized here from the Telegram dev channel - makes a solid case for additional tests IMHO.

For QA (quality assurance), up to now ERPNext has relied on just two report tests!?

General Ledger
https://github.com/frappe/erpnext/issues/17707

Multicurrency issues and account
https://github.com/frappe/erpnext/issues/16879
https://github.com/frappe/erpnext/issues/16697
https://github.com/frappe/erpnext/issues/15174
https://github.com/frappe/erpnext/issues/15398
https://github.com/frappe/erpnext/issues/17553
https://github.com/frappe/erpnext/issues/17248
https://github.com/frappe/erpnext/issues/17417

Reports
https://github.com/frappe/erpnext/issues/17282
https://github.com/frappe/erpnext/issues/17584
https://github.com/frappe/erpnext/issues/17707
https://github.com/frappe/erpnext/pull/17421

Report builder
https://github.com/frappe/erpnext/issues/17335

1 Like