Inflow Process Specification: Confidential

Inflow Process Specification
Confidential – By no means does Car-Pass authorize the reader to internal use the present information.
The information contained in the present proposal may not be disclosed to any other people or organization
without prior authorization of Car-Pass. This information cannot be sold or given for commercial purpose.
Document status
version 9.1.2 – 10/09/2021
Version Date Changes

1.0 23/04/2006 First public version
2.0 28/06/2006 - several clarifications after meeting with importers/software companies
- added feedback type in header row of an input file to allow FTP
feedback and e-mail feedback to a specified e-mail address
- XML Schema’s updated
- reception feedback simplified
3.0 11/09/2006 several clarifications (production ftp url, sender id = user id, production
http upload url)
4.0 14/04/2010 added section about directly opening history screen in the web application
5.0 17/06/2010 clarified how to select a language when directly opening history screen
6.0 14/05/2014 New chapter of Web services
6.1 03/05/2014 Added a Status for “Request Odometer Reading Status Response”
method in Webservice
6.1.1 11/08/2014 Corrections in examples page
CAR-PASS Inflow Process Specification 9.1.1 – Page 1 of 38

6.1.2 17/09/2014 Corrected Web Service examples in 5.2
6.1.3 5/1/2015 Added correct production WSDL links
6.1.4 10/02/2015 Host added
6.1.5 17/02/2015 Correction in examples xsi (xsi:noNamespaceSchemaLocation)
6.1.6 27/01/2016 FTP protocol Deprecated
Webservice flow added
6.1.7 25/10/2016 Added section OK Label
Correction in mandatory field flat file (issue id)
6.1.8 08/09/2017 Updated to reflected changes on issue feedback when the issue can’t be
corrected
6.2 20/09/2017 Delivery of data by FTP is set to END OF LIFE
7 05/07/2018 HTTPS, FTP removed (stop 1/03/2019)
8 21/12/2018 Added V2 of the Professional Web Services, adding extra functionality for
Vehicle History Reports
Added 4.2.2 General requirements
8.1.0 02/08/2019 Correction document added
Scheme business process overview added
Added important remarks Vehicle History Request
9.0. 07/08/2019 Complete review of the Inflow Process Specifications
FTP stops 31/12/2019
OK Label deprecated
Issue list added
9.0.1 29/01/2020 Correction in VHR (Paragraph 5.2.3)
Optional field languageHistoryReportPdf added in example
9.1 17/02/2021 Paragraph 3.4 - Comments added for ‘ONGOING’ problem

Paragraph 5.2.4 - OK label in VHR deprecated
Paragraph 5.3 - Manual Correction Form deprecated
Annex 6.1 - List of IssueTypes reviewed
Annex 6.3 - Good practices reviewed
9.1.1 08/04/2021 Annex 6.1 – IssueType 147 added
9.1.2 10/09/2021 Paragraph 5.1.2 (page 16) Security settings: supported TLS and Ciphers
versions

Table of Contents
1 Context and Objectives ...................................................................................................................... 4
2 Car-Pass Dictionary............................................................................................................................ 5
3 Business processes ........................................................................................................................... 6
3.1 Important Notice ................................................................................................................................... 7
3.2 Send a new odometer reading .............................................................................................................. 8
3.3 Send an odometer reading correction................................................................................................... 9
3.3.1 Categories of issues ............................................................................................................................. 9
3.3.2 How to respond to an issue? ...............................................................................................................10
3.4 Request a vehicle history report (VHR) ...............................................................................................12
4 Communication channels .................................................................................................................13
5 Web Services .....................................................................................................................................14
5.1 WSDL ..................................................................................................................................................15
5.1.1 Location ...............................................................................................................................................15
5.1.2 Security................................................................................................................................................15
5.1.3 Dataflow...............................................................................................................................................16
5.2 Webservices for each type of input ......................................................................................................19
5.2.1 Register Odometer Reading ................................................................................................................19
5.2.2 Register Request Status Response .....................................................................................................22
5.2.3 Request Odometer Reading Status .....................................................................................................23
5.2.4 Request Odometer Reading Status Response ....................................................................................24
5.3 Manual Correction procedure ..............................................................................................................28
6 Annexes..............................................................................................................................................31
6.1 Issue List .............................................................................................................................................32
6.2 Issues that cannot be corrected, (automatically closed). .....................................................................35
6.3 Good practices – Car-Pass approved DMS .........................................................................................36

1 Context and Objectives
Car-Pass is the nonprofit organization created by FEBIAC (Belgian federation of the Car and Two-
wheeler Industries), GOCA (Regroups recognized organizations in charge of the technical car control)
and Traxio (Federation of car vendors, car service professionals as well as linked sectors), charged by
the legislator with a task of public interest i.e. to protect buyers and to promote the fair trade in used
vehicles by combating fraud with the odometer.
The reason of existence of the organization arises from the federal law of 11/06/2004, modified by the
law of 28/11/2018. The purpose of this legislation is the prevention and repression of fraud linked to
odometer manipulations and provide transparent information about used cars to the buyer. The
essential principles are the following:
▪ Mileage fraud is considered a serious crime sanctioned with severe penalties (up to 1 year
imprisonment)
▪ Creation of a central database containing the odometer readings of all vehicles (cars and vans)
registered in Belgium
▪ All professional car dealers and repair shops are required to transfer VIN number, mileage and
date when repairing or maintaining a vehicle or replacing parts (ex. tyres, windscreens,…)
▪ The seller of a second hand vehicle is obliged by law to deliver a certificate showing the mileage
history of the vehicle to the buyer. If he fails to do so the transaction is void
The Car-Pass nonprofit was certified by royal decree of 4/5/2006 to manage the database and issue
the mileage certificates.
To fulfill its mission, Car-Pass developed an information system covering the following objectives:
▪ Centralize odometer status information originating from multiple data providers located all over
the Belgian territory.
▪ Store the kilometer information about all cars and vans registered in Belgium and gathered at
different moments during their ‘lifetime’
▪ Guarantee the quality, security and confidentiality of all centralized data.
▪ Deliver the Car-Pass document that shows the mileage history of a car to any potential buyer
of a second hand car.
As of the 1st March 2019 the modification of the 2004 law entered into force. One of the objectives is to
improve the accuracy of the communicated odometer readings. The 2004 legislation allowed
companies 5 working days to communicate their data to Car-Pass. If companies made a mistake in
registering the odometer reading it was, of course, very difficult to rectify as the vehicle had long since
left the workshop. This is why the new wording stipulates that the data must be sent to Car-Pass
immediately, i.e. while the vehicle is still on the company premises. Therefore, if a company uses file
transfer for communicating its data to Car-Pass, it will be non-compliant with the new legisaltion. Hence,
as from 1/1/2020 only the use of webservices and input via the Car-Pass website will be supported.
When offering a registered vehicle for sale, any professional car seller is obliged by law to indicate the
kilometre history of the vehicle and the other information foreseen by the law . as these are made
available by the association referred to in Article 6 at that moment in time.

