[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-lcsc] Questions re: mappings
As we discussed, here are my thoughts on these issues. However, i would like Jean to put her opinion on this. my involvement was orginally attempting to keep this process rolling and i don't want to overlap the work she has been doing. Just a general note to start: the UN Layout forms have always been problematic for computer applications. many of these issues are not new and have been resovled in a variety of ways. what i suggest are simply my ideas/views - not the definitive approach. G. Ken Holman wrote: > Thank you, Tim, for the mappings that you gave in: > > http://lists.oasis-open.org/archives/ubl-lcsc/200301/msg00200.html > > Some observations and questions: > > (1) Order > > (1.1) - each of Transport Charges, Terms of Payment, Currency of > Payment, and Buyer's Bank allow more than one entry but there is only > a single line in the form. I can space delimit the items so they > appear on the one line, but overflow will be clipped. If I signal an > error on the overflow, formatting shuts down. If I clip, the user > won't know. There are no guidelines regarding continuation pages for > this item, and even if so I would be unable to overflow more than a > single concept, which for now is the list of line items. Some of these repeats are a manifestation of the data models UBl has adopted and whilst theoretically they may repeat it is unlikely. taking the 80/20 rule, i would comma delimit all multiple values in a left-right/top-down manner (e.g. USD,GBP, EUR or FOB,CAF, CAI and so forth) imagine how a typist would do it. I think w could even let the things spill into other sections - if we ever got that many. I agree only the Item list should cause a page spill. > > > (1.2) - in the absence of continuation forms, I've been using both a > page number top right and an enumeration in the line items; I'd like > to continue using the enumeration for now, so I suggest that we have: > > B1234567 > 1 of 10 > > or: > > 1 of 10 > B1234567 > > ... since I've allocated two lines per line item. Can you suggest an > alternative? i dont fully understand your question. I see "Page n of n" at the top of each page and that's fine. Within the Item, i see you are using "n of n" - this isn't what is supposed to be here. this is a buyer's reference to a specific order line - not the actual item's identifier (that would/should be part of the description - which means we should add this the mapping for section 5.7 - i missed it). This order line reference may be simply numeric increments , e.g. 1,2,3,4, but it may not be - they can use their own identification of order lines. is that what you mean with "B1234567" or was that the identifier of the Item? either way, i think its best to leave this as the data field transmitted and not assume it has any sequential significance. (i.e. not use the "? of n" approach) > > > (1.3) - for Terms of Payment the XPath address you gave as > po:Order/cat:AllowanceCharge/cat:TypeCodeID is not found in the set of > available XPath addresses you're correct - it was supposed ot be po:Order/cat:AllowanceCharge/cat:PaymentMeans/cat:TypeCodeID. however, this isn't really correct. the more i think about this, i realise that we don't want to use Terms of Payment for the Order (only the Invoice). so lets remove this mapping. > > (1.4) - the sample test instance you made from Sally's data has only > five visible entries; the teleconference group asked me to summarize > some of the technical issues and I have done so in: > > http://lists.oasis-open.org/archives/ubl-lcsc/200301/msg00215.html this limited visibility is not a problem . just our aerospace instance isn't a good one for your demonstration forms. in terms of your 'customization' options - i suspect yours (option 3) is what we want, but this is still under discussion with the NDR and CM teams. > > > (2) DespatchAdvice > > (2.1) - each of Mode of transport and Means of transport allow more > than one entry but there is only a single line in the form; please see > the discussion above in 1.1 as above > > (2.2) Container Nr: allows more than one, I can put each on individual > lines, though more would fit if I wrapped space delimited values; > which way to go and what about overflow? wrap , comma delimited values and don't worry about overflow - just keep going!! this is the same as with the previous multiple value situations. > > (3) Invoice > > (3.1) - Invoice clauses: did you want these each to start on a new > line and to be enumerated as in (1), (2), ... or (a), (b), ...? sounds good - but don't add any text (e.g. bullets), just new line > > > (3.2) - in Sally's Order instance that you massaged, is the Terms of > Delivery information supposed to be split into a reference rendered in > "Terms of Delivery" and prose rendered in "Invoice Clauses"? If so, > how would the arbitrary numbering accommodate the unnumbered clauses > identified in the spec for invoices? i thought we didn't map 'invoice clauses' in the Order document? are you proposing that we use this real estate for the Terms of Delivery? The Terms of Delivery will be a code e.g. FOB (possibly more than one) which is enough for people to understand the general terms. these are part of international trade's INCOTERMs codes that are widely used and understood. > > > Faxed mockups of sample field displays may be more easily created than > trying to mock up layouts in software (my fax number is in my trailer). it is hard for me to scan and fax - so this is the best i can do for now. ..... over to Jean! > > Thanks again, Tim! I make quick progress when these formatting > specification documents are filled out. With the above you now know > the additional kinds of information I'm looking for regarding layout. > > ...................... Ken > > -- > Upcoming hands-on in-depth Europe: February 17-21, 2003 > XSLT/XPath and/or XSL-FO North America: June 16-20, 2003 > > G. Ken Holman mailto:gkholman@CraneSoftwrights.com > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ > Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) > ISBN 0-13-065196-6 Definitive XSLT and XPath > ISBN 0-13-140374-5 Definitive XSL-FO > ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath > ISBN 1-894049-10-1 Practical Formatting Using XSL-FO > Male Breast Cancer Awareness http://www.CraneSoftwrights.com/o/bc > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > -- regards tim mcgrath fremantle western australia 6160 phone: +618 93352228 fax: +618 93352142
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC