RE: [ubl-comment] VS: Deadline for submission of changes for UBL 2.2 Pre-Award is approaching (May 31st)

["Duvekot, Kees" <kduvekot@Wehkamp.nl>]

If you look at this picture that was created as part of the ApplicationResponse within PEPPOL:

 

 

Then the Messagelevel Response is the UBL ApplicationResponse. In that document you can tell that you have received the document, that you could understand it (functional correct) and that you will “process” it.

In the Business Level response you can then tell the result of that processing if there is a business need to do that (like in a OrderResponse)

 

Are we sure you are not mixing the MessageLevel Response errors with the Business Level responses?

If an certificate is not valid .. is that a Business Level response or a MessageLevel response in which you tell that you are NOT going to process the received document?

 

If I look at that TenderReceipt document (I use the following URL for easy looking at UBL documents: http://www.datypic.com/sc/ubl21/s-UBL-TenderReceipt-2.1.xsd.html ) then I see a lot of overlap with the ApplicationResponse but you can not say you are not going to do anything with the document.

 

So I think a proper Business Level Response document like “TenderResponse” document looks more like something you need as a BusinessLevel Response to the “Tender” document. In there you can see that you have registered the tender (or not and why not) or what the status is of the tender, updates to it that are initiated by a receiver of the Tender etc etc ..

 

So you have a business process much like the Order(Change) -> OrderResponse process .. and when the Tender is awarded you send out the correct documents (AwardNotification/UnawardedNotification) just like you send out a DespatchAdvice on an order J

 

Kees D.

 

 

Van: Tim McGrath [mailto:tim.mcgrath@documentengineeringservices.com]
Verzonden: vrijdag 13 mei 2016 9:44
Aan: Ole Ellerbæk Madsen <olema@digst.dk>
CC: ubl-comment@lists.oasis-open.org; Oriol Bausà Peris <oriol@invinet.org>; Holman Ken <gkholman@CraneSoftwrights.com>
Onderwerp: Re: [ubl-comment] VS: Deadline for submission of changes for UBL 2.2 Pre-Award is approaching (May 31st)

 

Could we use ApplicationResponse for this?

 

 

On 13 May 2016, at 15:08, Ole Ellerbæk Madsen <olema@digst.dk> wrote:

 

Translated by Google from Norwegian:

 

We have had a discussion about which messages should be able to handle information when something goes wrong in an electronic filing.
Trdm045: http://docs.oasis-open.org/ubl/prd2-UBL-2.1/xsd/maindoc/UBL-TenderReceipt-2.1.xsd
is basically a message which is located on the business layer and can in theory be sent several times and may be used.
 
My question is about the feedback to UBL 2.2 might include such additions to this trdm?
 
What we may need is three new fields:
1. Treatment Status (OK, Error, Warning) (S0001 / S0002 / S0003)
2. Field of reason code example describes:
a) The offer came too late (T0001).
b) The offer can not be read (T0002)
c) certificate is not valid (T0003)
d) There is no agreement between the sender's identity and certificate (T0004)
e) The missing documents (T0005)
f) etc. (T ...).
3. Text field to be read by a human showing error code.

 

Fra: Mærøe, Jan André [mailto:jan.andre.maroe@difi.no] 
Sendt: 13. maj 2016 08:45
Til: Ole Ellerbæk Madsen
Cc: Cook, Steinar Overbeck; 'siw.meckelborg@edisys.no'
Emne: SV: Deadline for submission of changes for UBL 2.2 Pre-Award is approaching (May 31st)

 

Hei Ole

 

Vi har hatt en diskusjon om hvilke meldinger som skal kunne håndtere informasjon når noe går galt i en elektronisk innlevering.

Trdm045: http://docs.oasis-open.org/ubl/prd2-UBL-2.1/xsd/maindoc/UBL-TenderReceipt-2.1.xsd

er i utgangspunktet en melding som ligger på businesslaget og kan i teorien sendes flere ganger og kan eventuelt benyttes.

 

Mitt spørsmål er om den tilbakemeldingen til UBL 2.2 kan inneholde slike tillegg til denne trdm?

 

Det vi eventuelt trenger er 3 nye felt:

1. Behandlingsstatus (Ok, Feil, Advarsel) (S0001/S0002/S0003)
2. Felt for årsakskode som eksempel beskriver:

a)       Tilbudet kom for sent (T0001).

b)       Tilbudet kan ikke leses (T0002)

c)       Sertifikatet er ikke gyldig (T0003)

d)       Det er ikke overensstemmelse mellom avsenders identitet og sertifikatet (T0004)

e)       Det mangler dokumenter (T0005)

f)        osv. (T….)

3. Tekstfelt som skal leses av et menneske som viser feilmeldingskoden.

 

BII trdm:

<image001.png>

 

Fra: Ole Ellerbæk Madsen [mailto:olema@digst.dk] 
Sendt: 12. mai 2016 16:40
Til: Mærøe, Jan André <jan.andre.maroe@difi.no>; Cook, Steinar Overbeck <SteinarOverbeck.Cook@difi.no>
Emne: VS: Deadline for submission of changes for UBL 2.2 Pre-Award is approaching (May 31st)

 

Hi Steinar and Jan

 

Do DIFI have input to UBL 2.2 please send it to me as well.

 

Best Regards

Ole

 

 

 

Fra: ubl-pre-award@lists.oasis-open.org [mailto:ubl-pre-award@lists.oasis-open.org] På vegne af Ole Ellerbæk Madsen
Sendt: 12. maj 2016 11:40
Til: ubl-pre-award@lists.oasis-open.org
Emne: [ubl-pre-award] Deadline for submission of changes for UBL 2.2 Pre-Award is approaching (May 31st)

 

 

All,

 

As you might be aware the UBL TC is aiming to release a new version of UBL every 3 years as stated in the UBL Maintenance Governance Procedures [1]

As the last release of  the UBL  standard (version 2.1) was published in late 2013 and the next release is targeted for late 2016 publication.

 

Given the timelines that are needed to meet this targeted publication date, the deadline for submitting new additions to the UBL standard is set for May 31^st2016.

This email is a reminder for this deadline.

 

If you have any new addition request to UBL related to Pre-Award then please use the following procedure for submitting them to the UBL Pre-Award Subcommittee.

https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ubl

 

 

Ole Madsen

Chair UBL Pre-Award Procurement Subcommittee

 

[1] http://docs.oasis-open.org/ubl/UBL-Governance/v1.0/cn01/UBL-Governance-v1.0-cn01.html

 

 

Venlig hilsen/Best Regards

Ole Madsen

T   +45 4090 6064
M  +45 2331 3133
E  olema@digst.dk

 

Finansministeriet

Digitaliseringsstyrelsen
Landgreven 4, Postboks 2193
1017 København K

Ministry of Finance

Agency for Digitisation
Landgreven 4, Postboks 2193
DK-1017 Copenhagen K

T   +45 3392 8000

 

-----------------

Regards 

Tim McGrath
tim.mcgrath@documentengineeringservices.com

Fremantle, Western Australia 6160

AUSTRALIA

Phone: +61438352228

Skype: t.mcgrath