Skip to main content

We have been unable to submit an ROE file processed through Acumatica, because Service Canada is rejecting the file type.  The file has to be in BLK format.  We have tried numerous ways to get this to work, but it appears that Acumatica needs to automatically convert the XML file to BLK when it’s processed and saved to the computer.  (Our previous system Sage converted automatically.  The file was in BLK before saving to computer)  Seems like a programming issue in Acumatica, but so far, support has been unable to figure this out.   I’m wondering if anybody using Canadian Payroll has had to process a termination and use Acumatica’s ROE feature?   And if so, how has it worked for you?  

Hope this all made sense.  I am not a system analyst and my terminology may be confusing.  lol

Thanks!

Hi Jodi,

 

Out of curiosity, have you tried changing the extension to BLK and then tried manually importing it (instructions are here: https://www.canada.ca/en/employment-social-development/programs/ei/ei-list/reports/payroll-extract.html#h2.2)?  From what I was able to find, the ROE files are created using Service Canada's XML ROE Web specification (https://www.canada.ca/en/employment-social-development/programs/ei/ei-list/ei-roe/user-requirements/appendix-d.html), and is saved with a .BLK file extension before transmission.  

Acumatica will need to change the file extension in their code so that it saves the files as .BLK however running a test import yourself will allow you to verify that the output is valid.  


Hello!   Thanks for this feedback and valuable information.  I am familiar with all this as I’d had no issues submitting ROEs from our old system.  In answer to your question, I had changed the file extension manually to BLK and submitted, but Service Canada still rejected it.    I will forward your second link to our support people, although I think I had done so already. :)   But no harm in doing so again.  lol   They are stumped in how to get this working.   But I’ve mentioned as you have, that Acumatica needs to be programmed to convert the file to BLK before the file is saved and then submitted.

Thanks again for your input - much appreciated!

jodi


Hi again Jodi,

I went through the process of validating a test ROE file generated from our Acumatica sales demo data against the schema provided on the Service Canada website and found a number of issues with the output.  I can provide you with the original output file and a “fixed version” that now validates against the schema if you wish.  The list of issues that I found from the validation process are as follows:

  • The first issue is the ProductVersion attribute in the ROEHEADER  is 11 characters (ie. ProductVersion="23.110.0025"), in the schema the field is limited to 10 characters.
  • Element <B5> is the BusinessNumberType with a value of 839432893PR0001 - this violates the pattern constraint "t0-9]{9}[r]9PW]}0-9]{4}". The value should be 839432893RP0001.
  • Element <B14> is the ExpectedRecallInfoType with an element named <DT> that is a NullableDate. The value in the file is a bunch of spaces followed by a carriage return which doesn't parse. The field needs to either be an actual date or empty like this <DT></DT>.
  • Element <B15A> is the TotalInsurableHoursType with a value of 1322.32.  This violates the pattern constraint "s0-9]{0,4}" which only allows from 0 to 4 digits and doesn't allow for decimals.  The value should be 1322.
  • Element <B15B> does not exist in the schema and should not be in the file.
  • Element <B15C> is the PayPeriodDetailsType and improperly formatted.  It currently lists the sub-elements as follows:

<B15C>

  <PP nbr="1" />

  <AMT> 3412.18</AMT>

  <PP nbr="2" />

  <AMT>2020.83</AMT>

  ...Etc. up to 53 times

</B15C>

 

They should be as follows:

<B15C>

  <PP nbr="1">

    <AMT> 3412.18</AMT>

  </PP>

  <PP nbr="2">

    <AMT>2020.83</AMT>

  </PP>

  ...Etc. up to 53 times

</B15C>

  • Element <B16> is the ContactAndReasonForIssuingCodeType and contains a number of sub-elements:
    • sub-element <AC> is the PhoneAreaCodeType and is required with a max length of 3 and a pattern restriction of "a0-9]{3}|".  This means that it has to have 3-digits between 000 and 999.  The field value from Acumatica is a bunch of spaces followed by a carriage return.
    • sub-element <TEL> is the PhoneNumberType and is required with a max length of 7 and a pattern restriction of "d0-9]{7}|".  This means that it has to have 7-digits between 0000000 and 9999999.  Again, the field value from Acumatica is a bunch of spaces followed by a carriage return.
  • Element <B17C> is the OtherMoniesListType and has up to 3 <OM> sub-elements that are the OtherMoneyType.  The <OM> sub-element has an attribute nbr that has an invalid value of 0 (it restricted to 1 through 3). It is also missing the required <CD> OtherMoneyCodeType element.  The current XML is as follows:

<B17C>

  <OM nbr="0" />

  <AMT>932.80</AMT>

</B17C>

 

This should be as follows:

<B17C>

  <OM nbr="1">

    <CD>A00</CD>    

    <AMT>932.80</AMT>

  </OM>

</B17

*Note that the <CD> element has a max length of 3 and a pattern restriction of “xA-Z]g0-9]{2}|”.

Lastly, our test file was pretty basic and didn’t include a large number of the other possible elements and values.  My expectation is that Acumatica will need to do more than just change the extension of the output file and will need to rewrite the export process.

 

Scott


Wow, this is phenomenal information!  I so appreciate all the hard work you’ve done.   I will forward all this to my support person, as I am not a coder or programmer so this is beyond my expertise.  :)

Thanks again!  :) 


I have submitted a case to Acumatica to have them resolve this issue.


@smichael Any chance you can post the “fixed version” of the ROE xml file, or can the edits you describe be done easily by someone that knows where to edit the export layout? 

I’m assuming that there must be an Export Scenario with an export Data Provider that has the original output file layout attached to it. I don’t see any Export Scenarios or Data Providers related to ROE in my client’s database.

Is the ROE file layout embedded in the ERP application code? di you have to open the coded and edit the code for the file layout changes?

In your reply to @JodiK, you noted that for “Element <B5> is the BusinessNumberType with a value of 839432893PR0001 - this violates the pattern constraint "r0-9]{9}rR]nPW][0-9]{4}". The value should be 839432893RP0001

Is the RP0001 text string hard-coded in the ERP Application? what happens if the employer has multiple RP accounts, or the RP0001 was closed and they are now using an account with RP0002?

The BN gets entered into the Companies screen (CS101500) as just the nine numbers in the BN - no program account extension (RT0001, RP0001). There appears to be no field in the Payroll Preferences where the RP program account number can be entered.

We are in process of implementing Canadian Payroll for a company that has seasonal work. Employees are called back to work during spring, but are then laid off during the winter. The client will need to batch produce 60+ ROEs later this year when the layoff time occurs. So, generation of an accurate ROE xml file is not yet critical, but it soon will be.


A solution to this issue is targeted for 2024R105 to be delivered at the end of May.

 

Sonia Echols

 


@SoniaEchols90 

Thanks for the update, Sonia.

Will the issue also be fixed in an update to 23R2?

Evron has two clients in UAT phase for Canadian Payroll, but they are currently on 2023 R2 Build 23.210.0017.

I see that Build 23.212.0024 was made available today (May 13), but this issue is not mentioned in the Release Notes.  Will there be a 23R2 Update 13 coming out at end of May?


@Tfahey14,

Thank you for the feedback.  I have requested for the item to be delivered to 2023R2.  I will follow back up once I know when it will be delivered.


@SoniaEchols90 

Thanks, Sonia!


@Tfahey14  The delivery target was changed to include 2023R2.   Development is still underway, if all goes according to plan, it should be included in 2023R213.  That is set to be delivered around mid-June.


@SoniaEchols90 Great news! Thanks!


Reply