Ability To Pull Accounts& transactions in report transformations

I Would Like to request @lubos to add the Ability To pull Income, Exoenses And all balance Sheet Accounts in report Transformation. This Gives the Ability to create Income tax returns And Some GST returns by using report Transformation.
And
I also Like To Suggest That an ability to pull Specific transactions in report Transformations.
Ex for This case:-
Indian GSTR-1 , in GSTR 1 All Invoices needs to be listed in Chronological order in sepcified Format to GST Authority. so that needs to pull Each invoice to Report Transformation to Create GSTR-1.
This is just an Ex for My request . there may be many other reports created with Report transformation if Such Abilities are Provided .

Under the current setup Report Transformations work exclusively with Tax Codes and hence this request is kind of irrelevant.

Your request could be better answered by improvements to custom reports. Just as a summary of popular requests on custom reports:

  • Scope should expand to include other transactions like sales invoice, purchase invoices, payslips, etc.
  • Scope should expand to include master records like customers.
  • Methods of summary should include count.
  • And, Or logic for filters.
  • Custom report definitions and instances should be separated much like report transformations. Definition can be done by admins in the Settings but users can create instances in Reports tab.

Also, the name Report Transformations is kind of misleading and imo it should be called something more descriptive of what it actually does.

1 Like

Yes maybe, But Currently report Transformations has More Independence than Custom Reports.
So, Both Custom Reports And report Transformations Should Be improved.
In a Way Like-
For Custom Reports:-

and
for Report transformations:-

and Many Other ways …

For country specific localisation generated and maintained by the community, to be viable; people with reasonable accounting knowledge but minimal programming skills need to feel confident that generating them is readily achievable for their skill set.

Program access to Manager has been available for several years but participation in localisations has been low.

Participation has dramatically increased recently which has been achieved by

  • simplifying the localisation interface by reducing it’s capabilities
  • encouraging localisation discussion on this forum

So there are good reasons to have a localisation programming environment with very specific an restricted capabilities.
Imo all accountant have at least basic spreadsheet skills so having basic spreadsheet functionality would not be a barrier to entry. So some where between the current and prior implementation would maintain broad participation but enable greater functionality however that is a judgment call.

You forget one important element as reasons why., i.e. the legal requirement as in Saudi Arabia (by far most discussions) and in some countries the online submission gateways of tax reports and invoices.

Despite an increase in some instances many of the countries listed in localisations have no real entries nor participation. Also some like USA is impossible because of the numerous variations at federal and state levels.

I am not sure if this could not have been better tackled with a combination of people with programming and with accounting skills. In reality @Lubos now did all the programming, for localisations more flexibility and ability to do some basic arithmetic and logic (if then else) similar to needs for custom reports would maybe have been more powerful and participatory if getting the same push and support from @lubos.

if all The Advanced Functionalities Which Will be Added Into Custom Reports as well a Report Transformations Should be added as a checkbox.
like-

  • Checkbox Named `Weather Master Data is included or not `
  • Checkbox named `weather Invoices be included or not `
  • Every Addition Would be as a checkbox.

This Way People Which does not require Advanced Functions are able to use Simple form of Custom Reports And Report Transformations.
and
Users Who Require Advanced Functionalities is Able to use them.

@Omnipotent.inc, you need to understand report transformations are just that: transformations of data already present in the report.

I’m not convinced that approach leads to a simple general solution. It requires very specific code for each user request / use case. As a result as it evolves the interface would become progressively less intuitive, requiring more and more knowledge of prior work arounds. And to be honest that is the problem with custom reports, finding the data you want requires understanding the underlying data structure Manager has evolved to use.

In my opinion a cleaner more general solution would be spreadsheet style interface where clicking on a spreadsheet cell shows a “formula bar” panel with fields to

  • Name the cell
  • Define the cell contents (database lookup information similar to the immediately prior localisation “Figures” interface) or
  • Arithmetic function of other cells (by name) in the report transformation
  • Format the displayed value (rounding options)

Described in more detail here Localisation Rounding support , however I can’t see that happening now.

Similar considerations apply to custom reports. Most people can’t use the current interface, so adding more independent options will just decrease the number of users actively using them and increase the programming cost of maintaining the functionality.

1 Like