2 Car-Pass Dictionary
Throughout the document different terms are used. Here are definitions of the user terminology.
To explain some terms an example enterprise is given:
Garage “Cool Cars” has 3 sites where Vehicles are sold and repaired and one headquarter (Cool Car
HQ) where all administration is done.
- Cool Car 1
➔ Establishment number 2xxxxxxxx1
- Cool Car 2
- Cool Car 3
- Cool Car HQ
➔ Enterprise number 04xxxxxxx1
Establishment number and enterprise number refers to the official data in KBO/BCE (Kruispuntbank
van ondernemingen/ Banque Carrefour des Enterprises),
Odometer Readings are read in the three sites and the headquarters centralizes all data and sends it
to Car-Pass.
Term Description
VIN Vehicle Identification Number. The unique number for the
identification of a vehicle
Odometer Reading The value of the Odometer as displayed on the
dashboard.
Enterprise n° (legally responsible) In the used example this must be 04xxxxxxx1 (10 digits
always starting with 0(zero))
User code for the party that entered the Identifies the Organization that performed work on the
data (usually the establishment n°) Vehicle and noted the Odometer Reading
In the used example this can be

- 2xxxxxxxx1
- 2xxxxxxxx2
- 2xxxxxxxx3
Internal code (optional) Can be:

- Name of the technician
- Invoice number
- Order number
- …

3 Business processes
The legal mission of Car-Pass is to centralize all odometer readings registered by the automotive
professionals in Belgium and make them available for potential buyers of used cars. As to this
centralization we can identify three main processes.
• The first covers the sending of an odometer reading.

• As errors may occur, the second process handles data correction requests.
• The third main process is the vehicle history request of a vehicle. This is in fact a specific
variant of the sending of an odometer reading.

3.1 Important Notice
Needless to say, that the accuracy of the transmitted data is very important. We expect that
professionals transfer the exact value they read on the dashboard, no approximate values or rounded
numbers. They need also to pay attention that the date matches with the value of the odometer reading.
Errors, if they remain uncorrected, will eventually appear on the Car-Pass document of the vehicle and
may result in a considerable loss of the residual value.
Do note that the Car-Pass legislation only applies for passenger cars and light commercial vehicles
(maximum permissible weight up to 3,5 t). Odometer readings of heavy trucks, busses or motorcycles
don’t need to be sent to Car-Pass and in any case will be rejected.
Car-Pass has drafted a set of guidelines to improve the quality of the transmitted odometer data. If
correctly implemented by the software developer, he can apply for the ‘Car-Pass approved DMS’
certificate (see annex 6.3)
Do note that our maintenance window for ‘production’ is Thursday 19h – 24h (CET)

3.2 Send a new odometer reading
The main input into the system consists of odometer status information communication. Five steps can
be identified in this procedure.
▪ Take note of the odometer reading on the dashboard: this operation is performed by a staff
member in the workshop and for obvious reasons requires the presence of the vehicle.
▪ Send the odometer reading to Car-Pass: the professional (or Car-Pass user) sends the
kilometer information to Car-Pass, either via de Car-Pass website (not discussed in this
document) either via a third party software (DMS). He needs to identify himself in order to
access the Car-Pass environment.
▪ Validate and parse data: reception, validation and parsing by Car-Pass of kilometer
information according to the known type and format (see below for exact definitions)
▪ Store information in DB: transformation of the raw data to the Car-Pass format as well as
verification of the information based on a set of quality standards, technical information
(odometer) and transformation rules. The concerned cars historical information combined with
alert rules allow the definition of additional criteria making it possible to detect errors and reject
the information.
▪ Request feedback: the software hast to request for information about the result of the
validation of the provided data is returned to the professional.
The feedback by Car-Pass may confirm that the data has been validated and loaded. On the other
hand, the validation may have raised issues. In that case a correction is needed.
Important notices:
▪ Car-Pass expects to receive the exact odometer reader indicated on the dashboard, no
approximate values or rounded numbers.
▪ Workshops have to send the data they hold to Car-Pass immediately, when the vehicle is still
in the workshop. Since the 1st of March 2019, professionals are not allowed to wait for 5
working days before transferring the data.
▪ Car-Pass doesn’t accept that a same user sends an odometer for the same vehicle twice. The
second reading will generate an error and will be rejected.
▪ The kind of intervention (ex. general maintenance, tyres replaced, gearbox repair) doesn’t need
to be mentioned to Car-Pass. Only when the odometer itself has been repaired or replaced, a
different data type (121 instead of 120) has to be used.

3.3 Send an odometer reading correction
The Car-Pass system may generate issues after the validation of the received data. There are three
categories of issues:
1. Error
2. Warning
3. Anomaly
3.3.1 Categories of issues

3.3.1.1 Error
When an odometer reading generates an error, this means that Car-Pass cannot or refuses to load the
data in its data base.
Errors result from various causes: faults in the data structure, wrong authentication, typos or
infringement of Car-Pass business rules, etc.
Examples: user code is invalid, VIN is unknown in the database of CP, date has an invalid structure,
etc.
Depending on the cause of the error, corrections can be made by the user (ex. typo in the VIN) or an
intervention from the software supplier or Car-Pass helpdesk can be necessary.
3.3.1.2 Warning
When an odometer reading generates a warning, this means that Car-Pass has loaded the data in its
data base but suspect there might be something wrong with it. We recommend the user to double check
the input and make a correction if the input was wrong.
Examples: the odometer reading is a rounded number, the odometer reading is much higher than
expected based on previous mileages, etc.
3.3.1.3 Anomaly
An anomaly is raised, when the user transmits a mileage that is lower than the most recent mileage
stored in the database of Car-Pass for that vehicle. As odometer value always increases this should
normally not occur. We recommend the user to double check the input and make a correction if the
input was wrong.
As this issue can result from previous errors in the mileage history, the data are stored in the database.

The table below presents a summarized overview of the different issue categories:
issue type data stored correction possible

error  
warning  
anomaly  
The complete list of all different kind issues, classified by category, can be found in annex 6.1.
It is possible that one odometer reading generates different issues.
3.3.2 How to respond to an issue?
It is crucial that the user responds to the issues raised by Car-Pass. They can be an indication of
(serious) underlying problems.
Errors lead to data loss for Car-Pass and non-compliancy with the legislation for the user. Indeed, if the
data cannot be stored in the Car-Pass database, due to faulty data structure of authentication problems,
the professional risks severe penalties in case of an inspection by the Economic inspection.
Warnings caused by erroneous odometer readings will result in errors on the Car-Pass document, that
can lead to considerable financial losses for the car owner when selling its vehicle. Buyers may indeed
withdraw when considering the untrustworthy odometer history.
Therefore the inputs that generate issues must be doublechecked and corrected. If a user doesn’t
respond to an anomaly or warning, the data remains as it is in the database of Car-Pass.
Only in some exceptional cases, corrections are not possible.
Important notices:
To avoid fraudulent behavior, an input can only be corrected once. If the correction generates
again one or more issues and the user realizes he has made an error twice, he will have to fill
in a signed correction form and mail it to Car-Pass. After evaluation if the correction is justified,
Car-Pass will rectify the error.
When a user wants to correct an Odometer Reading that has been accepted without raising
any issue, he will have to contact the helpdesk of Car-Pass.
When a correction is handled successfully, all Issues related to the same odometer reading will be
closed.

