Mandalay CS 3.2Regulatory ReportingQueenslandHow do I create a QLD regulatory submission?

How do I create a QLD regulatory submission?

The following article provides a high level explanation of the process for generating a submission for the QLD state government levy submission. It covers the following stages:

  • Setting up of bulked up load data
  • Generating a submission
  • Responding to errors in a submission
  • Finalising a submission

Accessing the Application

The Regulatory Management application is access from a specific tile in the naus Platform. You must be granted the Regulatory Management user role for this tile to be visible when you access the naus platform.

Submission Process

The submission process requires a few steps to be performed before a successful detailed data file and report can be generated. Part of this process is iterative and requires repeating steps to get to a finalised submission, specifically around correcting any errors detected during the submission generation step. Users will require access to the Mandalay CS Administration application and the naus Regulatory Management application.

Generating a new submission will start the process of creating a submission. Once started the system will work through the following stages of creating a submission:

  • Extract the data from the CS database of the period being reported.
  • Validate all the extracted data against the requirements for the legislation
  • Validate all the bulked up transactions so ensure they are valid and have a matching bulked up contract.
  • Expand all the bulked up transactions based on the relevant bulked up load contract.
  • Generate a detailed data file.
  • Generate a summary report.

 

The following flow chart demonstrates the end to end process that should be followed to generate a valid submission for the QLD government  submission. This flow chart can be downloaded from this article using the link at the end of this article.

Completed and In Progress Submissions

The submission list will by default show the last 6 submissions generated and any new submissions that are due to be generated. Each submission listed will provide details of the submission including when and who last actioned it.

Its possible to search for a submission beyond the 6 that are initially shown, by typing part or all of the name of the period required. Once the search criteria select the Search button to see the submission relevant to your search criteria.

The system will not show any more that 6 submissions in the list. So if the results for the search are more than 6 then the result counter at the top will show 6 of X where X is the total number matching the criteria. If the submission required is not visible then more details will need to be entered to the search criteria.

 

 

Its possible to search for a submission beyond the 6 that are initially shown, by typing part or all of the name of the period required. Once the search criteria select the Search button to see the submission relevant to your search criteria.

The system will not show any more that 6 submissions in the list. So if the results for the search are more than 6 then the result counter at the top will show 6 of X where X is the total number matching the criteria. If the submission required is not visible then more details will need to be entered to the search criteria.

In Progress submissions will run on the naus servers so you do not need to keep the web browser open.

Every 5 minutes the status of the process will be updated including the progress bar. If errors are detected they will be presented to the right hand side of the screen.

Clicking on the Submissions menu item will take you back to the submissions list where the new submission will presented as an existing submission.

If necessary the process can be aborted. This may be helpful if you are seeing a lot of errors and would prefer to correct them before continuing. Once aborted the download option for the error log will be presented.

Bulked Up Loads

Bulked Up loads refers to loads that contain more that one waste stream and are generally restricted to the following scenarios:

  • Waste transfers from RRA to landfill where the RRA accepts C&I or C&D material and so loads include a combination of C&I, C&D and MSW Waste
  • Waste collections direct to Landfill that cover loads with a combination of  C&I, C&D and MSW waste.

Each of these loads will have a % split between the different waste streams and classes, which is not necessarily known at the time of the transaction. To apply this split to loads a process needs to occur that will adjust a transaction and split the load based on a certain % ratio. This split is defined in CS Administration as a bulked up load contract.

Facility operators should consult the Regulator regarding agreed methods for determining the percentage split between waste streams..

When a submission is generated the transactions that are marked as bulk up loads will be expanded based on the appropriate contract 

For more details on managing bulked up loads see the following article.

Ticketing Corrections

Any ticketing corrections for the reported month should be corrected in Ticket History prior to running the submission to ensure all data is accurate in Mandalay CS.

Submission Generation

Once the bulked up load contracts have been defined and any ticket corrections have been made a submission can be generated. This is done in the naus Regulatory Management application.

At the end of each reporting period the regulatory system will make a new submission available for generation. The user can then request the submission be generated in the back ground. The submission generation process will perform the following actions before a final submission file and summary report are available:

  • Validate waste classification data for each transaction against the effective state government legislation.
  • Verify all required data is available against a transaction to allow it to be reported to the government.
  • Check all bulked up load transactions for contracts that match the details in the transactions (see this article for more detailed on bulked up load management)
  • Expand all bulked up load transactions based on the specific bulked up load contracts.
  • Generate a detailed data file and summary return report.

Any errors or warnings reported during these process will be reported back and available for downloading in a log text file. (Note: the log file will not contain any more than 10,000 errors)

Only sites that have a valid Site Operator ID record in Mandalay CS will be used for generating a submission file.

For more information on using the naus Regulatory Management application to generate a submission please see this article.

Correcting Submission Generation Errors

Submission errors will usually come in 3 specific types:

  • Transaction validation errors
  • Bulked Up load contract errors
  • System errors
  • Warnings (warnings are indicated by the count included in an orange circle)

If a submission contains anything other than warnings it cannot be generated or finalised. So all errors will need to be corrected before a submission can be generated.

