Re: [ubl-dev] DespatchAdvice and updates ...

[Stephen D Green <stephengreenubl@gmail.com>]

Hi All,

I think this one actually predates the OGC work and goes all the way
back to xCBL 3.5 and the first seven UBL document types

see https://www.oasis-open.org/committees/ubl/lcsc/0p70/ for the first
set of seven.

I had a look at the lists going back that far and came across, for
example, this email

https://lists.oasis-open.org/archives/ubl-lcsc/200310/msg00116.html

whose thread is

https://lists.oasis-open.org/archives/ubl-lcsc/200310/threads.html#00116

This reminded me we didn't try initially to model the changes to the
documents in a document-type-specific way (except for OrderChange
which actually came later) but instead had an approach which allowed
document status code (and optionally document reference) to be used to
change any document, perhaps along legacy-EDI lines (though I'm no
legacy-EDI expert). So if that isn't possible then really it could be
the original concept of the document status code which is either
defective or inadequate, I suggest.

Cheers

Steve
----
Stephen D Green


On 22 December 2014 at 15:34, Peter Borresen <plb@ebconnect.dk> wrote:
> Hi Kees
>
>
>
> I dont think this scenario currently is covered in UBL, or rather the
> despatch advice has not been designed for it. In the invoicing process we
> have the debitnote, but we don’t have anything similar in the fulfillment
> process. What we need is that something like “previous DespathAdvice
> document reference” and then an indicator that this document replaces
> another one?
>
>
>
> /Peter
>
>
>
> Fra: Duvekot, Kees [mailto:kduvekot@Wehkamp.nl]
> Sendt: 22. december 2014 14:55
> Til: 'Peter Borresen'; 'UBL-Dev'
> Emne: RE: [ubl-dev] DespatchAdvice and updates ...
>
>
>
> Peter,
>
>
>
> Not exactly …
>
> The situation that I’m describing is when a supplier has issued the
> DespatchAdvice .. but wants to update the information after it has been
> issued (for example add package identifiers that were not known when the
> initial DespatchAdvice was issued) or they find out that some items were not
> included in the shipment .. so they need to be removed. Etc etc
>
>
>
> So how can the supplier send updated DespatchAdvice information in UBL
> format …
>
>
>
> Kees
>
>
>
> Van: Peter Borresen [mailto:plb@ebConnect.dk]
> Verzonden: maandag 22 december 2014 14:27
> Aan: Duvekot, Kees; 'UBL-Dev'
> Onderwerp: SV: [ubl-dev] DespatchAdvice and updates ...
>
>
>
> Hi Kees
>
>
>
> This process as it was original defined by OGC that was putted into UBL was
> that the supplier sends a dispatch advice. The the customer sends back a
> receipt advice. Then in both direction there could be send a rectification
> advice. We just agreed in UBL 2.0 that this was to a to seldom used so we
> skiped the rectification advice.
>
>
>
> You can see the process here:
> http://ec.europa.eu/idabc/servlets/Doc6d70.pdf?id=22198
>
>
>
> Does this fit with the need you are describing?
>
>
>
> Best regards
>
>
>
> Peter
>
>
>
> Fra: Duvekot, Kees [mailto:kduvekot@Wehkamp.nl]
> Sendt: 22. december 2014 13:46
> Til: UBL-Dev
> Emne: [ubl-dev] DespatchAdvice and updates ...
>
>
>
> UBL Dev readers,
>
>
>
> I am getting a request to implement a method to be able to handle updates on
> DespatchAdvice documents.
>
> As far as I can see does UBL not really support this in the DespatchAdvice
> (there is no “DespatchAdviceDocumentReference” in the DespatchAdvice to
> reference to a previously sent DespatchAdvice)
>
>
>
> In UBL we only have a “cac:AdditionalDocumentReference” that could be used
> for this reference … but it is not a “named reference”
>
> When the DespatchAdvice document was designed .. was this subject discussed?
> And what would be the best practice to update DespatchAdvice documents?
>
>
>
>
>
> My position is that each UBL document should have it’s own unique
> (document)ID, so an update to a already send DespatchAdvice should have a
> new unique (document)ID.
>
> You could use the DespatchAdviceTypeCode to specify that this new document
> is an update/change to an already send DespatchAdvice but not sure if that
> is the correct place. Also because there is also a “DocumentStatusCode” that
> could be used in the header.
>
>
>
> There is also the “FulfilmentCancellation” document .. but that can only be
> used to cancel a whole document .. so that would mean two document from the
> seller (one FulfilmentCancellation and one new DespatchAdvice) which might
> put to much burden on the sender.
>
>
>
>
>
> If I look at the GS1 DESADV documentation:
>
> http://www.gs1.org/docs/gsmp/eancom/2012/print/ean02s4.pdf/desadv.pdf
>
>
>
> I see that on page 26 they describe an element called “Message Function
> Code”. In there you can specify information that you can use in relation to
> a previously send DespatchAdvice.
>
> If you use message function code to cancel, update or replace a GS1 DESADV
> you use the RFF element to specify which DESADV document you want to cancel,
> update or replace.
>
>
>
> So what is the UBL equivalent to this?
>
>
>
> So I’m looking for pointers on how to implement this in a “correct” way.
>
>
>
> Thanks,
>
>
>
> Kees Duvekot
>
>