Hello @lubos
I was looking for a quick way to get the total number of transactions entered in a given period but couldn’t. I was wondering if we could have a statistics section in reports for statistics like:
Transaction count by transaction type
Transaction count transactions by user
0 value transaction count by transaction type
0 value transaction count by user
Unassigned special accounts
Unclassified accounts and control accounts
Number of inactive accounts, special accounts, groups, transaction types, users … etc.
Duplicate transaction numbers
Transactions without numbers
Alternatively, we can have reports for masters a tab view for all transactions showing:
It isn’t clear how or why you would use some of this information. Can you provide use cases? Also, some of it is already available:
This would essentially be the entire database, plus some of its history. What is the use case? What useful information would you get from such a report that you don’t already have from the General Ledger Transactions and Tax Transactions reports?
So you suggest a new tab in the program, but are not willing to explain your use case(s). And when it is pointed out where some information is already available, you either add to your requirements or withdraw the request. Then you throw in transactions in Suspense to justify having statistics on groups and other accounts. And apparently, you don’t want to address why existing reports that seem to give the information you ask for are not adequate.
You have been a forum member for most of a year, long enough to have noticed that the developer is often accommodating when new feature requests are thoughtfully justified. If you want your ideas to be considered and supported, you need to explain their benefits for users.
Why are you so tense? I know @lubos is a very busy man and I appreciate the work he does greatly. I don’t know what you understood from it all but look at the title: Just a suggestion. If you do not want suggestions then please say so.
Back to your comment, yes I withdrew some SUGGESTIONS because based on your initial comments I saw that they were unnecessary … So, what did I do wrong here?
Second, also yes, you were clearly playing on words when you say:
That is a clear evasion of my point, tell me how “special accounts” is a proper classification, any accounts that remain there are effectively unclassified. I am not going to discuss the definition of the words “Classified” or “Assigned.”
What I SUGGESTED was either giving us a statistics section in the reports OR giving us a tab we can use to make our own statistics to give red flags on:
Completeness of records (e.g. if there was a period without any invoices, receipts entered: say the staff is taking customer collections without issuing invoice and/or receipt. There is no other way to find this not even the bank reconciliation)
Integrity of data (i.e. proper unique numbering of transactions, this will certainly help when auditing, reconciling and just referencing transactions for retrieval)
Who to followup with (i.e. created by and modified by and when)
If you want better explanations, please ask valid questions.
The disadvantage of limiting Manager programming discussion on this forum is other users don’t learn what is possible and NG Software doesn’t get an insight into how their program is being used.
Unfortunately there is a trade off in application development design environments:- the more capable / flexibility the environment the harder it is for a user to choose which option to select / program. Lubos has intentionally reduced the localisation interfaces capabilities to increase the number of users who can program it.
I believe Lubos is designing the localisation interface for functionality shared between many users. What you have generated would be valuable if shared between accountants, but I’m not sure if that’s a focus for NG Software.
Agreed, but if Manager is not going to cater to individual reporting needs of users, why not allow them to get what they want themselves? I can’t wrap my head around that.
So why not have both? We can have two setting items:
Report transformations is a way to get country-specific functionality into Manager without hard-coding it.
What you require could be solved by custom reports or could be generic built-in features.
For example, duplicate transaction numbers shouldn’t be a report. That should be shown as an alert directly under the tab if there is a duplicate.
Transaction count by transaction type could be a custom report.
You are proposing quite a few bullet points, but there is a story behind each bullet point, isn’t there?
So each bullet point should be separate idea if justified by use-case and we can find the best way to implement this. And without resorting to custom coding.
I don’t like custom reports because it exposes the entire setup to the user that just needs to change the dates. An alternative is to make cloning custom reports yet another chore for the administrator.
That sounds right.
But for custom reports to suit my purposes the setup should be separate from report instances and we need to have more summary column options like: Count, Average.
For your application of accountant review of clients business files, externally interrogating Manager via the “API” may work better for you. I don’t like suggesting it because:
It results in zero reuse for other users so is worse for the Manager community overall
Manger doesn’t really have an application programming interface, it has program hooks to enable low level access. In contrast a true Application Programming Interface is an abstract defined interface which is a relatively constant specification, maintained independent of either source or destination program modifications. The most significant practical difference is if you wrote code to use Managers program hooks, then you would need to expect ongoing regular maintenance to achieve compatibility with Manager program update cycle.
I agree that it’s not an “interface” yet, it’s more like an FTP or SOAP (whichever is correct) but I still like the idea to automate the entire thing.
I don’t think it’s practical at this point though because in order for me to process the entire thing externally, I need to retrieve thousands of objects every time, and then rebuild the relationships from scratch. Even incremental updates aren’t possible because neither the object or the index store create and update timestamps, which is kind of a bummer.
I currently use the API for master records only and it works great. The recent changes to built in accounts didn’t affect me so much because they are not really used in transactions, so I don’t mind a couple of dead queries there.
But maybe if we can query the entire output of a system generated view or report, then we are talking business.
