Australian Goods and Service Tax (GST) Business Activity Statement (BAS) XML File fails to import into the Electronic Commerce Interface (ECI)

  • Article

David Meego - Click for blog homepageToday I am going to discuss a support case where we found an issue with the XML file created when exporting the Business Activity Statement (BAS) tax return report for Australian Goods and Services Tax (GST).

So, if you don't have to work with Australian companies and the rest of this article does not make sense, please don't worry.

Before I start, I should explain that the issue discussed below has been fixed for GP 2010 (v11.0) Service Pack 3 and later as Problem Report 63031. If you are still on version 10.0 read on, if you are on GP 2010, install SP3 or later (or read on).

Get ready for lots of TLAs (Three Letter Acronyms).

 

Background 

Tax returns for Australian Goods & Service Tax (GST) are called Business Activity Statements (BAS) and there are a number of different forms based on what components of the tax legislation the business needs to report on. The Australian Taxation Office (ATO) provides software called the Electronic Commerce Interface (ECI) which allows the BAS data to be sent electronically to the ATO. The ECI also allows you to export and import the data using XML files.

Microsoft Dynamics GP has an additional BAS Report module for Australian installations. This BAS Report module will gather the data for the required date period in the form needed by the ATO from the source transactions in Microsoft Dynamics GP. Once the information has been collected, it can be either:

  • Manually transferred on the hand written paper form. While the BAS Report module can print a form that looks very like the real paper form, only the real paper form from the ATO can be lodged.
     
  • Manually transferred (cut and paste) directly into ECI software and lodged electronically.
     
  • Automatically transferred via XML files to the ECI software and lodged electronically.

It is this last method that we are interested in.

The way that the XML file method works is as follows:

  1. In Microsoft Dynamics GP, process the BAS data for the desired date period.
  2. Once complete, Edit the Business Activity Statement to see and adjust the data as needed.
  3. From the ECI software, locate the form provided by the ATO which needs completion and export it to an XML file.
  4. Back in GP, import the XML file to populate the BAS header information.
  5. Then export from the BAS a new XML file which now contains the additional transaction data.
  6. From the ECI software, import the updated XML file.
  7. From the ECI software, send the document to the ATO via the internet.
  8. Back in GP, mark the BAS as lodged and close the appropriate Tax Periods.

Note: There is a method of automating the export/import processes to combine steps 3 & 4 into a single step and steps 5 & 6 into a single step.

 

The Problem 

The issue we are seeing occurs at step 6 above. When you attempt to import the XML file into the ECI software it generates an error similar to the one below:

Error - BT - E104
An unexpected error occurred while opening a form.
Further details: unable to access form resource archive for NAT4235-0.2001.V2

Notice that it has a Document Type Description (DTD) of NAT4235-0.2001.V2. All of the different BAS forms have a number similar to this. This number is for a BAS-G type form. However, if we compare the XML exported from the ECI software (step 3) and compare it to the XML exported form the BAS software (step 5) we can see a difference in the headers:

Original ECI Software exported XML

<?xml version="1.0" ?> <!DOCTYPE NAT4235-9.2001.V5>
<NAT4235-9.2001.V5>

 

Updated BAS Software exported XML

<?xml version="1.0" ?>
<!DOCTYPE NAT4235-9.2001.V2>

<NAT4235-9.2001.V2>

 

There is a difference in the DTD with the version number.  The "V5" in the original XML file has been changed to "V2" in the updated XML file. "V2" is incorrect and so when you attempt to import the XML back into the ECI Software, it generates the error.

 

The Cause

OK, so the version has been updated and the BAS code was written using the old version. However, this was something that we expected and the BAS code had special handling exactly for this situation. There is a BAS_Report_Forms_SETP (BAS40200) table whose only job is to store the latest updated DTD version numbers for the different BAS forms. If you import a form with a higher number than the one the BAS code was expecting, it will write it into the table and then use that DTD when exporting.

So what went wrong, why did the "future proofing" code not work?

Well, I have worked it out, it took a while, but the cause is very subtle. Firstly, you have to understand that the BAS code that is reading the XML file is not actually an XML processor. To use the XML libraries requires Dexterity to use COM (Component Object Model) calls, but the BAS code was written before Dexterity supported COM. So the XML file is just read as a Text file and the BAS code interprets the XML tags accordingly.

This is import because the code that handled the "future proofing" of the Document Type Descriptions (DTDs) is looking for the "<!DOCTYPE" tag to read the DTD, but it is looking for it at the beginning of a line! Look closely at the XML excerpts above and you will notice that the "<!DOCTYPE" tag is not at the beginning of the line.

This is why the DTD version check was being skipped and why the updated version was not getting written to the BAS_Report_Forms_SETP (BAS40200) table.

 

The Solution

In GP 2010 Service Pack 3 or later, the code has been fixed in two ways. The default Document Type Descriptions (DTDs) have been updated to the latest versions AND the "future proofing" code that updates the BAS_Report_Forms_SETP (BAS40200) table has been adjusted.

However, if you can't install GP 2010 SP 3 or later, you can manually fix the issue by populating the BAS_Report_Forms_SETP (BAS40200) table with the updated DTDs.

The SQL script below can be executed against each Australian Company database to update the contents of the table.

  

Transact SQL Script

delete from BAS40200
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
values (1, 'NAT4189-9.2001.V5') -- BAS_FORM_A
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
values (3, 'NAT4195-9.2001.V5') -- BAS_FORM_C
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
values (4, 'NAT4191-9.2001.V5') -- BAS_FORM_D
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
values (6, 'NAT4190-9.2001.V5') -- BAS_FORM_F
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
values (7, 'NAT4235-9.2001.V5') -- BAS_FORM_G
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
values (8, 'NAT4236-4.2001.V5') -- BAS_FORM_H
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
values (16, 'NAT4646-3.2005.V2') -- BAS_FORM_P
select * from BAS40200

/* Copyright © Microsoft Corporation. All Rights Reserved.
This code released under the terms of the
Microsoft Public License (MS-PL, https://opensource.org/licenses/ms-pl.html.)
*/

 

I hope you find this interesting and not too confusing and more importantly... useful. 

David