The correction procedure for errors, warnings and anomalies can be graphically represented as follows:

3.4 Request a vehicle history report (VHR)
Professional dealers offering second-hand vehicles for sale are legally obliged to display the information that
appears on the Car Pass in the advertisement and showroom. Therefore they have to request a vehicle history
report via web services or the Car-Pass website.
To request a Vehicle History Report (VHR), the user has to provide, the VIN and the Odometer Reading of the
day. It is not allowed to include another date in the VHR request than the date of the request. It goes without
saying that the odometer reading must be accurate and match with the day of the request because Car-Pass
will store this data and they will appear an all upcoming VHR and Car-Pass documents.
In fact a request for a VHR is treated as an ordinary odometer reading (see 3.2). Therefor the same web
service method is used as to provide a new Odometer Reading. The distinction is made based on the provided
data type (010).
Important Notice:
If the provided data caused an issue (see 3.3), an issue feedback is returned . This issue has to be
solved before the user can retrieve the Vehicle History Report.
Issues can be corrected on the same way as a normal correction. When the correction valid and the data is
accepted by Car-Pass the Vehicle History Report will be generated. The professional can retrieve the Vehicle
History report by performing a status request. The VHR contains a unique hyperlink. This hyperlink needs to
be included in the advertisement for the vehicle, to allow potential buyers to consult the Car-Pass data for that
particular vehicle. It is also possible to receive the vehicle history as a pdf, that can be printed and apposed in
or closed to the vehicle in the showroom.
While creating a vehicle history we consult several external databases. These sometimes respond very
slowly or not at all. For this, our timeout is set to 1 minute. When we return an 'ONGOING', it means that we
are waiting for a response. Please write your application so that it recalls the method
'requestOdometerReadingStatus' with a maximum of 1 request in 10 seconds until you get a valid response
back that is different from 'ONGOING' and this for a duration of minimum 90 seconds.

4 Communication channels
The first objective of the Car-Pass system is the centralization of information originating from multiple sources.
The range of potential data providers is wide, going from large companies and organizations as the car
importers, tyre shop networks or technical inspection to the local independent car service professional. To
cover all of these potential data providers, 2 channels will be proposed by Car-Pass.
The following alternatives are presented.
▪ Use the Car-Pass website

A client can provide odometer readings, correct data and request odometer reports. No
implementation is needed, only an updated computer.
▪ Integrate the webservices in a third party application.

To make it possible for existing applications to integrate with the Car-Pass system. The user interfaces
send and correct their data directly into the Car-Pass system.
An overview of the client and communication layer of the Car-Pass system is presented in the figure below.
Only WEB SERVICES will be supported to interface with the Car-Pass system.
Important Notice:
The change of the law foreseen for the 1st of March 2019, mandates that an odometer reading has to be send
to Car-Pass while the vehicle is still in the workplace. And the correction of faults has to be done immediately.
Because FPTs isn’t a real time communication channel we will stop our FTP server at 01/01/2020.

5 Web Services
This solution offers the possibility to provide Odometer Readings, corrections and VHR requests through Web
services. Only authenticated users and senders will be allowed to connect to the Web Service. Before
users and senders will be able to connect to the Web Service, they will have to activate their account at the
Car-Pass website.
.
There are just 2 operations:
- registerOdometerReading (can be used for normal registrations, history requests and to make
corrections)
- requestOdometerReadingStatus
Versioning
• Version 2 provides extra functionalities for Vehicle History Report but has mostly the same structure
as Version 1
• All new development should happen on version 2, and users already working with version 1 are
advised to switch to version 2 as version 1 will no longer be updated.
• Version 1 wsdl: https://ws-professionals.beta.car-pass.be/carpass-web-services-
professional/WSCarPassPro?wsdl=CarPassWSPro.wsdl
• Version 2 wsdl: https://ws-professionals.beta.car-pass.be/carpass-web-services-
professional/WSCarPassPro2?wsdl=CarPassWSPro2.wsdl

5.1 WSDL
5.1.1 Location
To provide Odometer Readings (PROC-INPUT-3) or to request Vehicle History Reports at Car-Pass, a (SOAP)
web service has been created.
The WSDL for the web services can be found at: https://ws-professionals.beta.car-pass.be/carpass-web-
services-professional/WSCarPassPro2?wsdl
5.1.2 Security
The Authorization header is constructed as follows:

1. Username and password are combined into a string "username:password"
2. The resulting string is then encoded using the RFC2045-MIME variant of Base64, except not limited to 76
char/line
3. The authorization method and a space i.e. "Basic " is then put before the encoded string.
The web service can only be accessed with a username and password. These credentials must always be
provided while making a request to Car-Pass.
For each request the following date must be provided:
• POST: the url of the web service WSDL
o https://ws-professionals.beta.car-pass.be/carpass-web-services-
professional/WSCarPassPro2?wsdl (*)
• Accept-Encoding:
o gzip,deflate
• Content-Type:
o Text/xml;charset=UTF-8
• SOAPAction:
o Leave empty
• Authorization:
o Basic authentication is used. The authentication follows the following pattern:
▪ “Basic ”
▪ Username:password, base64 encrypted ( the RFC2045-MIME variant is used)
• Content-Length:
o 848
• Host: the host of the web service
o ws-professionals.beta.car-pass.be
• Connection:
o keep-alive
• User-Agent:
o Apache-HttpClient/ 4.1.1
(*) the production url is: https://ws-professionals.car-pass.be/carpass-web-services-

professional/WSCarPassPro2?wsdl
See the necessary header in the example below:
POST https://ws-professionals.car-pass.be/carpass-web-services-professional/WSCarPassPro2?wsdl

Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: ””
Authorization: Basic MjAwKKAwNjAwMTpQcjBlZSRza!:uYWw=
Content-Length: 848
Host: ws-professionals.car-pass.be
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1
<soapenv:Envelope …>
…
</soapenv:Envelope>
TLS versions
Only TLSv1.2 and TLSv1.3 is supported
Ciphers:
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
Fix on Windows server: Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in
Windows (microsoft.com)
General info about TLS security NSA: ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF (defense.gov)
5.1.3 Dataflow
The WEBSERVICES are setup asynchronously.
In the pictures below you see the different steps that can be taken.

Important Notice:
We recommend to implement a minimum delay time of minimum 2 seconds between the

registerOdometerReading and the requestOdometerReadingStatus.