If a transaction has multiple errors then only the first one will be reported. This means that even if you correct the error being reported the transaction may appear again. To help reduce this occurance check any other items in the transaction being corrected to make sure they are valid.

Transaction Validation Errors

As the submission is generated the system will validate a transaction against the requirements for the DES file specification.  It will check each transaction and specifically look at the following elements:

  • Are the waste class, waste stream, material type, source use and destination use codes recorded against the items in the transaction valid against the relevant legislation?
  • Is the vehicle type set against the transaction and is it valid for the relevant legislation.
  • Where a gross and tare does not exist for a transaction (i.e. not weighed), does a vehicle type and GVM (capacity for skip trucks) exist for the transaction.

Bulked Up Load Contract Errors

If bulked up transactions exist the submission generation process will perform the following checks before it attempts to expand a bulked up load transaction.

  • Do the bulked up load transactions have the bulked up load classification against the waste stream and waste class.
  • Can a unique bulked up load contract be identified for a bulked up load transaction?

When identifying a bulked up load contract for a location the system looks at the client, source and destination locations when trying to locate a contract. If more than one or no contracts are found the system will raise an error.

System Errors

Where an error occurs that does not relate to validating the data the system will report the error and include it in the log file. If the reason for this error is unknown then a support ticket should be raise with the Mandalay support desk.

Warnings

During the generation process the system may identify data issues that it is able to correct automatically. The system will only correct the data when it is added to the data file. It will report these issues as warnings to allow the root cause of the issue to be identified.

An example of a warning is when the license plate contains non alpha numeric characters or spaces. In this case the system will strip out the invalid characters and just report the alpha numeric characters. The user can then take a look at the cause of the invalid license plate and correct either the operator entering plates incorrectly or the vehicle record in Mandalay CS administration.

Warnings may also be generated for data that presents a higher risk of being incorrect and should be reviewed to ensure the record is correct.



A list of all the error and warning codes can be found in this article.

Correcting Errors in Mandalay CS

The Submission tab in Mandalay CS Administration includes the ability to correct waste classifications against a specific transaction. It will then allow the user to bulk correct other transactions with a similar structure to the transaction that was replaced.

To perform this process will require the creation of a submission in Mandalay CS but it only needs to be created for the period being submitted and you do not need to press the generate button.


Please note, the inappropriate use of this tool may lead to unintended data changes and a support ticket should be raised with Mandalay if you are unsure how to use this tool to perform bulk corrections.  In line with best practice, Mandalay encourages customers to maintain accurate data by editing (replacing) transactions as a preferred option to correcting errors in order to maintain a complete audit log. 

For further instructions on correcting errors see this article

Re-Run Submission

Once all the errors have been corrected in Mandalay CS the submission in naus Regulatory Management can be Re-Run. This will clear all information regarding the previous run and will reload all transactional data, including any new transactions recorded for the reporting period.

Correcting errors and rerunning the submission should be continued until the submission generation process is reporting no errors (warnings will allow a submission to be finalised).

Generated Submission

Detailed Data File

Once a submission has successfully completed without errors a data file will be made available for downloading. This file represents the file required for submission to the QLD state government though their QWDS portal. The file is produced based on the version of the Detailed Data Specification that relates to the effective legislation for submission.

Summary Return Report

A submission will also generate a summary return report. The report can be viewed within the application once the submission has been created and is formatted to mimic the Monthly Summary Return page in the QWDS portal.

Submit to DES

Once the data file and the submission are available the QWDS portal can be accessed and the summary return lodged. The detailed data file should then be uploaded once the summary return has been accepted. This is important as its not possible to resubmit a detailed data file but it is possible to resubmit a summary return.

During the upload process of the file it will be validated by QWDS. If any issues are reported then the process will need to be corrected in Mandalay CS and the submission re-run as per this step.

If any errors are reported by the QWDS system please contact Mandalay and provide the details of the errors and the data related to the error so that the regulatory application can be improved.

Finalise Submission

After the detailed data file has been uploaded successfully and the monthly return submitted, the submission in the naus Regulatory Management application must be finalised.

It is important for managing changes between submission months that your submission is finalised once the detailed data file has been accepted. Failure to do this may result in changes not being reported correctly to DES.

A submission must be finalised before a new submission period can be generated.

Skipping a submission

If necessary its possible to skip a submission period. Skipping a period will allow the next submission period to be presented and if necessary the skipped submission can be rerun at a later date.

Previous Month Adjustments

During the submission process the system will look for any transactions that have been replaced or canceled in previous submission periods. If changes are detected, they will be reflected in the detailed data file (as per the Levy Detailed Data File Specification) for the current submission month and the affected months summary will be adjusted. The adjusted summaries will require refinalising before the next months submission can be generated.

If more than one month requires refinalising then they should be do this in oldest to latest order. 

In some cases you may need to resubmit your monthly summary to DES, if so then you will need to follow the DES guidelines on resubmitting a monthly summary.

Only changes made using ticket replacements are managed through the adjustment process. Bulk ticket edits for previous month submissions are not detected and will be ignored.