OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

I agree with the comments from Tim. I also think the Application Response should be used in these situations.

Best regards
Oriol

El 14 maig 2016, a les 4:26, Tim McGrath <tim.mcgrath@documentengineeringservices.com> va escriure:

My apologies I am moving this to the UBL list where it belongs….

Looking at Ole's examples then I suspect this is probably not the Business Level Response that Kees is suggesting.  The BLR would be the Tender Receipt document that recognised the Tender has been accepted and lodged formally.

This is a requirement to address the technical part of the document delivery.  But it is more than the PEPPOL MLR which may be constrained to only message exchange acknowledgements (that the submission has been delivered (or not) to the party responsible) . In fact I think the MLR in PEPPOL only acknowledges between Access Point providers so it is not an end-to-end acknowledgement for the businesses involved.

I agree with Kees that an MLR document should tell the sending business that the receiving business has received the document, that they could understand it (functional correct) and that they will “process” it.  And that is what the Application Response was design for.

Based on Ole's examples the requirement seems to be for acknowledging that a submission has (or has not) met the technical requirements of a valid submission package.  In other words, whether it has been recognised as a legitimate submission package or it is not able to be lodged (processed) because of faults in the submission package.  It is not a decision based on understanding the content of the submission package. So it is an MLR (Application Response) but with more status and reason codes than the PEPPOL subset and in this case would be exchanged between a Tender submitter and a Tendering organization.

So in a PEPPOL environment (4 corner model) the “Messaging System” is two layers.  The lower AP to AP layer in the current PEPPOL MLR and the higher layer would be a (to be defined profile) for a Business to Business MLR.  

In which case we don’t need a new document type to deal with this.  Both can use the Application Response - but with different profiles.





Begin forwarded message:

From: "Duvekot, Kees" <kduvekot@Wehkamp.nl>
Subject: RE: [ubl-comment] VS: Deadline for submission of changes for UBL 2.2 Pre-Award is approaching (May 31st)
Date: 13 May 2016 at 21:56:33 AWST
To: "'Tim McGrath'" <tim.mcgrath@documentengineeringservices.com>, Ole Ellerbæk Madsen <olema@digst.dk>

If you look at this picture that was created as part of the ApplicationResponse within PEPPOL:
 
<image001.png>
 
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.
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….)
  1. 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 31st2016.
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.
 
 
Ole Madsen
Chair UBL Pre-Award Procurement Subcommittee
 
 
 

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 
Fremantle, Western Australia 6160
AUSTRALIA
Phone: +61438352228
Skype: t.mcgrath

-----------------
Regards 
Fremantle, Western Australia 6160
AUSTRALIA
Phone: +61438352228
Skype: t.mcgrath




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]