While creating a vehicle history we consult several external databases. These sometimes respond very
slowly or not at all. For this, our timeout is set to 1 minute. When we return an 'ONGOING', it means that we
are waiting for a response. Please write your application so that it recalls the method
'requestOdometerReadingStatus' with a maximum of 1 request in 10 seconds until you get a valid response
back that is different from 'ONGOING' and this for a duration of minimum 90 seconds

5.2 Webservices for each type of input
This paragraph describes the data exchanged with the Car-Pass system through Web services for each of the
input and feedback procedures. Both content and structure of the files or messages will be discussed. Please,
use only the WSDL for generating your code. The examples in the Inflow Process Specification are only
indicative.
5.2.1 Register Odometer Reading

The following elements are contained in the odometer status:
▪ Correction
▪ VIN of the Observed Vehicle
▪ Odometer Reading status
▪ Type of the data
▪ Date of the observation
▪ Code (enterprise n°) for the party legally responsible for the information
▪ Code (user code) for the party that entered the data
▪ Date of first Use (optional)
▪ Unifier (optional)
▪ Issue id (optional)
This request can be used for 3 purposes:

▪ Provide new Odometer Reading (5.2.1.1)
▪ Correct Issue (5.2.1.2)
▪ Request Vehicle History Report (5.2.1.3)
When the request is successful a response is returned with a unique key that will be the reference for all
further communication with Car-Pass.
5.2.1.1 Provide new Odometer Readings
To provide a new Odometer Reading, make sure that you use the following rules
▪ Correction:
o set to “false”
▪ VIN:
o maximum 17 characters
▪ OdometerReading:
o provided to correct Odometer reading value (0, 1 and 3 are not allowed)
▪ dataTypeId:
o use 120 for a normal Odometer Reading (equals service reparation)
o use 121 for a replaced or repaired odometer
▪ OdometerReadingDate:
o format “yyyy-MM-dd”
▪ enterpriseOrganisationID:
o the legally responsible
▪ enteredOrganisationId:
o the User code of the party that entered the data.
▪ firstUseDate:
o this is an optional field
o format “yyyy-MM-dd”
▪ unifier:

o When the VIN contains less than 17 characters, the Unifier is useful for unique identification
of the vehicle.
See a full example below:
SOAPAction: ””
Authorization: Basic:MjAwKKAwNjAwMTpQcjBlZSRza!:uYWw=
Content-Length: 848
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:prof="https://professionals.webservices.carpass. ... .be/">
<soapenv:Header/>
<soapenv:Body>
<prof:registerOdometerReading>
<request>
<correction>false</correction>
<vin>VNWS0000000005250</vin>
<odometerReading>1234</odometerReading>
<dataTypeId>120</dataTypeId>
<odometerReadingDate>2014-04-25</odometerReadingDate>
<enterpriseOrganisationId>0400006000</enterpriseOrganisationId>
<enteredOrganisationId>2000006001</enteredOrganisationId>
<firstUseDate>2000-01-01</firstUseDate>
<unifier>1</unifier>
</request>
</prof:registerOdometerReading>
</soapenv:Body>
</soapenv:Envelope>
5.2.1.2 Correct Issues
For the correction of issues the same web service method, registerOdometerReading, is used
To provide a new Correction, make sure that you use the following rules
▪ Correction:
o set to “true”
▪ dataTypeId:
o Use “120” for modification of the data. Make sure you provided the update value of the field
that needs to be modified
o Use “121” for modification of the data in case of a replaced or repaired odometer
o Use “010” for correction of a vehicle history request
o Use “080” to confirm the first provided Odometer Reading that caused the Issue as correct or
to close the Issue without further modification.
▪ IssueId:
o Provide Issue ID that you want to correct.
.
In case there are multiple issues caused by one odometer reading: when you correct one issue, the other(s)
will also be closed.

SOAPAction: ””
Content-Length: 848
xmlns:prof="https://professionals.webservices.carpass. … .be/">
<soapenv:Header/>
<soapenv:Body>
<request>
<correction>true</correction>
<vin>VNWS0000000005250</vin>
<firstUseDate>2000-01-01</firstuseDate>
<issueId>8850</issueId>
</request>
</soapenv:Body>
</soapenv:Envelope>
As a result of an odometer status correction, the standard feedback procedures will be invoked. In case the
correction solved the problem, the load will be reported in the load feedback. In case the correction recreated
the problem or invoked a new one, an issue feedback will be triggered.
5.2.1.3 Request Vehicle History Report
A Vehicle History Report can be requested through the web service. To retrieve it, a new correct Odometer
Reading must be provided. The date has to be the date of the request. The same web service method as for
a normal Odometer Reading is used; registerOdometerReading.
Important Notice
You will only receive a vehicle history report after the issues are solved.
Remarks:
- The provided odometer reading will appear on the Vehicle History Report and / or on the Car-Pass Certificate.
- Request a vehicle history report for other users -‘third party request’- is not allowed. You will receive
issueType 242
Use the rules from 5.2.1except for:

▪ Correction:
o set to “false”
▪ dataTypeId:
o use “010” for a vehicle history report
▪ enteredOrganisationId:
o the Organisation number of the enterprise or establishment that requested the Vehicle History
Report and who is allowed to request it.

▪ odometerReadingDate:
o The date has to be the current date
POST http://ws-professionals.car-pass.be/carpass-web-services-professional/WSCarPassPro2?wsdl
SOAPAction: ””
Content-Length: 848
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:prof="

https://professionals.webservices.carpass. ... .be /">
<soapenv:Header/>
<soapenv:Body>
<request>
<correction>false</correction>
<vin>VNWS0000000005250</vin>
</request>
</soapenv:Body>
</soapenv:Envelope>
5.2.2 Register Request Status Response
Each web service Request will return a response. This will inform the requestor on:
• The Status of the Request
• A unique ID to track the Request and to retrieve the status
The following elements are contained in the odometer status response:

▪ Status: Possible values are
name description
OK The request was successful, all parameters
are in the correct format. Car-Pass is
processing the request.
VALIDATION_ERROR There was an error during the validation of
the parameters.
e.g. the date was in a invalid format
CONNECTION_ERROR There was a problem while connecting to
Car-Pass. This request is not invalid, but
should be resend again.
AUTHENTICATION_ERROR The credentials used to connect with the
web service are invalid.

▪ RequestId: A GUID of 36 characters, format xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx
This GUID needs to be saved, because this is the key to the further processing of the request
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns2:registerOdometerReadingResponse xmlns:ns2=”https://ws-professionals.car-pass.be/carpass-
web-services-professional/WSCarPassPro2?wsdl ">
<return>
<status>OK</status>
<requestId> 52d71495-9c2b-46d7-862f-12543299ff3f</requestId>
</return>
</ns2:registerOdometerReadingResponse>
</soap:Body>
</soap:Envelope>
5.2.3 Request Odometer Reading Status

