Open monkeypants opened 8 years ago
Please
{
"UBLVersionID": "2.1",
"CustomizationID": "urn:www.digitalbusinesscouncil.com.au:dbc:invoicing:documents:core invoice:xsd::core invoice 1##urn:www.digitalbusinesscouncil.com.au:dbc:einvoicing:process:einvoicing01:ver1.0",
"ProfileID":"urn:www.digitalbusinesscouncil.com.au:dbc:einvoicing:ver1.0",
"ID": "B65830",
"IssueDate": "2005-11-20",
"SenderParty": {
"Party": {
"PartyIdentification": {
"ID": {
"schemeID": "ABN",
"schemeAgencyID": "0151",
"value": "63197439746"
} },
"PartyName": {
"Name": "Shared Services Centre"
} },
"ReceiverParty": {
"Party": {
"PartyIdentification": {
"ID": {
"schemeID": "ABN",
"schemeAgencyID": "0151",
"value": "34132141612"
} },
"PartyName": {
"Name": "Three Steps Pty Ltd"
} },
"DocumentResponse": {
"DocumentReference": {
"ID": "A00095678",
"IssueDate": "2005-11-20",
"DocumentTypeCode": "Invoice"
},
"Response": {
"ResponseCode": "BusinessReject",
"Description": "No supporting order or contract"
}
}
}
@onthebreeze , @monkeypants - I have made the above changes, Please review - https://swaggerhub.com/api/ausdigital/invoice/0.1
There are two kinds of semantic mismatch between the current /invoice/ swagger spec and the OASIS/UBL eInvoicing spec.
1) Superfluous verbs. Don't need GET, PUT and DELETE /invoice/ endpoints. GET makes sense (processing state metadata) but it's not in the spec (enhancement proposal? - see #6). 2) Missing ACK noun (/business_response/?). These should also be POSTed (it takes two to tango).
Both POSTs should probably return a GUID (for out of band status enquiry now, and possible future GET status/processing-metadata enquiry).
And, aren't there subtypes of invoice noun? should they have their own POST endpoints? I think it might be nicer to map validation rules to endpoints, but they could also be tested against payload types.