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... (01)
1.1 Invoice Characteristics (02)
Invoice in a logistics context can refer to qualitatively quite different
types of invoices: (03)
Trade invoice (materials, components, products)
Freight invoice (transportation services)
Services invoice (nontransportation services)
Combined invoice (trade and freight and services invoice) (04)
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)... (05)
1.2 Invoice Initiation (06)
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... (07)
1.3 Invoice Content (08)
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)... (09)
1.4 Invoice Transaction (010)
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... (011)
----------------------------------------------------------------------------
------------------------------------------ (012)
Duane Nickull wrote the following on Thursday, 07/10/2003 at 13:40:21: (013)
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??) (014)
Duane Nickull wrote the following on Thursday, 07/10/2003 at 13:11:30: (015)
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. (016)
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? (017)
"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" (018)
Greg Olsen wrote the following on Thursday, 7/10/2003 at 13:05:00: (019)
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." (020)
_________________________________________________________________
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 (021)
|