For each new Odometer reading that is provided or a Vehicle History Report that is requested through the web
service a status can be retrieved.
This can be done using the web service method “requestOdometerReadingStatus”
The following elements are contained in the Request Odometer reading status:
▪ requestId
▪ languageHistoryReportPdf: this is an optional field. Can be NL, FR, DE
▪ includeHistoryReportPdf- Boolean – values: true or false
o Optional field, if not provided it will be handled as false
o Set this as true if the request was a Vehicle History Report and you want to include the PDF
in the answer, see below
.
The requestId is the returned id, described in paragraph 5.2.2.
SOAPAction: ””
Content-Length: 848
xmlns:prof="http://professionals.webservices.carpass. .be/">
<soapenv:Header/>
<soapenv:Body>
<prof:requestOdometerReadingStatus>
<request>
<requestId> 52d71495-9c2b-46d7-862f-12543299ff3f</requestId>
<includeHistoryReportPdf>true</includeHistoryReportPdf>
<languageHistoryReportPdf>DE</languageHistoryReportPdf>
</request>
</prof:requestOdometerReadingStatus>

</soapenv:Body>
</soapenv:Envelope>
5.2.4 Request Odometer Reading Status Response

Each status request will return a response.
The following elements are contained in the VHR status response:
▪ Status: Possible values are listed in 5.2.2

▪ Requeststatus:
name description
READY The Odometer Reading is valid and
accepted at Car-Pass. It is possible one or
more issues are returned that need to be
confirmed or corrected.
When a Vehicle History Report is requested,
it is returned in the response
ONGOING The request id provided is known at Car-
Pass, but it the processing is not completed.
Please try again later
UNKNOWN The provided request id is not known. Please
try again later.
ERROR There is an blocking Issue with the provided
Odometer Reading, the registration is not
accepted by Car-Pass. One or more issues
are returned.
There is no Vehicle History Report available
DELETED The Vehicle History Report is no longer
available at Car-Pass. Please provide a new
request to retrieve a new Vehicle History
Report.
NOT_ALLOWED The Sender is not allowed to request the
status for the provided RequestId
▪ VIN:
o the VIN of the provided Odometer Reading
▪ Unifier (optional):
o the Unifier of the provided Vehicle
▪ Date of first Use (optional):
o the first use date of the provided vehicle
▪ Vehicle History Report: Object is only included when the request was for a Vehicle History Report
(Datatype 010)
o publicUrl: a url that shows the Vehicle History Report data, can be used in advertisements
about a second hand car that is being sold
o okLabelStatus: This element is deprecated. We will always give back ERROR.
o file: a base64 encoded string that represents the a PDF of the Vehicle History Report
o filename: a name that can be used to store the included PDF
If the Request Vehicle Report causes issues, the publicUrl nor the PDF will be returned. First the issue
have to be corrected with dataTypeID 010 or confirmed (080)
The fields file & filename are only included in the response, when this was requested in the
requestOdometerReadingStatus method (includeHistoryReportPdf)
▪ Collection of Issues

o Issue Type: the Issue code to define the type of the Issue
o Description: the description of the Issue
o Issue ID: a unique issue number. Is the reference to correct the Issue. If not available the
issue can’t be corrected.
Example 1: Without issues, with Vehicle History Report
<soap:Body>
<ns2:requestOdometerReadingStatusResponse
xmlns:ns2="http://professionals.webservices.external.shared.carpass.roots.be/">
<return>
<status>OK</status>
<requestStatus>READY</requestStatus>
<vin>DEFVN000000000A19</vin>
<vehicleHistoryReport>
<publicUrl>https://public.beta.car-pass.be/vhr/d0e17276-b665-48f4-8fce-
82fb443abd4d</publicUrl>
<file>JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCA1OTcvSGVpZ2h0ID
IwMC9GaWx0ZXIvRENURGVjb2RlL0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9MZW5ndGggMzQ4MjY+Pn
N0cmVhbQr/2P/gABBKRklGAAECAABkAGQAAP/sABFEdWNreQABAAQAAABkAAD/7gAOQWRvYmUAZMAAAAAB/9sAhAABAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgICAgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQIBAQICAgECAgMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCADIAlUDAREAAhEBAxEB/8QA5QABAAEEAw
EBAQAAAAAAAAAAAAoHCAkLBAUGAwECAQEAAgIDAQEBAAAAAAAAAAAABQYDBAIHCAEJChAAAAYCAgEDAQQDBRENCQAAAAECAwQFBg
cRCBIhEwkUMSIVCkEyFmEjtdV3UTMk1JVWthc3txg4SHiIyDlxkUJTVCU2dpZXl1gZgcHRYmPTRKYaEQABAwIEAQcGCAgKCAQHAQ
ABAAIDEQQhMQUGEkFRYZEiEwdxgaGxMgjB0UJSIzMUCfDhYnKCQzQVkrLC0lNjc5M1FvHTVFVWFxgZJJTUlaNEdKQldaXV/9oADA
MBAAIRAxEAPwCfwCICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICIC
ICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICIC
ICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICICLpcgyTHcSqZd9lV9S4zR</file>
<fileName>d0e17276-b665-48f4-8fce-82fb443abd4d.pdf</fileName>
<okLabelStatus>ERROR</okLabelStatus>
</vehicleHistoryReport>
</return>
</ns2:requestOdometerReadingStatusResponse>
</soap:Body>
</soap:Envelope>
Example 2: Odometer Reading status without issues
<soap:Body>
<ns2: requestOdometerReadingStatusResponse
xmlns:ns2=”http://professionals.webservices.carpass. … .be/ ">
<return>
<status>OK</status>
<vin>VNWS0000000005259</vin>
</return>
</ns2: requestOdometerReadingStatusResponse >
</soap:Body>
</soap:Envelope>

Example 3: With issues
<soap:Body>
xmlns:ns2=”https://professionals.webservices.carpass. ... .be ">
<return>
<status>OK</status>
<vin>VNWS0000000005259</vin>
<issues>
<issueType>208</issueType>
<description>Le kilométrage est un nombre arrondi, évitez d’arrondir les
kilométrages.</description>
<issueId>8850</issueId>
</issues>
</return>
</soap:Body>
</soap:Envelope>
Example 4: With issue that can’t be correct, without Issue ID
<soap:Body>
xmlns:ns2=”https://professionals.webservices.carpass. ... .be ">
<return>
<status>OK</status>
<vin>VNWS0000000005259</vin>
<issues>
<issueType>150</issueType>
<description>Double Observation</description>
</issues>
</return>
</soap:Body>
</soap:Envelope>
Example 5: A correction of a Vehicle history request
POST http://ws-professionals.car-pass.be/carpass-web-services-professional/WSCarPassPro2?wsdl
SOAPAction: ””
Content-Length: 848

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:prof="

