Report Transformations - No-code development platform

[Patch]

@Patch

a way of incorporating XML into the current Report transformation development platform would be to add an export drop down menu along side the columns menu with options

• None
• CSV
• XML

Selecting other than None would enable a column to specify the export files contents.

@lubos

XML or JSON would suit better. I will add support for all three formats or any format that is useful. What I would like to avoid is to add ability to create custom structures. That would probably require coding.

@lubos

I’m looking at all country-specific requirements at once and where figures need to be lodged with government departments digitally, I need to approach this differently. I’m working on something new.

@Patch

Report writer interface

• To support report writer defined calculation, interim values must be named in some way so they can be referenced.
• A spreadsheet style interface is widely recognised and probably the simplest way of defining a report. By which I mean have a localisation development environment which has a layout section (where the user can select a cell in a grid) and a formula section where the user defines what goes in each cell.
• When a cell in the layout section is selected, the formula section could show the corresponding formula.
• The formula panel could be virtually identical to the prior “Figures” settings except the most specific parameter near the bottom of the panel could have the option to add alternative values (data base search “or”).

Thinking about this further a possible Report writer interface is:

• A menu to select the type of file to be exported
• Cells in that column enable selection of a data element or valid data delimiter for the chosen file type.
• Entering a data element would consist of entering the data element name (column heading in a cvs file, element name in structured data like xml) and which report column the data value is taken from.

This would simplify generation of electronic communication data. I think it would cover all static data structures, which I suspect is by far the majority.

The only exception I’m aware of is the “Allowance - Other” in the Australian single touch payroll which uses a dynamic data structure consisting of data labels

• Other allowance [ integer 1 … 20 ] description
• Other allowance [ integer 1 … 20 ] value

Where the description is a pay type specific to a group of employees such as “Jobkeeper-Topup”, so in Manager terminology it is a payslip item name. I suspect this is rare in data communication standards so could be ignored. If not supporting it could be done by allowing the data element name to be dynamic (reference a cell not static text) and allow more general control structures (not just “Supplier” or “Employees”). Hopefully this isn’t required as it risks complicating the interface.

Report writer control structures

The current No code report writer supports looping for

• Suppler
• Employee

If a spread sheet style layout was used these could continue to be implemented using the current interface, perhaps enhanced by showing the loop boundaries in a grey area with labelling.

An alternative is to enter the control structure in a similar manner to entering a data value in column A. Doing so would result in the same changes as described above. While this approach would result in a more flexible report writer architecture, it may involve too much programming to be viable in the near term.