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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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


Subject: RE: [ubl-lcsc] [Analysis Team] Re: Revised Model diagram


Tim,

the idea of having unambiguous items makes a lot of sense with respect to the modeling of the message structure. For the message's XML instance however we tried so far to avoid every unnecessary overhead, especially on item and on schedule line level. In so far I would suggest to realize the unambigous items only as a schema type not as a tag name, e.g.

<DespatchAdvice>
	<Item> of type "DespatchAdviceItem"
	...
</DespatchAdvice>


<ReceiptAdvice>
	<Item> of type "ReceiptAdviceItem"
	...
</ReceiptAdvice>

The semantical relationship between the item and the corresponding "parent element" in the XML instance can already be identified by the hierarchical structure (e.g. "Item" is subelement of "DespatchAdvice" etc.).

Best regards,
Frank
>>>>>>>>>>>>>>>>>>
Frank Thome, Ph.D.
SCM Development, SAP Labs        Phone: +1 650-320-3174
3475 Deer Creek Road             Fax:     +1 650-320-3769
Palo Alto, CA 94304


>-----Original Message-----
>From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
>Sent: Friday, December 06, 2002 8:35 PM
>To: Michael Adcock
>Cc: ubl-lcsc@lists.oasis-open.org
>Subject: [ubl-lcsc] [Analysis Team] Re: Revised Model diagram
>
>
>I would like to propose a modification to the way we are dealing with 
>lines/items in  our model.
>
>Please consider something like the attached diagram.  It is an attempt 
>to reflect the dependency of properties (i.e 'items') rather than the 
>structure of traditional documents (ie 'lines').
>
>Basically, i think we should have a set of properties about 
>things when 
>they are ordered, transported and then charged/invoiced.  The 
>transportation properties can be refined into those dependant on the 
>sending (despatch) and the receiving (receipt).
>
>These structures then allow us to unambiguously reconcile 
>Invoiced Items 
>with Ordered Items, Ordered Items with Transported Items , etc...
>
>For example, our Despatch Advice can follow the path....
><DespatchAdvice>
>    <DespatchedItem>
>            <OrderItem>
>                <Order />
>            </OrderItem>
>            <DeliverySchedule />
>            <TransportHandlingUnit />
>            <Shipment />
>    </DespatchedItem>
></DespatchAdvice>
>
>and the Receipt Advice can follow the path....
><ReceiptAdvice>
>    <ReceivedItem>
>            <OrderItem>
>                <Order />
>            </OrderItem>
>            <DespatchedItem>
>                <DespatchAdvice />
>            </DespatchedItem>
>            <DeliverySchedule />
>    </DespatchedItem>
></Despatch Advice>
>
>and the Invoice can follow the path....
><Invoice>
>    <InvoiceItem>
>            <ReceivedItem>
>                <OrderItem>
>                    <Order />
>                </OrderItem>
>    </InvoiceItem>
><Invoice>
>
>Does this make sense???
>
>
>Michael Adcock wrote:
>
>>Hi!
>>
>>Here is the revised diagram. I believe it is now up-to-date with the
>>agreed mods. Also I have modified the price area..., it seems much
>>simpler but still functional.
>>
>>I have added in Despatch Advice, Receipt Advice and Invoice, 
>also their
>>Lines with (as yet) incomplete information but enough to 
>understand the
>>difference and linkages. Sue and I discussed this on the 'phone.
>>
>>Note also that this does not include any e-mail comments sent/received
>>since 15.00hrs GMT 5 Dec, if there are any!
>>
>>'bye for now...
>>
>>Mike Adcock
>>Standards & Security Unit
>>APACS - Association for Payment Clearing Services
>>Mercury House, Triton Court
>>14 Finsbury Square
>>London EC2A 1LQ
>>Tel: +44 (0) 20 7711 6318
>>Fax: +44 (0) 20 7711 6299
>>e-mail: michael.adcock@apacs.org.uk
>>
>>
>>
>>**********************************************************************
>>The opinions expressed are those of the individual and not 
>the company.
>>  Internet communications are not secure and therefore APACS 
>does not  
>>     accept legal responsibility for the contents of this message.
>>  If the reader of this message is not the intended recipient, or the
>>employee responsible for delivering this communication to the intended
>>recipient, you are hereby notified that any disclosure, 
>distribution or
>>   copying of this communication is strictly prohibited.  If you have
>> received this communication in error, please notify us immediately by
>>          telephone to arrange for its return.  Thank you.
>>**********************************************************************
>>
>>  
>>
>
>-- 
>regards
>tim mcgrath
>fremantle  western australia 6160
>phone: +618 93352228  fax: +618 93352142 
>
>
>


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


Powered by eList eXpress LLC