https://professionals.webservices.carpass. ... .be /">
<soapenv:Header/>
<soapenv:Body>
<request>
<correction>true</correction>
<vin>VNWS0000000005250</vin>
</request>
</soapenv:Body>
</soapenv:Envelope>

5.3 Manual Correction procedure
This procedure is deprecated. In 2021 the possibility will be given to ask Car-Pass to correct an issue 129 via
electronic way. First the website, later via webservices.
To avoid fraudulent behavior, an input can only be corrected once. If the correction generates again one or
more issues and the user realizes he has made an error twice, he will have to fill in a signed correction form
and mail it to Car-Pass. After evaluation if the correction is justified, Car-Pass will rectify the erroneous data.
When an Issue must be corrected manually a correction PDF must be send to Car-Pass.
See an example and the description of the correction PDF below. This PDF can be downloaded on the public
website for professionals. Ideally this pdf is automatically generated and filled in by the DMS.
The following issues and issue types don’t need to be filled in because they can’t be corrected: Type 125, 126,
127, 128, 130, 150, 250
Note that the blue fields contain the original data, the white fields contain the correction data.
The following fields can be provided on the correction PDF
field description mandatory

User code (gebruikerscode – See dictionary 
Code d’utilisateur)
Enterprise (bedrijfsnaam – The company name of the user 
Nom de la société)
Issue ID (Issue ID - N° de The Issue number that is returned to the professional 
problème)
Type (type) The Issue type code that is returned to the professional 
together with the type 129. The latter doesn’t need to be
filled in E.g. 001
VIN (Chassisnummer – N° de 
châssis)
Odometer Reading value 
Observation Date (datum 
werken – Date des travaux)
Odometer replaced (Werken Has to be checked when Odometer has been replaced 
aan km-teller – Travaux au or repaired.
compteur)
Send date (datum van The date when the correction PDF is sent to Car-Pass 
verzending – Date d’envoi)
Name (naam - nom) The name of the person who also signed the document. 
This must be an authorised person of the enterprise or
establishment.
Title (functie - fonction) The title of the person whose name is filled in the name 
field
Signature (handtekening) A manually written signature of the authorised person 
whose name is filled in the name field

6 Annexes

6.1 Issue List
Code Severity Nederlands
001 Alert Kilometerstand lager dan laatste.
110 Error Ongeldige kilometerstand
120 Error Onbekende of inactieve onderneming (legally responsible Entreprise )
121 Error Onbekende gebruikerscode
122 Error "Type of data" niet toegelaten voor deze gebruikerscode
123 Error U heeft reeds een km-stand geleverd voor deze wagen op deze datum– Gegevens
worden verworpen, niet corrigeerbaar
124 Error Chassisnummer niet uniek. Specifieer ook datum 1ste inschrijving
125 Error Veld issue-id (probleemnummer) is niet ingevuld - de correctie werd verworpen, niet
corrigeerbaar
127 Error Issue-id niet bekend in de database – Gegevens worden verworpen, niet corrigeerbaar
128 Error Issue is reeds opgelost of verbetertermijn verstreken– Gegevens worden verworpen,
niet corrigeerbaar
129 Error Deze issue kan enkel manueel opgelost worden
130 Error Issue kan enkel opgelost worden door de gebruiker die de originele km-stand heeft
aangeleverd – Gegevens worden verworpen, niet corrigeerbaar
131 Error Voertuig onbekend in de Car-Pass database
134 Error Usercode matcht niet met de onderneming (legally responsible)
144 Error De requestId is niet uniek
146 Error User en Sender zijn niet actief
147 Error De datum der werken is ouder dan 3 jaar
Error U hebt deze gegevens reeds meegedeeld. – Gegevens worden verworpen, niet
150 corrigeerbaar
180 Error U kan enkel de datum van vandaag opgeven
203 Warning Datum opname ligt te ver in het verleden.
205 Warning Kilometerstand bestaat uit meer cijfers dan de teller van het voertuig
206 Warning Voertuig staat geregistreerd als wrak
207 Error Formaat chassisnummer is ongeldig
208 Warning De kilometerstand is een afgerond getal.
209 Warning Kilometerstand veel hoger dan verwacht
210 Warning Kleine anomalie (tellerstand is beperkt lager dan de vorige)
230 Warning Een geldige Car-Pass bestaat reeds

242 Error Organisatie niet toegelaten om voertuighistoriek aan te vragen
250 Error Sender code is inactief – Issue niet corrigeerbaar
251 Error Gebruikerscode is inactief – Issue niet corrigeerbaar
704 Error Datum eerste ingebruikname niet gedefinieerd (alleen voor vin’s < 17)
Code Severity Français

001 Alert Kilométrage inférieur au précédent
110 Error Kilométrage invalide
120 Error Entreprise (légalement responsable) inconnue ou inactive
121 Error Code utilisateur inconnu
122 Error Type de données non-autorisé pour cet utilisateur
123 Error Vous avez déjà fourni un kilométrage pour ce véhicule à cette même date - Les
données sont rejetées, non corrigeable

124 Error Le numéro de châssis n'est pas unique. Spécifiez aussi le date de première
immatriculation
125 Error Numéro du problème manquant - la correction a été rejetée, non corrigeable
127 Error Numéro du problème inconnu - Les données sont rejetées, non corrigeable
128 Error Problème déjà résolu ou le délai pour le résoudre est expiré - Les données sont
rejetées, non corrigeable
129 Error Ce problème ne peut être corrigé que manuellement
130 Error Le problème ne peut être résolu que par l'utilisateur qui a fourni le kilométrage
original. - Les données sont rejetées, non corrigeable
131 Error Véhicule inconnu dans la base de données de Car-Pass
134 Error Le code utilisateur n'appartient pas à cette entreprise (légalement responsable)
144 Error L'identifiant de la requête n'est pas unique
146 Error L'utilisateur et l'expéditeur sont inactifs
147 Error La date des travaux est plus ancienne que 3 ans
Error Vous nous avez déjà communiqué ces données. - Les données sont rejetées, non
150 corrigeable
180 Error Vous pouvez uniquement préciser la date d'aujourd'hui
203 Warning La date d'entrée est trop ancienne.
205 Warning Le kilométrage compte plus de chiffres que le compteur du véhicule
206 Warning Le véhicule est enregistré comme une épave
207 Error Le format de numéro de châssis est invalide
208 Warning Le kilométrage est un nombre arrondi
209 Warning Le kilométrage est plus élevé que la normale
210 Warning Petite anomalie (Le kilométrage est inférieur au précédent)
230 Warning Un certificat Car-Pass valide existe déjà

242 Error Organisation n'est pas autorisée à consulter l'historique kilométrique
250 Error Le code d'expéditeur est inactif - Les données sont rejetées, non corrigeable
251 Error Le code d'utilisateur est inactif - Les données sont rejetées, non corrigeable
704 Error Date de première mise en circulation non-définie
Code Severity Deutsch

