bulk payment request upload technical specification - ndis€¦ · web view07_004_0132_8_3 ......

ndis.gov.au

myplace Provider PortalBulk Payment Request Upload Technical Specification

Version Number: 1.5

Revision Date: 19 June 2016

myplace Provider Portal Bulk Payment Request Upload Technical Specification

Document Change HistoryVersion Date Change

1.0 7 November 2013

Initial document release. First Document reference 7,463,710

4 December 2013

Business review fixes

1.1 16 January 2014 Update to remove reference to StatusCode element

1.2 24 January 2014 Updates to XML schema validation on Qty. Updates to definition of xml header requirement. Inclusion of new CSV input file option.

1.3 26 June 2014 Incorrect date format fixed in the CSV file

1.4 15 September 2014

Updated to reflected addition of inkind funding program

1.5 19 June 2016 Updated to align to Full Scheme system

Version Number: 1.5 of 16 Revision Date: 19 June 2016


Table of Contents1 Overview......................................................................................................................42 Interface Details...........................................................................................................53 Reference Data............................................................................................................6

3.1 Support Item Reference List................................................................................................6

4 Message Definitions....................................................................................................74.1 XML Input File......................................................................................................................7

4.1.1 XML Data Types.......................................................................................................................7

4.1.2 XML Validation Rules................................................................................................................7

4.1.3 XML Input File Details...............................................................................................................7

4.1.4 XML Input File Definition...........................................................................................................74.2 CSV (Comma Separated) Input File..................................................................................12

4.2.1 CSV Validation Rules..............................................................................................................12

4.2.2 CSV Input File Details.............................................................................................................12

4.2.3 CSV Input File Definition.........................................................................................................12

5 Error Processing.......................................................................................................155.1 Output File Format.............................................................................................................15

5.1.1 Format..................................................................................................................................... 15

5.1.2 Output File Details................................................................................................................... 15

5.1.3 Output File Definition...............................................................................................................15



1 OverviewThis document provides the technical specification for the Bulk Payment Request Upload Interfaces (File Input/Output Formats) and is intended to provide information for third party software providers. It covers the following:

Interface Details – technical infrastructure, security and authentication

Reference Data

Message Format – data formats, commonly used data terms, examples and XSD Schemas

Error Processing



2 Interface DetailsThe bulk upload payment request interface is a facility that will allow providers to upload a file with payment requests exported from their in-house applications, and import that file for processing into the myplace Provider Portal.

While not intending to be a system to system interface in the “web services” sense, it will provide a “system to system interface” in the sense that data from the Providers in-house applications can be exported in an agreed format, and imported into the myplace Provider Portal for system processing.

Business process Summary1. Providers enter participant details in their in-house systems.

2. Providers export a file with payment requests from their in-house system (in a known format – see later for definitions).

3. Providers login to the myplace Provider Portal, select the “Payment Request” tile, then select “Bulk Payment Request Upload”.

4. Providers upload the file exported in step (2) into the myplace Provider Portal.

5. The myplace Provider Portal will apply format validation checks to verify that the input file is correctly formed and if not, users will get validation errors, and the file rejected.

6. If the file passes format validations, the myplace Provider Portal will accept the input file and queue it up for processing as soon as possible.

7. myplace Provider Portal users can do other tasks in the portal while the import completes, and can come back when notified that processing has completed.

8. myplace Provider Portal users verify that all payment requests in their uploaded file have been successfully imported (For error processing please refer to error processing section later in this document).

File FormatThe input file format is XML or CSV. The Error: Reference source not found section on page 7 contains format details and examples.

The output error file format is CSV. The Error Processing section on page 17 contains format details and examples.

Security and AuthenticationThe Security and Authentication function is provided via the myplace Provider Portal Web UI Interface and therefore uses the same authentication mechanism (PRODA).



3 Reference DataCode values are needed to prepare the bulk upload input file. Providers are responsible for downloading this reference data and using it in the bulk input file in the appropriate fields.

There are 2 reference data files provided: Support Item Number List and Download File Format.

Both data files can be downloaded by accessing the “Bulk Payment Request Upload” page from the Payment Request tile of the myplace Provider Portal.

