I think that the general answer to the questions asked (below) is that
an ontology consists of defined concepts whose structure and behavior
reflects the structure and behavior of instances in the domain of
interest, usually in the real world. As a consequence, for each
object in the real world that has a different structure (different
in some way significant to the ontologist or his/her manager),
there should be a different concept in the ontology.
For convenience the concepts are ordered in a hierarchy of classes
in which the subclasses inherit properties from the higher
classes. (01)
If it is possible to have an "invoice" that is not in response to
an "order", then that "invoice" concept would have to be different
from the one specified in the UBL UML "Invoice" diagram, as that
diagram indicates that an invoice references exactly one "Order". (02)
Perhaps one would want to create a higher-level concept,
say "GeneralizedInvoice", of which the "Invoice" of UBL is one
subtype (specialization). It would be greatly helpful in
bringing up such questions if one could find specific examples
of the things one wants to see represented -- in this case
invoices. If one is not available in electronic form, perhaps
one could get a hard copy and scan it and send the image to
this group. That would help discussion.
Since we are right now concerned with representing invoices
that are a request for payment in response to an order, we
should probably concentrate on that meaning of "Invoice" until
concrete specific examples of exceptions have been identified and
their details presented so that we can decide precisely how they
relate to this UBL "Invoice" concept. (03)
Pat (04)
===================== (05)
McHugh, Bob - MWT wrote:
> I, too, am very new to SUMO, ontology, and so forth, so maybe I am not
> stating things correctly in onological terms, but I do have some concerns
> about how the concept of Invoice as it relates to logistics would be
> represented in SUMO...
>
> 1.1 Invoice Characteristics
>
> Invoice in a logistics context can refer to qualitatively quite different
> types of invoices:
>
> Trade invoice (materials, components, products)
> Freight invoice (transportation services)
> Services invoice (nontransportation services)
> Combined invoice (trade and freight and services invoice)
>
> The first three types of invoices can have considerably different elements
> (the fourth type is a superset of the first three types). I am unclear as
> to whether SUMO would define Invoice as containing all of these various
> elements, or define the four types of invoices separately (Trade Invoice,
> Freight Invoice, Services Invoice, Combined Invoice)...
>
> 1.2 Invoice Initiation
>
> There are Trade Invoice situations, like vendor managed inventory (VMI),
> where no purchase order, sales order or transfer order is created or placed
> in the conventional sense. A Trade Invoice could be initiated by a change
> in ownership with no intrafacility movement, a change in ownership with
> intrafacility movement, a change in ownership with interfacility movement, a
> change in ownership caused by material use, and so forth. I am not sure
> that limiting a Trade Invoice to be a response to an order would be
> practical...
>
> 1.3 Invoice Content
>
> An Invoice without detail information (for example, line items in a Trade
> Invoice, lading items and accessorial services in a Freight Invoice,
> activities and rates in a Services Invoice) could cause a number of
> potential problems. A failure to explicitly state detail information can be
> interpreted in different ways by different trading partners in the global
> supply chain (for example, split shipment versus short shipment versus
> nonshipment situations in a Trade Invoice). Researching discrepancies
> without detail information is virtually impossible (invoice did not match
> originating document, invoice matched but matched out of tolerance, invoice
> matched and matched within tolerance but varied on detail
> quantities/amounts, and so forth). Invoice amounts may vary qualitatively
> for different trading partners depending on whether the amounts are pass
> through amounts or margined amounts (and these amounts could be mixed in one
> document). Some trading partners in the global supply chain may only have
> available to them the contents of the invoice, without any of the
> corresponding originating document information. Some countries require for
> import and export purposes that all invoice documents contain detail
> information. Generally the point would be that trying to define situations
> where detail information could be left out is likely to introduce more
> problems than any potential benefit is worth (and it is unclear what
> significant benefit would be obtained from leaving out the detail
> information)...
>
> 1.4 Invoice Transaction
>
> There are some regulatory situations where an Invoice cannot be split in a
> meaningful sense (split into more than one transaction), particularly for
> import and export compliance situations where the governmental agency
> requires the entire package of related information (commercial invoice,
> shippers export declaration, shippers letter of instruction, packing list,
> bill of lading, and so forth) to be sent in one and only one transaction or
> message...
>
> ----------------------------------------------------------------------------
> ------------------------------------------
>
> Duane Nickull wrote the following on Thursday, 07/10/2003 at 13:40:21:
>
> The notion of "document" is from the paper world and IMO - deprecated for
> electronic business. Why should it be necessary to send everything all at
> once, packaged into a "document"? let's think outside the box (or
> document).
> 1. An invoice is a request for payment.
> 2. An invoice contains a set of information, the minimum of which can be
> determined by adding together each parties legal, administrative, technical,
> geo-political and other requirements and finding a common superset.
> 3. An invoice payment request can be made in more than one single
> transaction (go away from document).
> 4. The order in which an invoice is received within a specific transaction
> will vary greatly depending on the nature of that transaction.
> 5. An invoice can be "implied" ( A quote with a prepayment demand serialized
> inline??)
>
> Duane Nickull wrote the following on Thursday, 07/10/2003 at 13:11:30:
>
> To me, the definition depends ont eh context. If the invoice can be
> eletronically linked to other transactions via a smart business process, it
> should not be necessary to include line items for each item, only a
> reference to the original PO. If it cannot be linked, then it will have to
> include these.
>
> Likewise, almost every piece of information or definition depends on the
> surrounding context. Geo-political factors definately affect it as well as
> legal ramifications. What does an "Invoice" (or "Facture" in Quebec) mean
> in Canada? Is that the same semantics as in Bengal or Nairobi?
>
> "An invoice is a container data element that includes other data elements to
> convey a request for payment. The nature and number of the secondary data
> elements depends on the context in which it is being used"
>
> Greg Olsen wrote the following on Thursday, 7/10/2003 at 13:05:00:
>
> Your definition, "An invoice is a document which is part of a financial
> transaction between two or more parties and is a response to an order." is
> good as far as it goes. But this definition could also represent a
> "pay-on-receipt ship notice". I would suggest the definition be opened up to
> include the following: "An invoice is a document which is part of a
> financial transaction between two or more parties requiring either the
> payment of monies or the granting of a credit and is a response to an
> order."
>
>
>
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Subscribe/Unsubscribe/Config:
>http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>
> (06)
--
=============================================
Patrick Cassidy (07)
MICRA, Inc. || (908) 561-3416
735 Belvidere Ave. || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054 || (908) 668-5904 (fax) (08)
internet: cassidy@xxxxxxxxx
============================================= (09)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Unsubscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (010)
|