001 Alert Kilometerstand niedriger als vorheriger.
110 Error Ungültiger Kilometerstand
120 Error Das Unternehmen is unbekannt oder nicht aktiv
121 Error Benutzercode unbekannt
122 Error "Type of data" für die betreffende Person nicht zulässig
123 Error Sie haben bereits an diesem Datum einen Kilometerstand für dieses Fahrzeug
gemeldet. - Die Daten wurden abgelehnt, unkorrigierbar
124 Error Die Fahrgestellnummer ist nicht einmalig. Geben Sie auch das Erstanmeldungsdatum
ein.
125 Error Fehlende Problemnummer - Die Berichtigung wurde abgelehnt, unkorrigierbar
127 Error Unbekannte Problemnummer- Die Daten wurden abgelehnt, unkorrigierbar
128 Error Problem bereits gelöst oder Lösungsfrist abgelaufen - Die Daten wurden abgelehnt,
unkorrigierbar
129 Error Dieses Problem kann nur manuell per Korekturantrag gelöst werden.
130 Error Das Problem kann nur von der Person gelöst werden, die den anfänglichen
Kilometerstand eingegeben hat. - Die Daten wurden abgelehnt, unkorrigierbar
131 Error Fahrzeug unbekannt in der Datenbank von Car-Pass

Die Kombination Unternehmensnummer/Benutzercode ist ungültig.
134 Error
- Die Daten wurden abgelehnt, unkorrigierbar
144 Error Der requestId ist nicht einzigartig
146 Error Entered and Sender organisation are not active
147 Error Das Aufnahmedatum ist älter als 3 Jahre
Error Sie versehen diese Informationen bereits. - Die Daten wurden abgelehnt,
150 unkorrigierbar
180 Error Sie können nur das heutige Datum angeben
203 Warning Das Aufnahmedatum liegt zu weit zurück.
205 Warning Der Kilometerstand umfasst mehr Ziffern als der Kilometerzähler des Fahrzeugs
206 Warning Das Fahrzeug ist als Wrack eingetragen
207 Error Das Format der Fahrgestellnummer ist ungültig
208 Warning Der Kilometerstand ist eine abgerundete Zahl
209 Warning Der Kilometerstand ist höher als der Normalwert
Dieser Kilometerstand ist niedriger als einer der früheren Einträge für dieses Fahrzeug.
210 Warning
Daher wird dieser Kilometerstand nicht in das Car-Pass-Zertifikat aufgenommen.
230 Warning Es besteht bereits ein gültiges Car-Pass-Zertifikat
Error Es ist diesem Unternehmen nicht zugelassen, um die Fahrzeugvorgeschichte
242 anzufordern
250 Error Absendercode ist inaktiv - Die Daten wurden abgelehnt, unkorrigierbar
251 Error Benutzercode ist inaktiv - Die Daten wurden abgelehnt, unkorrigierbar
704 Error Datum Erstinbetriebnahme nicht definiert

6.2 Issues that cannot be corrected, (automatically closed).
- Type 125: Issue_Id was not provided - The correction was rejected
- Type 127: Unknown issue-id (in the db) - Data is rejected
- Type 128: Issue-id is already solved or term to correct an issue is passed (90d) - Data is rejected
- Type 130: This problem can only be solved by the user who has delivered the original odometer
reading - Data is rejected
- Type 150: you have already provided the odometer reading - Data is rejected
- Type 250: Sender-id Inactive
- Type 251: User-id Inactive
- Type123: Same day other odometer reading - Data is rejected

6.3 Good practices – Car-Pass approved DMS
Car-Pass attaches the utmost importance to the quality of the data communicated by the enterprises in the
car sector. After all, any errors will later end up on the Car-Pass certificate for the vehicle and will cast doubt
on the correct odometer reading with a potential buyer. In the worst case, this could result in a sale falling
through.
Correcting errors is a difficult task, both for Car-Pass and for the enterprise that has communicated the
incorrect odometer reading. Prevention is therefore better than cure. In practice, it appears that many errors
can be avoided at the source if the software used by the enterprise is based on a sound design. That is why
Car-Pass has set a number of criteria that DMS software must meet in order to guide the user as much as
possible when transferring odometer readings, thereby helping the avoidance of errors. If the software meets
these requirements, it may carry the "Car-Pass approved DMS" label. Car-Pass has approved the following
software.
Transfer of the data

The DMS, must, as required by law, send the data to Car-Pass when the vehicle is still in the enterprise,
regardless of the final closing of the file or billing.
The developer must be able to demonstrate that the data is transmitted in one of the following ways:
a) Automatic transfer (automatically after entering data on, for example, a work order and without the
user having to explicitly press a button).
b) Manually, with installation of the necessary guarantees (warnings, reminders, etc.) that the data
is being sent before the vehicle file is closed or before the vehicle leaves the repairshop.
Checks to ensure correct transfer and subsequent receipt by Car-Pass

The DMS system must contain the necessary checks to verify whether the data has actually been sent to Car-
Pass and whether Car-Pass has received it properly.
1) In the first phase of the web service, Car-Pass sends back a requestID.
Is this requestID captured and stored, so that this requestID can be used even after restarting the
PC/server?
2) Before launching the requestOdometerReadingStatus, is there a delay time of 1 seconds as
minimum?
3) Is there an adequate strategy to retrieve the data when the
requestOdometerReadingStatusResponse is equal to 'ONGOING' (see § 3.4)?
4) Has the requestOdometerReadingStatusResponse been captured so that any issues can be
corrected? (see §4 Corrections)
5) If, for technical reasons, the data cannot be sent for a certain period of time, it must be saved and
the user must receive a warning. After the problems have been solved, the user and/or the DMS
vendor should be able to send all overdue data with the correct date of work.
The DMS system displays the error messages with the correct problem number, issue type
and description
See list with issues under § 6.1
In the DMS system, the outstanding problems must be visible, showing the correct problem number, the error
code (issue type) and the description of the problem.

The DMS system allows issues to be corrected
See § 5.2.1.2
The system allows corrections to be made. Under the term corrections is meant:
1. Modifying the VIN, mileage or date by using the correct issue_ID and dataTypeId=120 of 121.
2. Confirming the data that caused the issue as correct by using the correct issue_ID and
dataTypeId=080.
3. Closing open issues without any modification by using the correct issue_ID and dataTypeId=080.
If the input data has caused more than one issue, then all related issues will be closed when one of them is
corrected. If the garage sends a correction to Car-Pass, the company's local database must be updated
accordingly. The feedback on this correction will be loaded correctly.
The non-correctable issue types (see § 6.2) will be shown but must be closed automatically.
Corrections with dataTypeId=120 or 121 where the same data is repeated as the original data are not allowed.
The DMS shows all issues and which ones still need to be corrected.
Built-in checks to avoid system-based errors