3.1 Support Item Reference ListThe reference data lists Support Items in the NDIA supports catalogue along with their unique identifier.

The format is a Comma Separated Value file with 3 fields: SupportCategoryName, SupportItemNumber, and SupportItemDescription, with the first row as header row.

Example:

SupportCategoryName,SupportItemNumber,SupportItemDescription“SUPPORT_COORDINATION”, “07_004_0132_8_3”, “specialist support coordination”

“CB_CHOICE_CONTROL”, “14_034_0127_8_3”, “financial intermediary monthly processing”



4 Message Definitions

4.1 XML Input File

4.1.1 XML Data Types

Definitions of the data types used in input file can be found at the World Wide Web Consortium website. The URL for the specifications for the data types is http://www.w3.org/TR/xmlschema-2/#built-in-datatypes.

4.1.2 XML Validation Rules

The Message Definition tables in the following sections contain a column with Validation Rules. These are the rules that will be applied to the data as it is processed. Some of the data elements have a validation rule like “Must be a code provided in the Support Item Reference List reference table”.

All rules that apply in the online system apply to bulk uploads.

4.1.3 XML Input File Details

The input file can be populated with up 5000 payment requests (1000 is the recommended maximum) to be imported into the system.

The same business rules that apply when creating payment requests in the online system also apply when bulk uploading payment requests.

4.1.4 XML Input File Definition

XML Root: AddClaimRequestXML Child Node (up to 5000): Claim

Note: The xml header <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> is not mandatory. It is however, recommended practice to add it because it explicitly states what the text data encoding is. If not provided, the system will assume default encoding (ANSI, UTF-8 and ASCII will work by default).

Note: All Elements must be included for each Child Node, even if there is no data.

Elements within each Claim Node:


http://www.w3.org/TR/xmlschema-2/#built-in-datatypes


Element MandatoryConditionalOptional

Data Type

Length Format CommentsValidation Rules

RegistrationNumber Mandatory string 30 Provider Registration Number for the payment request

NDISNumber Mandatory string 20 Must be an existing Participant already connected to the Registration

SupportsDeliveredFrom

Mandatory Date Date Time when support is delivered from

W3C Standard Date format: (YYYY-MM-DD)

A future date cannot be provided

SupportsDeliveredTo Mandatory Date Date Time when support is delivered to



Must be greater than or equal to SupportsDeliveredFrom

SupportNumber Mandatory string 60 Support Item Reference Number – This is the Support Item for the service for the participant

Must be one of the “SupportItemNumber” codes found in the downloaded Reference data: Support Item Reference List on section 3.1 on page 6.

ClaimReference Optional String 50 Provider Reference for this payment request

Must not contain an apostrophe

Quantity Conditional decimal n.## (decimal with up to 2 decimal places)

This element is mandatory for Support Items which require Quantity

Leave element blank for payment requests that require Hours

Hours Conditional string 6 HHH:MM This element is mandatory for Support Items which require Hours

Leave element blank for payment requests that require Quantity

UnitPrice Mandatory decimal Money Must have two decimal places

GSTCode Mandatory string enumeration One of the following values:

Field will only accept the ‘P’ codes and not the text values. (‘P’ values are case sensitive and should be in upper case only).

P1 -Tax Free (0%)

P2 - Tax Claimable (10%)

P5 - Out Of Scope

AuthorisedBy Optional string 50 The logon Id of the person authorising the payment request

Legacy data element; not processed by system. Can leave blank.

ParticipantApproved Optional boolean true if the participant has approved the payment request

false otherwise


InKindFundingProgram Optional string 30 This is optional for support items that have In-Kind Funding for the payment request period.



