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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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

Subject: Re: [ubl] Definitions of the Name element

What is more, it is 'standard' (EU Directives and presumably other
regional requirements elsewhere) for an Invoice to include an
Invoice Type as a piece of text or a code. This is the case even
with a paper document. UBL merely reflects with XML what is defined
for each document type by the business world(s). Except that
occasionally the modeling of documents in XML throws up some useful
patterns which help to make existing business features reusable and
consistent across document types - as in this case where UBL could
usefully add the entity of document type to every document without
straying from the business requirements - call it rationalizing the
requirements. Adding 'Note' to each document type is another example
of this recognition of requirements / features common to document
types in general, as is 'Name' I suppose. In my opinion. It might
be useful to recognise a generic *abstract* document type (like
the CC) that is a useful starting point for creating most new
document types (not something which is represented using XML but
something more abstract like the CC).

ID 1..1
OtherID 0..n (abstract of course, not actually called this)
CopyIndicator 0..1
UUID 0..1
IssueDate 1..1
IssueTime 0..1
DocumentType 0..1
DocumentTypeCode 0..1
DocumentName 0..n (called just 'Name' in some documents)
Description 0..n
Note 0..n
SenderParty 0..n
ReceiverParty 0..n
OtherParty  0..n
Instruction 0..n (abstraction of various entities)
DocumentLine 0..n

and similarly for document line

I think eDocs does this but I think it goes a bit further than
I would by representing it more concretely.

Stephen D. Green

SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice

Quoting JAVEST <roberto@javest.com>:

> My opinion...
> The reason a Freight Invoice document exists is because there are
> effectively additional business entities not found on a Commercial
> Invoice (e.g. Shipment)
> The Self Invoice is not so different from a Commercial Invoice but it
> is a way to identify this particular situation in a unambiguos way (as
> it is a VAT aspect)
> Generally there is not the reason to create another document if
> business entities are the same, but just data changes.
> Roberto
> Oriol Bausą ha scritto:
>> Talking about invoice and type codes, I think there is another   
>> issue. There is an InvoiceTypeCode BBIE in the Invoice document,   
>> but there are also some different invoice type documents (aka Self   
>> Invoice or Freight Invoice) so it is difficult to decide whether   
>> you should use the InvoiceTypeCode or you should better define a   
>> new invoice document type (for instance Rectification Invoice,   
>> Proforma Invoice, and so on). El 04/02/2008, a las 22:35,   
>> stephen.green@systml.co.uk <mailto:stephen.green@systml.co.uk>   
>> escribió:
>>> Could I just 'chip in' on this. If it is as it seems that the
>>> Name is to be used for the type of document when it comes to
>>> the Waybill, then I would agree with Jon that Name should be
>>> on every document for this purpose since even invoice needs
>>> to state an invoice type and invoice type code is only useful
>>> when there is an agreed set of codes to use to cover all
>>> possibilities. For anything not coded there would be value in
>>> having a Text-based BBIE, in my opinion.

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