The DMS system carries out a check to ensure if the entered kilometer reading is possible (precheck of data
in the own system)
a. The DMS system gives a warning if the kilometre reading that is entered is lower than the
previous odometer reading in the garage database (local issue 001)
b. The DMS system gives a warning if the kilometre reading that is entered is excessively high
compared to the previous odometer reading in the garage database.(local issue 209)
c. The DMS system gives a warning if the kilometre reading that is entered is the same as a
previous odometer reading in the garage database
d. The DMS system gives a warning system if the date for the works is in the future
e. The DMS system gives a warning if the date for the garage works is in the past.
f. The input field for the mileage may only allow numbers and no special characters nor blanks.
g. When the data has already been processed by Car-Pass, the DMS prevents the same source
from sending the identical data (same VIN, km and date) multiple times. (DMS should
therefore not cause an issue_type 150)
Checks to ensure the correct data type

a. Transfer of the odometer reading: code 120 (or 121)
b. Transfer of the correction: code 120 (or 121) + issue_Id
c. Closing the problem without correction: code 080
d. If the garage repairs or replaces the odometer, this must be reported to Car-Pass via code 121
Check to ensure that 17 characters are entered for VIN

If a VIN is entered with less than 17 characters, the user receives a warning. As the VIN of oldtimers often
contain less than 17 characters, it should nevertheless be possible to send the data to Car-Pass.
When a VIN with more than 17 characters is entered, the user receives an error message. It should not be
possible to send the data to Car-Pass.
An empty or impossible chassis number (000000000000000000) is not allowed. Only alphanumeric values
are allowed.

The system makes it possible to exclude operations that are not mandatory to report (e.g. till
sales, etc.) and certain categories of vehicles from being transferred to CAR-PASS (trucks,
foreign number plates, etc.)
The user must have the option of excluding these operations/vehicles from being transferred to Car-Pass.
The system transfers the correct combination of date of works/odometer reading

The system links the correct date to the correct kilometer reading, i.e. the date when the vehicle was present
in the repair shop and the odometer value was recorded.
Possible errors that give rise to failure on this criterion (not exhaustive list):
• Using the invoice date
• Using the odometer reading at the date of the expertise and link it to the date of repair
• Using the date the appointment was made
• Re-sending the odometer reading when creating a credit note / re-invoicing
• Claims under guarantee: cut-off date
• Etc.
The user must be able to check his user codes and password
Test: The DMS system must have a screen showing the contact details that were entered at the time of
activating the Car-Pass user account. These are at the minimum the following:
- The user code
- The user's VAT number (enterprise code)
- The password
- The email address
- Optionally: telephone number of the Car-Pass helpdesk and link to the contact form.
If the enterprise changes its password and/or user code locally in the DMS system, at least one warning must
appear warning that it must also be changed on the Car-Pass website.
Vehicle History Request (optional)

The DMS allows the vehicle history to be consulted in accordance with § 5.2.1.3 and the PublicUrl to be saved
and associated issues to be processed. The DMS system opens the pdf document that was sent and allows
to print the vehicle history.
Automatic or manual forwarding after ANY entry of the odometer reading of the vehicle for sale. As long as
this odometer reading is not adjusted, no new VHR may be requested by the DMS.
It is not intended that the requests are stored locally and later queried in batch.
In order to create a VHR, Car-Pass has to contact several third parties (e.g. car manufacturers, DIV,...). Car-
Pass waits a maximum of 1 minute for a response. Meanwhile the response status remains ONGOING. Thus,
the DMS program may not repeat the RequestOdometerReadingStatus more frequently than 1 time per 10
seconds as long as the response status is ONGOING and should not abort the
RequestOdometerReadingStatus query within 90 seconds.

Inflow Process Specification: Confidential

Uploaded by

Copyright:

Available Formats

You might also like

Inflow Process Specification: Confidential

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Inflow Process Specification: Confidential

Uploaded by

Copyright:

Available Formats

Inflow Process Specification

version 9.1.2 – 10/09/2021

Version Date Changes

CAR-PASS Inflow Process Specification 9.1.1 – Page 1 of 38

9.1 17/02/2021 Paragraph 3.4 - Comments added for ‘ONGOING’ problem

CAR-PASS Inflow Process Specification 9.1.1 – Page 2 of 38

CAR-PASS Inflow Process Specification 9.1.1 – Page 3 of 38

CAR-PASS Inflow Process Specification 9.1.1 – Page 4 of 38

To explain some terms an example enterprise is given:

In the used example this can be

Internal code (optional) Can be:

CAR-PASS Inflow Process Specification 9.1.1 – Page 5 of 38

• The first covers the sending of an odometer reading.

CAR-PASS Inflow Process Specification 9.1.1 – Page 6 of 38

CAR-PASS Inflow Process Specification 9.1.1 – Page 7 of 38

CAR-PASS Inflow Process Specification 9.1.1 – Page 8 of 38

3.3.1 Categories of issues

CAR-PASS Inflow Process Specification 9.1.1 – Page 9 of 38

issue type data stored correction possible

It is possible that one odometer reading generates different issues.

3.3.2 How to respond to an issue?

CAR-PASS Inflow Process Specification 9.1.1 – Page 10 of 38

CAR-PASS Inflow Process Specification 9.1.1 – Page 11 of 38

CAR-PASS Inflow Process Specification 9.1.1 – Page 12 of 38

▪ Use the Car-Pass website

▪ Integrate the webservices in a third party application.

CAR-PASS Inflow Process Specification 9.1.1 – Page 13 of 38

CAR-PASS Inflow Process Specification 9.1.1 – Page 14 of 38

The Authorization header is constructed as follows:

(*) the production url is: https://ws-professionals.car-pass.be/carpass-web-services-

See the necessary header in the example below:

CAR-PASS Inflow Process Specification 9.1.1 – Page 15 of 38

Only TLSv1.2 and TLSv1.3 is supported

CAR-PASS Inflow Process Specification 9.1.1 – Page 16 of 38

We recommend to implement a minimum delay time of minimum 2 seconds between the

CAR-PASS Inflow Process Specification 9.1.1 – Page 17 of 38

CAR-PASS Inflow Process Specification 9.1.1 – Page 18 of 38

5.2.1 Register Odometer Reading

This request can be used for 3 purposes:

5.2.1.1 Provide new Odometer Readings

CAR-PASS Inflow Process Specification 9.1.1 – Page 19 of 38

See a full example below:

5.2.1.2 Correct Issues

See a full example below:

CAR-PASS Inflow Process Specification 9.1.1 – Page 20 of 38

5.2.1.3 Request Vehicle History Report

Use the rules from 5.2.1except for:

CAR-PASS Inflow Process Specification 9.1.1 – Page 21 of 38

See a full example below:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:prof="

5.2.2 Register Request Status Response

The following elements are contained in the odometer status response:

CAR-PASS Inflow Process Specification 9.1.1 – Page 22 of 38

See a full example below:

5.2.3 Request Odometer Reading Status

The requestId is the returned id, described in paragraph 5.2.2.

See a full example below: