Comments from Tom Verryn – PAL Solutions – Feedback on BRS for PIT2024 Modernisation Project

Tom Verryn support the comments submitted by Deon.

Tom Verryn’s comments are in addition to Deon’s comments.

Removal of source code identifiers
Tom Verryn want to comment on the removal of source codes from the record layout in several of the record types.
Tom Verryn understand that the administration for the allocation of new source codes is a painful process and involves extra work and resources. However, the benefits of a system with the volume of data that this system has makes it critical to have a source code driven file layout.
The current tax certificate file layout was designed in 1998 and has stood the test of time with major data item additions and deletions during the last 25 years.
With the complexity of different record types in the file the debugging of systems is going to be a nightmare.
Where a simple file layout with limited columns is used it is simple to include a header line defining each column and then importing that file into Excel to be able to check that the detail is recorded in the correct column.
With the proposed record layouts this will be a hair-raising task to identify where a problem is.
The initial release will have problems getting everything working, but the real drama is going to come when extra fields are added, or old fields are removed from the file. The fact that the header record provides for the file version number will assist to know what the file layout should look like but with so many different systems being involved I can see that changes down the line are going to be an issue.
When the original file structure was introduced, I spent many hours with the SARS developers debugging the systems and if it wasn’t for the source codes that process would have been almost impossible to get resolved.
Another point to take into consideration is that it is less confusing to refer to a unique field code when referring to a data item than a description. SARS always refers to Section xx or Schedule yy or paragraph a(b)iii(2) in the Income Tax Act and then there is a certainty to what is being referred to. As that is a standard way of doing those references it makes logical sense to keep the source codes in the BRS.
Another point on this issue is that when data is sent between systems it is accepted practice to do so in an XML, JSON or some other format that identifies each data item with a tag. These tags are usually long descriptions. Therefore using a 4-character source code is a much more efficient method of identifying the data items.

The current BRS specification will only require an additional first column in the tables for the recording of the Source Code and therefore the rest of the document is still effective. References to other fields in the BRS can have the source code included for clarity.

Record Structure
Section 4 on page 9 defines the record structure as:
2 The record structure of the file for employee monthly data is as follows:
o File Header Record
o Employer Demographic Record
o Employer Declaration Record
o Employee Demographic Record
o Employee Monthly Certificate
o Employee Year to Date Certificate
o File Trailer Record

Section 5.4
Checking the record layout detail of the ‘Employee’ records in section 5.4.2 there is a section 5.4.2.2 – Header which is a ‘Fixed’ record layout with 12 fields defined in this section.
This is followed by section 5.4.2.3 – Monthly Financial Information
This is a source code record layout.
The major problem here is that this record has no ‘key’ information present. The data on this record is only financial detail.
Where it is required to submit details for more than one period there will always be a header and financial record present on the file so that the financial data can be allocated to the correct period.
From a processing point of view having a financial record without any ‘key’ details is not good.
It would make much more sense to only have one record with the header and financial data together. This would then conform to the detail specified on page 9.
The same situation applies to the year-to-date record.

Telephone and Cell phone numbers
The length specification in the ‘File Header’ and ‘Employer Demographics’ records for these numbers is 0:0 or 1:15, but the validation rules require a number to be at least 10 characters long where the field is present.

Section 5.4.1
Identity Number (Page 33)
Length is specified as 1:13 but the Validations require this to be a South African Id number which is 13 characters.
Passport number (page 34)
Length is specified as 1:18 but Validations require a minimum of 6 characters.
Date of Birth (page 35)
The format is fixed and validation specifies the format as CCYYMMDD but the length is 1:8, should be 8:8.

Page 44 onwards – Postal Address
As there are different formats of Postal addresses depending on the ‘Postal Address Structure Indicator’ it would be safer to have this as the last section of the record.
If it is accepted that the Source codes are to be retained in the records, then the positioning of the Postal address data fields in the record is not a concern.

Section 5.4.2.1 Page 52
Bullet 4
Why is it not allowed to have a negative value for a ‘New’ transaction BUT when it is an ‘Amended’ transaction a negative is allowed? I thought that with amendments the full transaction must be supplied and not the delta. Therefore with an amendment, a negative can be loaded but not when a new record is supplied.

Section 5.4.3.1 Page 87
Under the General Rules bullet 2 it is stated that the year-to-date certificate must be included ‘in the last month of employment for employees who are no longer employed’.
This is not practical as payrolls are processed in advance of payday and therefore there are generally additional payments in the next month or even two months later.
Many of these payments are for variable payments for example overtime. The payroll system then keeps these employees in a state of termination in suspense so that any late payments can be processed. The user determines how long they want to keep the employee in this suspense state to allow for these late payments to be processed. The employee is then only terminated after the user-defined suspense end date is reached. The termination date recorded for the employee is the actual termination date which can therefore be a few months back. Under these circumstances, if this rule is to be applied there will be a year-to-date record for each month that the employee is in this suspense state. The transaction month will be the month in which the employee was paid for the variable payment BUT the termination date will be before the transaction month.
This is what happens in the payroll world. Will the monthly processing of data cater for this condition?