Re: [ubl-dev] looking for practical examples

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2009-02-10 11:15 +0100, Alexander Whillas wrote:
>The SKU is American in origin and since most/popular eCommerce system
>online (at the moment) originate in the USA this has sort of become
>the "de facto standard", but as its just an identify and has no fixed
>formatting constraints it doesn't really matter what you call it. What
>I'm really interested in is using it for stock tracking.

That tells me you could be treating it as a 
<CatalogueItemIdentification> semantic (if you are basing your 
identification on the catalogue you are creating), but I like 
Steven's idea of using <StandardItemIdentification> and in the <ID> 
child indicate in the meta data that it is an SKU.

>For stock tracking I need to keep a record for every combination of a
>products attributes (size, colour etc) or AdditionalItemProperty as
>UBL calls them.

Then I'll retract what I said earlier and move the property 
attributes "up" in the document model to <Item> instead of <ItemInstance>.

>Thus I need an ID at the ItemInstance level and UBL
>seems to only have one identifier at that level: SerialID. Is this
>correct?

No, SerialID is for a particular *instance* of a particular item.  As 
I understand what others have said in the past, if you are tracking 
the properties of an item *in general* (i.e. all instances of that 
item), then you use properties of <Item>.

For example, if I had three Gizmos, all in red, I would use the 
following (which validates against the UBL Catalogue schema) to 
describe a catalogue line for red Gizmos and the three that I had in 
stock with unique serial numbers:

T:\ftemp>type whillas.xml
<?xml version="1.0" encoding="UTF-8"?>
<Catalogue xmlns:cbc=
"urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
            xmlns:cac=
"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
            xmlns="urn:oasis:names:specification:ubl:schema:xsd:Catalogue-2">
   <cbc:ID>1</cbc:ID>
   <cbc:IssueDate>2009-02-10</cbc:IssueDate>
   <cac:ProviderParty>
     <cac:PartyName><cbc:Name>Me</cbc:Name></cac:PartyName>
   </cac:ProviderParty>
   <cac:ReceiverParty>
     <cac:PartyName><cbc:Name>You</cbc:Name></cac:PartyName>
   </cac:ReceiverParty>
   <cac:CatalogueLine>
     <cbc:ID>A</cbc:ID>
     <cac:Item>
       <cbc:Description>Gizmo</cbc:Description>
       <cac:StandardItemIdentification>
         <cbc:ID schemeURI="urn:x-SKU">ABC987</cbc:ID>
       </cac:StandardItemIdentification>
       <cac:AdditionalItemProperty>
         <cbc:Name>Colour</cbc:Name>
         <cbc:Value>Red</cbc:Value>
       </cac:AdditionalItemProperty>
       <cac:ItemInstance>
         <cbc:SerialID>123</cbc:SerialID>
       </cac:ItemInstance>
       <cac:ItemInstance>
         <cbc:SerialID>124</cbc:SerialID>
       </cac:ItemInstance>
       <cac:ItemInstance>
         <cbc:SerialID>125</cbc:SerialID>
       </cac:ItemInstance>
     </cac:Item>
   </cac:CatalogueLine>
</Catalogue>
T:\ftemp>w3cschema-all 
u:\cd\artefacts\os-UBL-2.0\xsd\maindoc\UBL-Catalogue-2.0.xsd whillas.xml
Xerces...
No validation errors.
Saxon...
No validation errors.
Altova...
The XML data is valid

T:\ftemp>

>I'll also need to record a stock level for each instance. There
>doesn't seem to be anything I can use for this that the ItemInstance
>level except, again AdditionalItemProperty?

Here I'm thinking you might use an extension, since as I understand 
it, the semantics of a Catalogue are not really the semantics of an 
inventory record.  I don't see anything jump out at me.

How about overloading the <cbc:MaximumOrderQuantity> concept to be 
your stock level?  Or do you otherwise already have limits on order quantities?

Perhaps someone on the list can recommend an appropriate item to use 
for this semantic.

>I put in the name spaces so you might correct me as to what I'll need
>there :) I'm on a Mac and the only tool I seem to have been able to
>find is Exchanger XML Lite (www.freexmleditor.com) which I think does
>some basic validation but I haven't explored how helpful it is if you
>give it a .xsd it doesn't know (it does have a UBL 1.0 example
>however). Advice on a better editor for Mac would be most welcome.

I use emacs.  :{)}  Not everyone will agree with that.

>The mandatory fields might be a problem as they seem to imply the
>other documents, which in turn implys the whole UBL (or is ebXML?)
>process.

It doesn't imply process, it only implies document model 
requirements.  The Catalogue is being sent from a provider to a receiver.

>At this stage I was just looking for a standards way to
>represent the products catalogue (half for stock tracking purposes)
>between two systems. The UBL process does seem sensible but I'm only
>responsable for one communication in the chain and so the rest of
>parts are not applicable or beyond my scope and/or control.

Sure, but by using UBL, when it comes time to address other aspects 
of scope, you will have built a foundation on a common library of 
business objects across multiple document models.

And UBL is designed such that you can add your own document 
descriptions on top of the common library.  I cover this in my 
hands-on UBL class.

>I guess I plan to take only the parts I need and try and comply as
>much as possible, within the time constraints of my project.

Yes, UBL is there to take off the shelf and only use what you 
need.  The benefit is that you are building on a suite of business 
objects that can be used in multiple document exchanges.

>Its a PHP
>project and so I really only have to aim for well formed XML not so
>much adherence to a strict schema. I guess this is how standards
>evolve, hand-to-hand with industry/necessity. If UBL becomes adapted
>by other OS platforms, more than my implementation, then I guess
>stricter compliance will follow.

I highly recommend that you stick with conformance and not just 
well-formedness ... though I admit it adds a small amount of extra 
work to start.

>The 'ActualDeliveryDate' example is interesting as ActualDeliveryDate
>would be a process/time dependant variable which only comes into
>existence once the Order has actually been delivered. While the goods
>are in the process of being delivered, they still need and Order with
>a Delivery type.

Looking at our Crane-UBL2Report-Catalogue-EN.html report for all of 
the information items used in Catalogue, I do not see that 
ActualDeliveryDate is used anywhere at all in that document type.

This implies to me that you'll have other document types, such as Order.

Which strengthens my argument to use the UBL business objects in the 
common library and UBL documents on top of that common library to 
ensure the expression of information found in multiple documents is the same.

I hope this helps.

. . . . . . . . . . . . Ken

--
Upcoming hands-on XSLT, UBL & code list hands-on training classes:
Brussels, BE 2009-03;  Prague, CZ 2009-03, http://www.xmlprague.cz
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal