[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Basic Invoice - How Names Are Linked / Determined
Yes, the mapping is helped by the use of data dictionary names to define each UBL entity according to CCTS's implementation of the data dictionary naming standard ISO 11179. The standard says that the dictionary entry name (Invoice. Invoice_ Period.Period or Period.Details) is composed of the parent followed by the entity name (with an optional qualifier which I think, if I remember correctly, is denoted by the underscore) followed by the datatype. There is more to it than that but you'd need to check out the full details, if you want them, in a copy of the CCTS document (some- times it was tricky to find it but I think one is included with UBL). Period.Details, as with all ABIE definitions, is an exception in that it just has two parts and Details is always the second part when defining an ABIE. The situation gets a little complicated when the exceptions are applied, sorry. The subtle difference between a term followed by underscore, e.g Invoice_ Period, and one without like 'Invoice Period' would be, is that in one case a qualifier is used and in another the qualifier has been merged into the term - the difference emerges when you reuse the entity because if its name is a combination of two words rather than a single word plus a qualifier then the two words always have to be used when it is reused. The other main point is the third part of the Dictionary Entry Name (DEN), the datatype name: this shows someone mapping (or an automated mapping system - like that of OASIS SET TC and METU - shameless plug) what datatype is used to represent the entity. For a 'leaf', BBIE entity it will be one of the defined datatypes like the UDTs, QDTs, custom QDTs, etc. If it is an ABIE it will be the associated ABIE. That's as simple as I can make it. It took ages to work out how to apply this in UBL so it may take a while to understand how it is applied, especially if you want to get into the precise details (take what I've said above with a little bit of 'a pinch of salt', I may be wrong in the exact details like what to call things and I've missed a fair bit out like not mentioning words like 'representation term', etc which are close to the heart of CCTS-ers). Best regards Steve Stephen D Green 2009/6/19 Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>: > > > In discussion how to use the UBL invoice, it is important to consider two > realities. My apologies if all this is familiar. > > One is that UBL typically is not "native" to either the party originating > the invoice nor the party receiving and, one can hope, paying the invoice, > but merely an intermediate version used to communicate data between unlike > systems. Consequently, it often is necessary to define (map) data as > expected or required by the given recipient. For example, if the business > deal with the recipient involves service billing by week, it may be that the > UBL "period" data fields should map to week, even if the invoice originator > and the invoice originator's billing system internally categorize invoices > by calendar month. For many invoices (e.g., for the typical product invoice) > fields such as invoice date or FOB date or some other specific date often > governs all important invoicing matters, making "period" essentially > irrelevant to the paying party, because the payer's internal systems will > "bucket" invoices by period according to internal conventions, not by the > supplier's. > > Second, note that many data conventions to be used in a given invoice are > essentially dictated by upstream transactions, such as the purchase order, > ship advice, quote or contract. As an example, a customer often will require > the invoice to include original PO line number, so original PO line data > must be captured, ideally by being carried through the internal ERP's sales > order management process and then picked up from the ERP for the outbound > invoice process. The mapping process needs to be sufficiently agile to deal > with transaction-level dynamics. > > Often mapping and sending less is more, because if a data field is unlikely > to be useful to the recipient, don't send it so that you will not have to > explain or defend it. > > > Fulton Wilcox > Colts Neck Solutions LLC > > > > -----Original Message----- > From: jaymuz@optusnet.com.au [mailto:jaymuz@optusnet.com.au] > Sent: Thursday, June 18, 2009 8:35 PM > To: ubl-dev@lists.oasis-open.org > Subject: [ubl-dev] Basic Invoice - How Names Are Linked / Determined > > Hi, > > I'm nearly there. Thanks for your answers. > > A bit of clarification on what is following what here [if any] with regards > names. > > 1. The tag name <tagname></tagname> is taken from ref attribut value > "cac:InvoicePeriod" even though the element name is "InvoicePeriod" in cac > [as otherwise namespaces wouldn't function. Correct? > > 2. In this line in Invoice: > <ccts:DictionaryEntryName>Invoice. Invoice_ Period. > Period</ccts:DictionaryEntryName> > > To determine what should be after Invoice_ Period. we look for the > ObjectClass tag of the next level in this case the complex type definition. > Correct? > > <ccts:ObjectClass>Period</ccts:ObjectClass> > > 3. If that be the case then where do we get the string "details" in: > <ccts:DictionaryEntryName>Period. Details</ccts:DictionaryEntryName> > > and the string "Date" in: > <ccts:DictionaryEntryName>Period. Start Date. > Date</ccts:DictionaryEntryName> > > > invoice: > > <xsd:element ref="cac:InvoicePeriod" minOccurs="0" > maxOccurs="unbounded"> > <xsd:annotation> > <xsd:documentation> > <ccts:Component> > <ccts:ComponentType>ASBIE</ccts:ComponentType> > <ccts:DictionaryEntryName>Invoice. Invoice_ Period. > Period</ccts:DictionaryEntryName> > <ccts:Definition>An association to period(s) to which the > Invoice applies.</ccts:Definition> > <ccts:Cardinality>0..n</ccts:Cardinality> > <ccts:ObjectClass>Invoice</ccts:ObjectClass> > > <ccts:PropertyTermQualifier>Invoice</ccts:PropertyTermQualifier> > <ccts:PropertyTerm>Period</ccts:PropertyTerm> > > <ccts:AssociatedObjectClass>Period</ccts:AssociatedObjectClass> > </ccts:Component> > </xsd:documentation> > </xsd:annotation> > </xsd:element> > > > cac: > > <xsd:element name="InvoicePeriod" type="PeriodType"/> > > <xsd:complexType name="PeriodType"> > <xsd:annotation> > <xsd:documentation> > <ccts:Component> > <ccts:ComponentType>ABIE</ccts:ComponentType> > <ccts:DictionaryEntryName>Period. > Details</ccts:DictionaryEntryName> > <ccts:Definition>Information about a period of > time.</ccts:Definition> > <ccts:ObjectClass>Period</ccts:ObjectClass> > </ccts:Component> > </xsd:documentation> > </xsd:annotation> > <xsd:sequence> > <xsd:element ref="cbc:StartDate" minOccurs="0" maxOccurs="1"> > <xsd:annotation> > <xsd:documentation> > <ccts:Component> > <ccts:ComponentType>BBIE</ccts:ComponentType> > <ccts:DictionaryEntryName>Period. Start Date. > Date</ccts:DictionaryEntryName> > <ccts:Definition>The start date of the > period.</ccts:Definition> > <ccts:Cardinality>0..1</ccts:Cardinality> > <ccts:ObjectClass>Period</ccts:ObjectClass> > <ccts:PropertyTerm>Start Date</ccts:PropertyTerm> > <ccts:RepresentationTerm>Date</ccts:RepresentationTerm> > <ccts:DataType>Date. Type</ccts:DataType> > </ccts:Component> > </xsd:documentation> > </xsd:annotation> > </xsd:element> > > cbc: > > <xsd:element name="StartDate" type="StartDateType"/> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]