[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-comment] VS: Deadline for submission of changes for UBL 2.2 Pre-Award is approaching (May 31st)
Please do not use the comment list for discussion. I am recording this in the comment list so that people reading the comment list understand that it is a depository of comments only, not a place for internal discussions. It is in scope to use the comment list to solicit feedback from the originator, as they still have to use the comment list to communicate. Internal discussions belong on the TC list, where you can cite the original post to the comment list. . . . . . . . . Ken At 2016-05-13 13:56 +0000, Duvekot, Kees wrote:
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>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 <<mailto:olema@digst.dk>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>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>mailto:jan.andre.maroe@difi.no] Sendt: 13. maj 2016 08:45 Til: Ole Ellerbæk Madsen Cc: Cook, Steinar Overbeck; '<mailto:siw.meckelborg@edisys.no>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>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: Behandlingsstatus (Ok, Feil, Advarsel) (S0001/S0002/S0003) 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?.) Tekstfelt som skal leses av et menneske som viser feilmeldingskoden. BII trdm: <image001.png> Fra: Ole Ellerbæk Madsen [<mailto:olema@digst.dk>mailto:olema@digst.dk] Sendt: 12. mai 2016 16:40 Til: Mærøe, Jan André <<mailto:jan.andre.maroe@difi.no>jan.andre.maroe@difi.no>; Cook, Steinar Overbeck <<mailto:SteinarOverbeck.Cook@difi.no>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: <mailto:ubl-pre-award@lists.oasis-open.org>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: <mailto:ubl-pre-award@lists.oasis-open.org>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. <https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ubl>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>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 <blocked::mailto:olema@digst.dk>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 <mailto:tim.mcgrath@documentengineeringservices.com>tim.mcgrath@documentengineeringservices.com Fremantle, Western Australia 6160 AUSTRALIA Phone: +61438352228 Skype: t.mcgrath
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
-- Check our site for free XML, XSLT, XSL-FO and UBL developer resources | Streaming hands-on XSLT/XPath 2 training @US$45: http://goo.gl/Dd9qBK | Crane Softwrights Ltd. _ _ _ _ _ _ http://www.CraneSoftwrights.com/o/ | G Ken Holman _ _ _ _ _ _ _ _ _ _ mailto:gkholman@CraneSoftwrights.com | Google+ blog _ _ _ _ _ http://plus.google.com/+GKenHolman-Crane/posts | Legal business disclaimers: _ _ http://www.CraneSoftwrights.com/legal |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]