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

[JAVEST by Roberto Cisternino <roberto.cisternino@javest.com>]

Hello Kees,

The "Profile Execution ID" is in some way supporting the connection between different transactions exchanged within a given business profile.
So if the DespatchAdvice document is sent with different transactions (as update) you can keep their relationship by using the Profile Execution ID.

Of course you can clearly specify the DocumentStatusCode (e.g. Revised - see genericode list).

This is a UBL 2.1 feature we have designed to support the profile execution tracking which is a traversal thing possibly across different documents.

I think this is a good solution to your requirement.

Best regards

Roberto Cisternino
UBL ITLSC co-chair

Il 23/12/2014 21.17, Duvekot, Kees ha scritto:

Stephen,

Thanks for digging this up .... this was discussed more then 10 years ago also :-)

So I'm on the right track with actually using the DocumentStatusCode .. but the DocumentReference is "missing" in this specific case.
So a work around could be to use the "AdditionalDocumentReference" as a stand-in ...

Not sure of anybody has created a EDIFACT DESADV to UBL DespatchAdvice translator that is also using updates? There this should also been identified as an issue....

And the followup question:  should we establish a standard UBL way of updating documents  ... any UBL document ...?
(so that could be included in the next release of UBL)

Kees

________________________________________
Van: Stephen D Green [stephengreenubl@gmail.com]
Verzonden: dinsdag 23 december 2014 15:22
Aan: Peter Borresen
CC: Duvekot, Kees; UBL-Dev
Onderwerp: Re: [ubl-dev] DespatchAdvice and updates ...

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

---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org



-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2015.0.5577 / Database dei virus: 4257/8792 -  Data di rilascio: 23/12/2014

--
Best regards

Roberto Cisternino

JAVEST By Roberto Cisternino

P.IVA: IT01290640117
C.F.: CSTRRT68M06E463H

Document Engineering Services, Director Associate
OASIS Member
TESISQUARE Partner

Mobile: +39 328 2148123
Skype: roberto.cisternino.ubl-itlsc