RE: Core Components aggregate Analysis

["Welsh, David" <David.Welsh@nordstrom.com>]

Harmut,
I honestly hadn't looked at PRODAT as a full message, as I am came from the
EDIFACT transport end of the community. 
As far back as the early 90's in transport, when we were working on BAPLIE
and other SMDG messages, where there is a very  strong focus to marry
products and services in a message(ex. a container used to transport
industrial products), there was problems (nothing major though) with some of
the larger users (I was one of them) with getting comprehensive
classifications in our area within our normal transport messages; ex.
BAPLIE, MOVINS, CUSCAR ...

Coming from MD1 and for commercial products and specifically PRODAT itself
as a full EDIFACT message, I can honestly believe you that PRODAT has
addressed such concerns for products for manufacturing. 

Thanks for the enlightening note, and all the very best.
Dave Welsh


> -----Original Message-----
> From: Hermes Hartmut [mailto:Hartmut.Hermes@MCH11.siemens.de]
> Sent: Thursday, January 11, 2001 6:36 AM
> To: 'Welsh, David'
> Cc: 'ebxml-core@lists.ebxml.org'
> Subject: AW: Core Components aggregate Analysis
> 
> 
> 	Sorry David you should have checked the EDIFACT PRODAT 
> message type
> prior to saying that there is "been a bit of a shortcoming in
> 	the trad EDI world, when it comes to product 'classification &
> identification'". Indeed There is a very well working 
> capability to classify
> and identify products and their Characteristics. Maybe you 
> shoul have a look
> at this message type. The EWG wMsub working group Materials 
> Management dealt
> quite a long time in these issues and developped a message 
> type which even
> wirks in the provision of complexSystem's masterdate 
> including "physical
> 	product/service descriptions/attributes," AS WELL AS 
> "descriptive
> latitude (which may be more of a code list-s- issue) towards 
> allowing for
> the 'market
> 	aspects' of a product".
> 
> Kind regards / Mit freundlichen Gruessen
> Hartmut Hermes     
> Siemens AG GPL GLO LE	D-80286 Muenchen     
> Tel: +49 89 9221 4564     	Fax: +49 89 636 718 580
> Tel: +49 8233 600 222     	Cellular phone: +49170 22 97 606  
> Project Omega Information may be found at:
> http://www.el.siemens.de/cgi-bin/index.pl?href=/new/logistik/g
> eschabw/omega/
> uebersicht.en.htm
> If you want to get information on the Basic Semantic Register 
> please visit:
> http://forum.afnor.fr/afnor/WORK/AFNOR/GPN2/TC154WG1/index.htm
> 
> 	-----Ursprüngliche Nachricht-----
> 	Von:	Welsh, David [SMTP:David.Welsh@nordstrom.com]
> 	Gesendet am:	Dienstag, 2. Januar 2001 19:09
> 	An:	'Bob Haugen'; ebxml-core@lists.ebxml.org
> 	Betreff:	RE: Core Components aggregate Analysis
> 
> 	Bob,
> 	I don't know if this will help but there's been a bit of a
> shortcoming in
> 	the trad EDI world, when it comes to product 'classification &
> 	identification', that I hope will be a bit better in the ebXML
> world. 
> 	Specifically there's been a good degree of attention in 
> the past to
> physical
> 	product/service descriptions/attributes, and not enuf 
> descriptive
> latitude
> 	(which may be more of a code list-s- issue) towards 
> allowing for the
> 'market
> 	aspects' of a product.
> 
> 	For example, for years in the container transport world 
> there's been
> 	discussions on the concept of container type/size codes 
> which have
> largely
> 	been literally about the combination of container type, 
> -ex. open
> top or
> 	high cube or ..-, and container size -40' or 20' or ..-. 
> 	All the type/size codes are workable to a degree but in the
> operational
> 	dispatching & planning of containers, the shipping 
> lines tended to
> also have
> 	to include the important marketing aspects of a 
> container; ex. never
> send a
> 	container which is used to regularly carry onions to a 
> big customer
> carry
> 	new clothes on a 6 week journey !!
> 
> 	I'm sure there's examples of this in other industries, 
> and it sounds
> like
> 	EconomicResource***** concepts are more flexible ?
> 	Thanks
> 	Dave Welsh
> 
> 
> 	> -----Original Message-----
> 	> From: Bob Haugen [mailto:linkage@interaccess.com]
> 	> Sent: Tuesday, January 02, 2001 4:41 AM
> 	> To: ebxml-core@lists.ebxml.org
> 	> Subject: RE: Core Components aggregate Analysis
> 	> 
> 	> 
> 	> A couple of comments on what I think might be the current
> 	> core component definitions, as evidenced by the spreadsheet
> 	> sent by Marianne Cockle with finance group comments.
> 	> 
> 	> I think the definition of Product/service may suffer 
> from a common
> 	> conceptual problem, the lumping together of product 
> definition and
> 	> product instance.  For example, the definition of an 
> automobile
> 	> model (e.g. Flapmobile Deluxe Roadster) vs a 
> particular instance
> 	> with a Vehicle Identification Number sold to a particular
> customer.
> 	> Or the definition of a food product with a SKU vs a particular
> 	> bunch of products on grocery shelves with Lot IDs.
> 	> Or a flightnumber vs a seat on a particular leg of a 
> particular
> trip.
> 	> Or a room number vs a particular stay.
> 	> 
> 	> The BP Metamodel makes this distinction as 
> 	> EconomicResourceType vs EconomicResource (instances of
> 	> the type).  EconomicResource may be too abstract for
> 	> core components, but the distinction between type and 
> 	> instance may be necessary.  All ERP systems make the
> 	> distinction in one way or another - the type level is often
> 	> called "Master", e.g. "ProductMaster" vs "Inventory" or
> 	> "Lot".
> 	> 
> 	> Also, I fully agree with the finance group's comment about
> 	> differentiating Duration (a length of time) from DateTime,
> 	> a point in time.
> 	> 
> 	> Respectfully,
> 	> Bob Haugen
> 	> 
>