4.1.4.1 XML Input File Example (2 payment requests)<?xml version="1.0" encoding="UTF-8" standalone="yes" ?><AddClaimRequest>

 <Claim> <RegistrationNumber>4050003167</RegistrationNumber> <NDISNumber>430192177</NDISNumber> <SupportsDeliveredFrom>2016-06-18</SupportsDeliveredFrom> <SupportsDeliveredTo>2016-06-18</SupportsDeliveredTo> <SupportNumber>03_501509092_0103_1_1</SupportNumber> <ClaimReference>1000000</ClaimReference> <Quantity>1</Quantity> <Hours></Hours> <UnitPrice>153.00</UnitPrice> <GSTCode>P2</GSTCode> <AuthorisedBy></AuthorisedBy> <ParticipantApproved></ParticipantApproved> <InKindFundingProgram></InKindFundingProgram> </Claim>

 <Claim> <RegistrationNumber>4050003167</RegistrationNumber> <NDISNumber>430192021</NDISNumber> <SupportsDeliveredFrom>2016-06-18</SupportsDeliveredFrom> <SupportsDeliveredTo>2016-06-18</SupportsDeliveredTo> <SupportNumber>07_004_0132_8_3</SupportNumber> <ClaimReference>1000000</ClaimReference> <Quantity></Quantity> <Hours>1:59</Hours> <UnitPrice>172.13</UnitPrice> <GSTCode>P2</GSTCode> <AuthorisedBy></AuthorisedBy> <ParticipantApproved></ParticipantApproved> <InKindFundingProgram></InKindFundingProgram> </Claim></AddClaimRequest>


4.1.4.2 Input File XSD Schema<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="AddClaimRequest"> <xs:complexType> <xs:sequence> <xs:element name="Claim" minOccurs="1" maxOccurs="5000"> <xs:complexType> <xs:sequence>

<xs:element name="RegistrationNumber"> <xs:simpleType> <xs:restriction base="xs:normalizedString"> <xs:minLength value="5"/> <xs:maxLength value="30"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:element name="NDISNumber" > <xs:simpleType> <xs:restriction base="xs:normalizedString"> <xs:minLength value="5"/> <xs:maxLength value="20"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:element type="xs:date" name="SupportsDeliveredFrom"/>

<xs:element type="xs:date" name="SupportsDeliveredTo"/>

<xs:element name="SupportNumber"> <xs:simpleType> <xs:restriction base="xs:normalizedString"> <xs:minLength value="5"/> <xs:maxLength value="60"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:element name="ClaimReference"> <xs:simpleType> <xs:restriction base="xs:normalizedString"> <xs:minLength value="1"/> <xs:maxLength value="50"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:sequence> <xs:choice> <xs:element name="Quantity" > <xs:simpleType> <xs:restriction base="xs:decimal"> <xs:minExclusive value="0"/> <xs:fractionDigits value="2"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:element name="Hours"> <xs:simpleType>



<xs:restriction base="xs:string"> <xs:pattern value="[0-9]{0,1}[0-9]{0,1}[0-9]:[0-5][0-9]"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:choice> </xs:sequence>

<xs:element type="xs:decimal" name="UnitPrice" />

<xs:element name="GSTCode"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="P1"/> <xs:enumeration value="P2"/> <xs:enumeration value="P5"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:element name="AuthorisedBy"> <xs:simpleType> <xs:restriction base="xs:normalizedString"> <xs:minLength value="1"/> <xs:maxLength value="50"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:element type="xs:boolean" name="ParticipantApproved"/><xs:element name="InKindFundingProgram" minOccurs="0"> <xs:simpleType> <xs:restriction base="xs:normalizedString"> <xs:minLength value="0"/> <xs:maxLength value="30"/> </xs:restriction> </xs:simpleType> </xs:element>

</xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element>

</xs:schema>



4.2 CSV (Comma Separated) Input File

4.2.1 CSV Validation Rules

The Message Definition tables in the following sections contain a column with Validation Rules. These are the rules that will be applied to the data as it is processed. Some of the data elements have a validation rule like “Must be a code provided in the Support Item Reference List reference table”.

All rules that apply in the online system apply to bulk uploads.

4.2.2 CSV Input File Details

The input file can be populated with up 5000 payment requests (1000 is recommended maximum) to be imported into the system.

The same rules that apply when creating payment requests in the online system apply when bulk uploading payment requests.

4.2.3 CSV Input File Definition

Row 1 : Headers with Field NamesRow 2 onwards (up to 5000): Claim request data

Note: The input file must include the header with field names as per the column names specified below (also refer to the example file input).

Elements within each Claim Row

Column MandatoryConditionalOptional

Data Type


RegistrationNumber Mandatory string 30 Provider Registration Number for the payment request

NDISNumber Mandatory string 20 Must be an existing Participant already Connected to the Registration


Mandatory Date Date Time when support is delivered from



SupportsDeliveredTo Mandatory Date Date Time when support is delivered from



Must be greater than or equal to SupportsDeliveredFrom



Column MandatoryConditionalOptional

Data Type


SupportNumber Mandatory string 60 Support Item Reference Number – This is the Support Item for the the service for the participant

Must be one of the “SupportItemNumber” codes found in the downloaded Reference data: Support Item Reference List on section 3.1 on page 6.

ClaimReference Optional String 50 Provider Reference for this payment request

Must not contain an apostrophe

Quantity Conditional decimal n.## (decimal with up to 2 decimal places)

This element is mandatory for Support Items which require Quantity.

Leave element blank for payment requests that require Hours

Hours Conditional string 6 HHH:MM This element is mandatory for Support Items which require Hours

Leave element blank for payment requests that require Quantity

UnitPrice Mandatory decimal Money Must have two decimal places

GSTCode Mandatory string enumeration One of the following values:

Field will only accept the ‘P’ codes and not the text values. (‘P’ values are case sensitive and should be in upper case only).

P1 -Tax Free (0%)

P2 - Tax Claimable (10%)

P5 - Out Of Scope

AuthorisedBy Optional string 50 The logonId of the person authorising the payment request


ParticipantApproved Optional boolean true if the participant has approved the payment request

false otherwise


InKindFundingProgram Optional string 30 This is optional for support items that have In-Kind Funding for the payment request period.




4.2.3.1 CSV Input File Example (2 payment requests)

RegistrationNumber,NDISNumber,SupportsDeliveredFrom,SupportsDeliveredTo,SupportNumber,ClaimReference,Quantity,Hours,UnitPrice,GSTCode,AuthorisedBy,ParticipantApproved,InKindFundingProgram

4050003167,430192177,2016-07-05,2016-07-05,07_004_0132_8_3,ab0002,,1:59,172.13,P2,,,4050003167,430192177,2016-06-18,2016-06-18,03_501509092_0103_1_1,ab0003,1,,153.00,P2,,,



5 Error ProcessingUsers will have the facility to download an error file for their submissions. Errors can be fixed in one of two ways:

a) Using the myplace Provider Portal:

Description: Users look at the errors in the error file, and go to one of the Create Payment Request screens (Create Payment Request tile or Bulk Payment Request Upload tile) and re-enter the payment request errors.

This is a good option when there are only a few errors in the error list.

b) Fixing the errors in the source system

Description: Users look at the errors in the error file, fix the errors in their source system, and upload another file (only with fixed records) for processing.

5.1 Output File Format

5.1.1 Format

The file format of the error file will be CSV. This format allows users to open the error file directly into their preferred tool (i.e. MS Excel, Libre Office, etc.) in their desktop, facilitating the task to identify and fix errors.

5.1.2 Output File Details

The output file will be populated with payment requests that were imported in error and were not accepted as payment requests by the system.

5.1.3 Output File Definition

Header Row: Field NamesChildren Rows (repeated): One row per claim in Error

Elements within each Claim NodeElement Data Type Length Format

ErrorMessage string 100

RegistrationNumber string 30

NDISNumber string 20


Date

SupportsDeliveredTo Date

SupportNumber string 60



Element Data Type Length Format

ClaimReference String 50

Quantity Int

Hours string 6 HHH:MM

UnitPrice decimal Money

GSTCode string

AuthorisedBy string 50

ParticipantApproved boolean

StatusCode string

5.1.3.1 Output File Example (2 payment requests imports with errors)ErrorMessage,RegistrationNumber,NDISNumber,SupportsDeliveredFrom,SupportsDeliveredTo,SupportNumber,ClaimReference,Quantity,Hours,UnitPrice,GSTCode,AuthorisedBy,ParticipantApproved,StatusCode

”Invalid Data”,1000,12345,2016-07-01,2016-07-31,ABCDE1,1,10,,100.10,P1,,,”Invalid Data”,1000,12345,2016-07-01,2016-07-31,ABCDE1,1,,1.59,100.10,P1,,,


bulk payment request upload technical specification - ndis€¦ · web view07_004_0132_8_3 ......

Documents