Testing the web service
There are two ways to test the web service, but both require a valid USP web service user:
- Setting the test flag
Settingsof the SOAP message. As a result, only the first technical check is carried out and neither a good case nor the confirmation e-mail nor the call of the asynchronous web service callback can be tested. Read more
- By using a test endpoint, both good cases, e-mail confirmation and asynchronous callback can be tested. Read more
Note: Without a USP user the web service cannot be tested. There is also no test user for the USP. It can only be tested, and later submitted, with the personalised USP user.
Note to SoapUI users: in the settings of the request, the default settings for "Authentication Type" do not need to be changed and "Username" and "Password" must also remain empty. Only the data in the SOAP header is accepted!
The test flag offers the possibility to test the call of the web service without sending an invoice to the real system. It is similar to the test upload, but requires a USP user. The aim of the test flag is to check the use of the USP web service user and the coding of the invoice. In addition, the included invoice is also checked technically - as with the test upload. The list of errors or the success message is returned as a direct response. However, the web service callback cannot be tested with this test flag, as the invoice is never transmitted for content verification. If the test flag is set, no confirmation e-mail is sent.
To test the web service as close as possible to the productive solution, there is a separate web service endpoint for the e-Rechnung.gv.at test platform. This uses the same interfaces as the production (the same WSDL files), but offers the possibility of end-2-end testing.
1. A USP user - see these slides for details
2. A USP Webservice user - see also these slides. Make sure that the check mark is set at "e-Rechnung.gv.at Webservice (T)" - this is the test web service. The entry without "(T)" is the productive web service (see page 28 of the slides).
If the entry "e-Rechnung.gv.at Webservice (T)" is not visible, please send an e-mail to email@example.com so that we can arrange for activation.
Note: all existing activations work for both Webservice V1.2 and Webservice V2.0!
3a. For testing Webservice V2.0 (recommended) use this Webservice endpoint URL:
3b. For testing Webservice V1.2 use this Webservice endpoint URL:
4. Now a test request can be sent. The test flag (see above) can also be set here, but does not have to be. To test the asynchronous callback with an error case, the setup is sufficient up to here.
Testing a good case
The prerequisite for testing a good case is the existence of a purchase order in our system. We offer you a corresponding functionality for creating such dummy purchase orders, to which invoices can then be sent. This only works with the test endpoint and not on the productive e-Rechnung.gv.at site! All requirements of the test endpoint (see above) must be fulfilled.
- Create a SOAP client for erb-in-test-order-102.wsdl (last Update 2016-01-28 - added default endpoint). This Webservices does not require a USP user.
- Contact firstname.lastname@example.org by e-mail and ask for an API key, providing at least your company name. The received API key must be part of every service invocation.
- Invoke the Webservice client with the endpoint URL
https://test.erechnung.gv.at/tester/wstest100(no "-" in the URL!) - no USP user and no WebService Security is needed!
Method to invoke:
APIKey- see point 2. above
Currency- default value is 'Euro'
OrderLine(1-n times; order positions) - consisting of:
Description- Name of the article/the service - is mandatory
UnitNetPrice- Unit net price - is mandatory and must be ≥ 0
Unit- Unit of measure - default value is 'Stück' (German for "piece")
Quantity- Ordered quantity - default value is 1 - must be ≥ 0
TaxRate- VAT rate as a percentage - default value is 20 (for 20%)
Note: the net order sum (sum of
Quantity) may not exceed 1000 (thousand) (due to internal restrictions).
CreditorID- die supplier ID to be used for this order
OrderID- die purchase order number for this order
BuyerGroup- the buyer group (German "Einkäufergruppe") of this order
OrderPositionNumber(1-n times) - the order item number to be used per order item, in the same order as the order items were specified
Note: with this data the different forms of order reference (order number, purchasing group etc.) can be mapped. It is not absolutely necessary to send an order-related invoice.
- Send the invoice via web service to the test endpoint. Use the return values of 3. as reference data. If everything fits, you will receive a good case message - either by e-mail or via the asynchronous callback.
Note: with the return values from 3. also an invoice form can also be filled out or a manual upload can be performed on the e-Rechnung.gv.at test platform.