{"text_format":"5","workbook":"xls","n_sheets":3,"sheets":["All Issues","New documents","New ABIEs"],"props":{"last_modified_by":"Calc"},"defined_names":["Excel_BuiltIn__FilterDatabase_1"],"not_rendered":{"macros":1,"external_links":1,"defined_names":1},"read":"whole","date_system":"1900","formulas":"cached_only"}

{"sheet":"All Issues","index":0,"n_rows":43,"n_cols":14,"rows_kept":43,"flags":["formulas_cached_only"]}
[null,"Submitter","Email","Date Submitted","Category","Issue Type","Issue","Recommendation","Clarification","Disposition","Status","Action","Remark","Action no"]
[null,"Leong Jern-Kuan","jernkuan@crimsonlogic.com","2006-01-01","Transport","Bug","Critical : Transport Library. Certificate of Origin Document type.  1. ExporterParty and ImporterParty are at the wrong ABIE namly Certificate of Origin. 2. EndorserParty is already at Certificate of Origin Application ASBIE","1. ExporterParty and ImporterParty should be at the Certificate of Origin Application ASBIE. 2. Removal of EndorserParty at Certificate of Origin.",{"$nulls":3},"Change in next major release: 1. ExporterParty and ImporterParty should be at the Certificate of Origin Application ASBIE. 2. Removal of EndorserParty at Certificate of Origin."]
[null,"UN/CEFACT TBG3 (Chair Dominique Vankemmel)","dvankemmel@wanadoo.fr","2006-02-01","Transport","General","Limited scope regarding transportation: covering only sea/river transport, focused on the relations between the shipper/exporter/consignor and the freight forwarding agent and not including the parties involved in the actual movement of the consignments of the goods."]
[null,"UN/CEFACT TBG3 (Chair Dominique Vankemmel)","dvankemmel@wanadoo.fr","2006-02-01","Transport","General","Business process: has to be revised and completed according to the existing business practices. ",null,"For example: the freight forwarding instructions between the shipper and the freight forwarder has to be complemented by the shipping instructions to the actual carrier; the certificate of origin process has no direct relationship with the bill of lading/ waybill being produced by the transportation agent."]
[null,"UN/CEFACT TBG3 (Chair Dominique Vankemmel)","dvankemmel@wanadoo.fr","2006-02-01","Transport","General","Semantic definitions of documents description ( documents types chapter 5.10) need to be aligned with the existing EDIFACT standards code list in  UNCL (ref: data element 1001 document/message name)"]
[null,"UN/CEFACT TBG3 (Chair Dominique Vankemmel)","dvankemmel@wanadoo.fr","2006-02-01","Transport","General","Although TBG3 appreciates the UBL development for ocean transport, the UBL deliverables should be further extended to multimodal transport with the collaboration of TBG3 business experts.      ","the UBL deliverables should be further extended to multimodal transport with the collaboration of TBG3 business experts.   "]
[null,"Dave Fitzpatrick (EFM project)","fitzpatrick_david@bah.com","2006-03-01","Transport","New Requirement","Desire to define size constraints on XML elements.","Section 1.6, Customization, should offer guidance on how and when to place size constraints on a given xml element. In particular this section, or a separate section, should articulate how transport specific terms may be harmonized with the UN Trade Element Directory."]
[null,"Dave Fitzpatrick (EFM project)","fitzpatrick_david@bah.com","2006-03-01","Transport","General","It is unclear how UBL 2.0 transport messages can be defined to express the constraints described in the UNTDED. While this may be characterized as a customization; this is an important consideration to achieve semantic interoperability."]
[null,"Dave Fitzpatrick (EFM project)","fitzpatrick_david@bah.com","2006-03-01","Transport","Bug","The relationship of Consignment and Shipment is on-to-many. However, it should be many-to-many. Just as a consignment can be shipped in many shipments, many consignments can be consolidated into one shipment.","Change the relationship to many-to-many"]
[null,"Dave Fitzpatrick (EFM project)","fitzpatrick_david@bah.com","2006-03-01","Transport","Bug","Business processes to be revised and completed according to the existing business practices. For example: the freight forwarding instructions between the shipper and the freight forwarder has to be complemented by the shipping instructions to the actual carrier - the certificate of origin process has no direct relationship with the bill of lading"]
[null,"Dave Fitzpatrick (EFM project)","fitzpatrick_david@bah.com","2006-03-01","Transport","New Requirement","UBL 2.0 transport messages are standalone xml schemas with each based upon the same data dictionaries. These transport messages need to be related to each other via some kind of context or process. There should be a higher level \\\"dialogue\\\" that presents how these messages may be used together in a more global business transaction."]
[null,"Dave Fitzpatrick (EFM project)","fitzpatrick_david@bah.com","2006-03-01","Transport and Procurement","MissingField","Believe there is no way to record discrepancies for quantities received. There is a need for a discrepancy identifier, date, and notes, and each discrepancy should be linked to a PO or line item, and have the name of the person verifying the dicrepancy and its status. The discrepancy should be more generic than just rejected, which is available in UBL."]
[null,"Stepehn Green","stephen.green@systml.co.uk","2007-06-01",null,"New Requirement","As pointed out to me by Luca Reginato in Italy, we have an\ninconsistency between the document types in that in most\nof them PaymentMeans has minimum occurance 0 and maximum\noccurance unbounded, which is great as PaymentDueDate can\nbe automated even when there are multiple payment due dates\nby using multiple PaymentMeans occurances. So far so good.\nHowever it is quite a general requirement to use the\nOrderResponse document as a key document (usually calling it\n'order confirmation' or 'order acknowledgement') as with\nwhat is called 'punch out' and similar common practises.\nIn such cases the OrderResponse is the primary document from\nthe seller (or seller's agent) and so it there is a strong\nrequirement to include here the payment information such\nas a Payment Due Date or set of Payment Due Dates. The\ninconsistency is that in UBL 2.0, although the need for such\npayment requirement information is acknowledge by the\ninclusion of PaymentMeans, it is only, in the OrderResponse\nwith the allowance of zero or one occurances (hence only a\nsingle payment due date at most).\n\nI do accept that fixing this would be quite a challenge as\nit may involve a backwards compatibility issue. Maybe there\nis a way to fix it by creating a new ASBIE and ABIE which\nhas multiple occurances and appending it to the Order Response.\nOtherwise it would seem implementers making primary use of\nthe OrderResponse in this way have to 1. create their own\nextension which reduces the opportunities for interoperability\nor 2. use a document such as Invoice in situations where this\nis otherwise deemed as unnecessary (and therefore more expense\nis imposed which doesn't necessarily bring a proportional\nreturn on investment perhaps) or 3. do without the automation\nof the payment due dates and just use a note or description.\nI think 3. is unsatisfactory as it should be a major benefit\nof using UBL that payments can be fully automated as part of\nuse of implementing electronic procurement with UBL. ",null,"The same thing should apply for OrderResponse and OrderChange\n",{"$nulls":3},"Mark Leitch sais: As far as I can see, there is only one UBL 2.0 document that has unbounded Payment Means and that is the Invoice itself; the other five documents that have Payment Means (Quotation, Order, Order Change, Order Response and Self Billed Invoice) all have 0..1 Payment Means.  Note: Payment Means is also in AllowanceCharge (0..n), Statement (0..1), StatementLine (0..1), Remittance Advice (0..1), Reminder (0..n), but not relevant to this conversation.\n\nAs far as I can remember, the unbounded Payment Means in Invoice was a Swedish requirement for situations where an Invoice could be settled via a bank or via the Giro system; it wasn't to facilitate multiple due dates.  I do have to say, however (and the NES customisation has proved this), having the due date only available in Payment Means is a real pain !  In NES we have to use a Payment Means Code \"1\" just to get access to the due date for the Invoice where the due date is not Payment Means specific.\n\n\"Traditionally\" we have thought of the Quotation document as the carrier for punch-out (or round-trip) information; punch-out basically means that the information is brought back from a remote location (Supplier site) to populate a Requisition in the Customer domain from which an Order will be derived (following the appropriate internal approval processes).  I think Stephen is referring to a simple straightforward web Order which is a different thing.  Whether multiple due dates are required in this scenario is debatable as is the validity of the Order Response adopting the role of the Order, but what remains is the fact that Invoice is the only document in question that facilitates unbounded payment due dates rather than that's being the norm.\n\n"]
[null,"UBL Italia","roberto.cisternino@gmail.com",39356,null,"New Requirement","Regarding the use of Payment Terms for staged payment terms e.g.\no Payment Terms 1  pay €100 in 30 days\no Payment Terms 2  pay €200 in the next 30 days\no Payment Terms 3  pay x% of the remainder in the next 30 days\no Payment Terms 4  pay remainder in the next 30 days\n"]
[null,"Ian Jones","ian.c.jones@bt.com ","2007-11-01",null,"New Requirement","I am still struggling to understand how we could build a UBL Order message with sub components.  From Tim McGrath's e-mail I believe we may need to handle all of his scenarios as we deal with a very large product set that may be assembled in a number of ways.  Some components will be sold as both an individual order line item and as a sub-line both priced and un-priced.  This is our challenge - we have many business operating units that can mix and match components in different ways and they want to become even more flexible so a simple \"this is the only way\" solution is not possible.  Following from Tim's suggestion I have looked at the catalogue message and I can see how that gives a Bill of Materials structure but that does not solve my problem as the users may not wish to create individual catalogue entries for each of the possible combinations.   My users requirement is for the BOM to be in the order/invoice as that is the model they understand and are comfortable with and do not wish to invest in catalogue messages at this time.\n\n        I know very little about UBL and I am acting as an intermediary so I may have missed Tim's point - what we really need is simple examples of how we would build UBL messages that support as a minimum Tim's scenarios.  I have a fear that we will actually need an open end BOM structure as in the past I worked on an EDI Invoice that had a 6 layer line item structure to accurately reflect the data needed and could contain over 100,000 item lines in 1 invoice.","Peter says: I understand your strugle. Items are in UBL seem as information about what is traded. The focus has been on identifing the item, not to model its content. In a UBL Order every Item is attached throug a lineItem, that also can contain a price. Where an Item specifies \"What\", an lineItem specifies the claim details used in the transaction (How many, when do I want it, to what price, etc). If you have a need for structured information about the item without price information there are the following posibillities:\n \n1) Set up your own name-value specification in AdditionalItemProperty and ItemPropertyGroup\n2) Use a new documenttype, like BOM in the ItemSpecificationDocumentReference\n3) Use a catalog document as Tim suggested.\n \nIf none of these fullfill your need I would like to ask whether it would help if we added a SubItem [0..n] inside Item in version 2.1, so you can describe an Item hierarchy.\n "]
[null,"Sweden SFTI","soren@ooidata.se","2008-02-01",null,"New Requirement","”... amounts must be positive”: In situations where sellers bundle offers like \"buy 3 pieces of item X, and you'll get 1 item Y free of charge\", we wish all items to be explicitly listed on order line","”… amounts must be non-negative\" ","soren@ooidata.se"]
[null,"Sweden SFTI","soren@ooidata.se","2008-02-01",null,"New Requirement","Order currency does not always give the full picture. If ordering in a foreign currency, the relation to the buyer's domestic currency and, more precisely, the exchange rate to apply may additionally be stated.","Add an option to state buyer's domestic currency (or something to that effect) and add exchange rate information for the domestic and order document currencies","soren@ooidata.se"]
[null,"Sweden SFTI","soren@ooidata.se","2008-02-01",null,"New Requirement","Order/Delivery/Requested Delivery_Period: Period start/end dates are not sufficient, also start/end time is needed","Add Requested Delivery_Period Time","soren@ooidata.se"]
[null,"Sweden SFTI","soren@ooidata.se","2008-02-01",null,"New Requirement","An invoice addressee (invoice to) is missing","Add an address to receiver of invoice when different from the Customer Party","soren@ooidata.se"]
[null,"Sweden SFTI","soren@ooidata.se","2008-02-01",null,"New Requirement","Order/OrderLine/Line Item/Delivery: Delivery address is sometimes required on line level (seems to be commonly used in construction)","Add delivery address on line (cardinality 0..1)","soren@ooidata.se"]
[null,"Sweden SFTI","soren@ooidata.se","2008-02-01",null,"New Requirement","Order/OrderLine/Line Item/Delivery/Requested Delivery_Period: Period start/end dates are not sufficient, also start/end time is needed","Add Requested Delivery_Period Time","soren@ooidata.se"]
[null,"Sweden SFTI","soren@ooidata.se","2008-02-01",null,"New Requirement","Order/OrderLine/Line Item/Delivery/Requested Delivery_Period: one occurrence of period start/end dates/times is not sufficient if Partial Delivery Indicator=true","Change cardinality to 0..unbounded","soren@ooidata.se"]
[null,"G.Ken Holman","gkholman@CraneSoftwrights.com","2008-04-01",null,"New Requirement","Note that in deployment I would constrain the item property names to a controlled vocabulary so that sender and receiver are using precisely the same terminology for all facets. ","I'm going to suggest in 2.1 that we add an optional ID to ItemProperty so that the Name can be textual and the ID be from a controlled vocabulary."]
[null,"David Webber","david@drrw.info","2008-05-01","ubl-dev","New Requirement","In looking at the Catalogue XSD - when you generate a complete XML instance per the XSD schema - you get a 2.1MB transaction!!!\n \nClearly - noone is sending 2.1MB to describe one catalogue item (least I hope not!).\n \nSo - when I look at the content - most all of it relates to static CONTRACT related information - that really could be placed into a separate and new UBL transaction - and then simply referenced by an ID.\n \nThis would introduce a new process flow into the information equation - but seems entirely logical.  So if I need to know the contract conditions relating to an item - I can request that.\n \nThe design decision to burden the catalogue exchange with Contract related content (which makes up 90%) - seems counter intuitive - when that could be sent separately on request once - instead of everytime the catalogue entry is updated.\n \nNot only that - but I strongly suspect the Contract information is repetitive - so one contract could cover most all the items in the catalogue - again - dramatically reducing information exchange volume.\n \nThe contract information can then also be aligned to local tax regulations more closely - such as EU VAT - and serve better fit to purpose roles.\n\n"," \nIf you create a new transaction interchange as a supplemental pathway - should be possible to run those in parallel - and since the core components are all the same - would allow people to use simple XSLT to morph to/from as needed.\n ",{"$nulls":4},"Ken says: \nI've found thousands of elements related to <cac:ContractorCustomerParty> through both the document level and the line level ... but I have not found any explicit contract information whatsoever ... only information describing a *reference* to a contract.  The party information is necessarily extensive because of the options offered to describe agents, legal entities, etc.\n\nBut as for simplifying the contract information per se, I don't see where.  Note that my analysis is only based on a search of the term \"contract\" in element names in the XPath files ... of course I may be overlooking the contract information you are referring to.\n\nSo, can you cite for me which contract information you think should be removed from Catalogue when people are defining their own customizations of UBL?  Of course this cannot be \"removed\" in the UBL 2.1 specification, but for a reader of this mail list archive, they should know that any optional item in UBL can of course be deprecated by a customization that dictates to its community of users that an optional element is not included in that community's specification. "]
[null,"Daniel Toffeti","dtoffe@yahoo.com.ar","2008-11-01","ubl-dev","New Requirement","  I had a problem trying to generate JAXB Bindings for OASIS UBLv2 (http://www.oasis-open.org/specs/#ublv2.0) in the Netbeans IDE (version 6.5 rc2). The problem is with some quoted strings, in some strings the quoting is done with opening and closing double quotes with an hexadecimal encoding of E2 80 9C and E2 80 9D, while in the rest of the UBL documents hexa 22 is used for a straight double quote.\n    The three byte quotes seems to be valid UTF-8 since they are displayed with the proper glyph in other text editors, and people from the ubl-dev list confirmed this. But I'm getting an error \"unmappable character for encoding UTF-8\" and the offending strings are displayed as: ?VISA?, ?MasterCard?, etc. in the error output window in Netbeans.\n   The problem seems to appear only within CommonAggregateComponents-2,\nin CardAccountType and CountryType. After suggestion from a ubl-dev list member, I tried with the runtime xsdrt in (http://docs.oasis-open.org/ubl/os-UBL-2.0/xsdrt/) and the problem dissappeared.\n  I had a problem trying to generate JAXB Bindings for OASIS UBLv2 (http://www.oasis-open.org/specs/#ublv2.0) in the Netbeans IDE (version 6.5 rc2). The problem is with some quoted strings, in some strings the quoting is done with opening and closing double quotes with an hexadecimal encoding of E2 80 9C and E2 80 9D, while in the rest of the UBL documents hexa 22 is used for a straight double quote.\n    The three byte quotes seems to be valid UTF-8 since they are displayed with the proper glyph in other text editors, and people from the ubl-dev list confirmed this. But I'm getting an error \"unmappable character for encoding UTF-8\" and the offending strings are displayed as: ?VISA?, ?MasterCard?, etc. in the error output window in Netbeans.\n   The problem seems to appear only within CommonAggregateComponents-2,\nin CardAccountType and CountryType. After suggestion from a ubl-dev list member, I tried with the runtime xsdrt in (http://docs.oasis-open.org/ubl/os-UBL-2.0/xsdrt/) and the problem dissappeared.\n"]
[null,"Nick Hoggard","Nicholas.Hoggard@gen-i.co.nz","2008-12-01","ubl-dev","New Requirement"," \n\nI'm currently using the UBL 2.0 specification as part of an integration project.  So far we have avoided the need to customise the specifications in any way, however I'm struggling with finding the correct location to populate the Head Office Party details for the Seller Customer Party or Accounting Supplier Party elements of the Invoice schema.\n\n \n\nThe scenario we working through is that the Seller Customer Party is a branch of a larger organisation.  It is important to us to know the organisation that the branch is affiliated with, however it is not immediately obvious how to achieve this using the standard UBL specs.\n\n \n\nDoes anybody have any suggestions on how this could be approached?",null,"Thank you for the response to my query last week.  Unfortunately the\nbranch making the sale is both the legal address for the sale, and the\naccounting address.  Most of the branches are individually owned, though\nthey are each grouped into one of 10 parent organisations.  \n\n- Parent 1 (This is the level I'm unsure of how to model)\n-- Branch 1 (Seller Customer Party / Accounting Supplier Party)\n-- Branch 2\n- Parent 2\n-- Branch 3\n... etc\n\nI suspect that you are correct in your comment that I will need to use\nthe UBL Extensions to achieve this - I just thought I might be missing\nsomething as the concept of Head Office Party is not uncommon.  I'm sure\nthat I could use one of the other party elements that you mentioned, but\nI'm concerned that using one that doesn't quite fit will cause problems\nin future if any of these partner organisations start using UBL for\ntheir own purposes.\n"]
[null,"G.Ken Holman","gkholman@CraneSoftwrights.com","2009-01-01",null,"New Requirement","\nBut I'm still thinking for UBL 2.1 we should consider not having qualified data types in order to formally decouple code list conformance from the schema conformance. "]
[null,"Stephen Green","stephen.green@documentengineeringservices.com","2009-01-01",null,"New Requirement","Prior to UBL TC discussion of this, I thought I'd better add my own two cents\nworth: I realise the ordering process doesn't attempt or claim to show all the\naspects of real-life use of the UBL ordering documents (e.g. no attempt to\nshow that an order can be cancelled prior to order response). I agree my\ndiagram version does seem to remove some possibilities but does this matter\nif it is a clarification? Maybe the things it removes can be added back in\nwithout obscuring anything. At the same time it should be considered\n1. include a cancellation before the order response\n2. there is a cycle (pointed out as we tried to use this diagram in TAG TC)\nwhich might need consideration - going from order 'modified' to order\nchange and back to possible modification and so on - is this realistic?\nThe aim with my modified diagram is only to improve the clarity (with paths\nthrough the process not sharing so many steps - different paths having their\nown steps , even if those steps have the same names). I didn't attend to create\na profile as such. Nothing should be missing that is in the original,\njust clearer\npaths. Maybe add order cancellation prior to response and qualify the loop(s).","Revised diagram at http://lists.oasis-open.org/archives/ubl/200901/jpg00000.jpg"]
[null,"Martin Kempe","kempus@web.de","2009-01-01","ubl-dev","New Requirement","I am working on extending UBL for my purposes. I want to describe a transport consisting of two phases within one document (forwarding instructions). Therefore I used \"cac:ShipmentStage\" within the shipment declarations. But I found that you can only store the actual time spend at the individual track. Is that right? I want to define \"estimatedDeliveryTime\" and \"requestedDeliveryTime\" for every part of an ongoing transport. Right now, I am only able to make such specific time declarations in the global definition of the transport within the \"cac:delivery\" element.",null,"From Mark Brown (mark_brown@toll.com.au)... Unfortunately we encountered the same problem for Actual Dates.\nOur solution was to extend the UBL (a Toll Version of UBL 2.0). This is only used internally. The extension created a new element group\n\"TollShipmentStage\" with a very simply structure.\nATD = Manifest/ManifestDetail/cac:Shipment/cac:ShipmentStage[0]/cac:TollShipmentStage/cac:Period[0]/cbc:StartDate\nATA = Manifest/ManifestDetail/cac:Shipment/cac:ShipmentStage[0]/cac:TollShipmentStage/cac:Period[0]/cbc:EndDate\n \nExternally to trading partners we utilise the use of agreed qualifiers.\ne.g\nETD = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:StartDate\n       = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:DescriptionCode[0]/*body = \"ESTIMATED\"\nETA = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:EndDate\n       = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:DescriptionCode[0]/*body = \"ESTIMATED\"\nATD = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:StartDate\n       = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:DescriptionCode[0]/*body = \"ACTUAL\"\nATA = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:EndDate\n       = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:DescriptionCode[0]/*body = \"ACTUAL\"\nThis does rely on duplication of shipment stages though. It requires each leg to be provided twice.\nThis has only been implemented with one trading partner. Most integration occurs within the Toll Group.\n ) Unfortunately we encountered the same problem for Actual Dates.\nOur solution was to extend the UBL (a Toll Version of UBL 2.0). This is only used internally. The extension created a new element group\n\"TollShipmentStage\" with a very simply structure.\nATD = Manifest/ManifestDetail/cac:Shipment/cac:ShipmentStage[0]/cac:TollShipmentStage/cac:Period[0]/cbc:StartDate\nATA = Manifest/ManifestDetail/cac:Shipment/cac:ShipmentStage[0]/cac:TollShipmentStage/cac:Period[0]/cbc:EndDate\n \nExternally to trading partners we utilise the use of agreed qualifiers.\ne.g\nETD = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:StartDate\n       = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:DescriptionCode[0]/*body = \"ESTIMATED\"\nETA = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:EndDate\n       = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:DescriptionCode[0]/*body = \"ESTIMATED\"\nATD = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:StartDate\n       = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:DescriptionCode[0]/*body = \"ACTUAL\"\nATA = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:EndDate\n       = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:DescriptionCode[0]/*body = \"ACTUAL\"\nThis does rely on duplication of shipment stages though. It requires each leg to be provided twice.\nThis has only been implemented with one trading partner. Most integration occurs within the Toll Group.\n )....   Unfortunately we encountered the same problem for Actual Dates.\nOur solution was to extend the UBL (a Toll Version of UBL 2.0). This is only used internally. The extension created a new element group\n\"TollShipmentStage\" with a very simply structure.\nATD = Manifest/ManifestDetail/cac:Shipment/cac:ShipmentStage[0]/cac:TollShipmentStage/cac:Period[0]/cbc:StartDate\nATA = Manifest/ManifestDetail/cac:Shipment/cac:ShipmentStage[0]/cac:TollShipmentStage/cac:Period[0]/cbc:EndDate\n \nExternally to trading partners we utilise the use of agreed qualifiers.\ne.g\nETD = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:StartDate\n       = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:DescriptionCode[0]/*body = \"ESTIMATED\"\nETA = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:EndDate\n       = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:DescriptionCode[0]/*body = \"ESTIMATED\"\nATD = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:StartDate\n       = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:DescriptionCode[0]/*body = \"ACTUAL\"\nATA = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:EndDate\n       = ns:BillOfLading/cac:Shipment/cac:ShipmentStage[0]/cac:TransitPeriod/cbc:DescriptionCode[0]/*body = \"ACTUAL\"\nThis does rely on duplication of shipment stages though. It requires each leg to be provided twice.\nThis has only been implemented with one trading partner. Most integration occurs within the Toll Group.\n "]
[null,"G. Ken Holman",null,"2009-01-01",null,null,"Transport Mode Code has a listID of UN/ECE Rec 16 and it should be rec 19","Change QDT (spreadsheet and schema) to correct recommendation number"]
[null,"Ian Jones","ian.c.jones@bt.com","2007-11-01",null,null,"I am still struggling to understand how we could build a UBL Order message with sub components.  From Tim McGrath's e-mail I believe we may need to handle all of his scenarios as we deal with a very large product set that may be assembled in a number of ways.  Some components will be sold as both an individual order line item and as a sub-line both priced and un-priced.  This is our challenge - we have many business operating units that can mix and match components in different ways and they want to become even more flexible so a simple \"this is the only way\" solution is not possible.  Following from Tim's suggestion I have looked at the catalogue message and I can see how that gives a Bill of Materials structure but that does not solve my problem as the users may not wish to create individual catalogue entries for each of the possible combinations.   My users requirement is for the BOM to be in the order/invoice as that is the model they understand and are comfortable with and do not wish to invest in catalogue messages at this time.\n\n        I know very little about UBL and I am acting as an intermediary so I may have missed Tim's point - what we really need is simple examples of how we would build UBL messages that support as a minimum Tim's scenarios.  I have a fear that we will actually need an open end BOM structure as in the past I worked on an EDI Invoice that had a 6 layer line item structure to accurately reflect the data needed and could contain over 100,000 item lines in 1 invoice."," Items are in UBL seem as information about what is traded. The focus has been on identifing the item, not to model its content. In a UBL Order every Item is attached throug a lineItem, that also can contain a price. Where an Item specifies \"What\", an lineItem specifies the claim details used in the transaction (How many, when do I want it, to what price, etc). If you have a need for structured information about the item without price information there are the following posibillities:\n \n1) Set up your own name-value specification in AdditionalItemProperty and ItemPropertyGroup\n2) Use a new documenttype, like BOM in the ItemSpecificationDocumentReference\n3) Use a catalog document as Tim suggested.\n \nIf none of these fullfill your need I would like to ask whether it would help if we added a SubItem [0..n] inside Item in version 2.1, so you can describe an Item hierarchy."]
[null,"Ole Ellerbæk Madsen","olem@itst.dk","2009-04-16",null,"MissingField","BuyerCustomerParty is missing in CreditNote","Makes Creditnote more compliant with an iinvoice"]
[null,"Ole Ellerbæk Madsen","olem@itst.dk","2009-04-16",null,"Explanation is missing","What is Response.ReferenceID used for"]
[null,"Ole Ellerbæk Madsen","olem@itst.dk","2009-04-16",null,"MissingField","RequestForQuotation is missing a DueDate"]
[null,"Ole Ellerbæk Madsen","olem@itst.dk","2009-04-16",null,"New Requirement","Severity/Privacy classifiaction is missing on line level as well as header level"]
[null,"Ole Ellerbæk Madsen","olem@itst.dk","2009-04-16",null,"New Requirement","Secret/confidential classification is missing on live level as well as header level"]
[null,"Ole Ellerbæk Madsen","olem@itst.dk","2009-04-16",null,"New requirement","Ouatation.quotationLine.AlternateLineItem is missing","Used to give the buyer a secondary choise"]
[null,"Ole Ellerbæk Madsen","olem@itst.dk","2009-04-16",null,"New Requirement","Ouatation.quotationLine.OptilnalIndication is missing","Used to specified whether a line is required"]
[null,"Ole Ellerbæk Madsen","olem@itst.dk","2009-04-16",null,"missingField","CreditNote.CreditNoteLine.AllowanceCharge is missing","Allign with invoice"]
[null,"Ole Ellerbæk Madsen","olem@itst.dk","2009-04-16",null,"missingField","Reminder.ReminderLine.AllowanceCharge is missing","Used to speciy charges. Perhaps a surcharge class is better."]
[null,"Ole Ellerbæk Madsen","olem@itst.dk","2009-04-16",null,"New Requirement","PaymentTerms is missing a Factoring Indicator","There is missing a fixed element to see whether facturing is used"]
[null,"Peter L. Borresen","plb@ebconnect.dk","2009-04-16",null,"New Requirement","PaymentTerms is missing a Factoring Message","Legal requirement for using factoring"]
[null,"Peter L. Borresen","plb@ebconnect.dk","2009-04-16",null,"missingField","Cardinality of signatura should be 0..* in stead of 1..0"]

{"sheet":"New documents","index":1,"n_rows":11,"n_cols":10,"rows_kept":11,"headers":{"footer":["","Side"]},"flags":["formulas_cached_only"]}
["Project","Submitter","Email","Process","Collaboration","Proposed document Name","Definition","PSC Proposed doument Name","Comment","Status"]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","UtillitySpecification","UtilitySpecification is a kind of attachment document used for specifying the extended informations needed by the Utility sector in addition to a standard invoice.\nUTS is therefore a supplement to an OIOUBL Invoice or CreditNote.\nUTS is issued as a selfcontained OIOUBL document using af dedicated OIOUBL profile.","UtillityStatement"]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","CallForTenders","The document used for a Contracting Authority to define the procurement project to buy goods, services or works during an specified period."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","ContractNotice","The document used for a Contracting Authority to announce the project to buy goods, services or works."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","PriorInformationNotice","The document used for a Contracting Authority to declare the intention to buy goods, services or works during an specified period."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","ContractAwardNotice","The document published by a Contracting Authority to announce the awarding of a procurement project."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","QualificationResponse","A message which the procuring organization sends to an economic operator in order to notify its admision or exclusion to/from the tendering process"]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","InvitationToTender","A message sent by the Contracting Authority to an Economic Operator inviting him to tender"]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","GuaranteeCertificate","A document to notify the deposit of a guarantee."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Tender","A message which a tenderer offers a tender to the tendering organization for bid."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Qualification","A document used for the Tenderer to declare things about his own condition."]

{"sheet":"New ABIEs","index":2,"n_rows":45,"n_cols":11,"rows_kept":45,"headers":{"footer":["","Side"]},"flags":["formulas_cached_only"]}
["Project","Submitter","Email","Process","Collaboration","Proposed ABIE name","Definition","PSC Proposed ABIE Name","Reuse ","Comment","Status"]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Utility Specification","UtilitySpecification is the root-element for the document \"OIOUBL UtilitySpecification (UTS)\".\nUTS is a kind of attachment document used for specifying the extended informations needed by the Utility sector in addition to a standard invoice.\nUTS is therefore a supplement to an OIOUBL Invoice or CreditNote.\nUTS is issued as a selfcontained OIOUBL document using af dedicated OIOUBL profile.\nUTS is build to comply with the Danish Legal requirements for the utility sector.\nUTS is a replacement for the eailier OIOXML FSV specification used within Denmark."]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Chargeable Consumption","This class contain the specification for the consumptionpoint. Is there a need for specify more than one consumptionpoint, then use one UtilityChargeableConsumption for each consumptionpoint, so you have several instance of UtilityChargeableConsumption. This could for exampel be a big company, there have severals branches."]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Consumption Point","Content information about UtilityConsumptionPoint and about metering"]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Meter","Information about Meter(s) and meteringdata"]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Meter Reading","Readings of the meterstand on the current meter"]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Chargeable Consumption Line","Specification of óne product. If you need to specifier more than one product, you must specifier one ChargeableConsumptionLine for each product. This could for exampel be necesarry if the customer have to pay both for the cables and the internet connection."]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Utility Item","Informations about a product of consumption"]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Unstructured Price","This class is a alternative to the class Price, and it contain a Tele line"]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Consumption Report","Staticstisc about the consumers consumption and the development in comsumption."]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Consumption Report Reference","Informations about ealiere reports, for exampel last years consumption"]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Development In Consumption","Informations about the consumption developement."]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","On Account Payment","The coming planned a conto payments"]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Energy Tax","Informations about specific enery tax and duties."]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Consumption Average","The Average price included VAT. \nThis clas are suplementary utility specifications, that depending of type of Utility and scenario, needs to be present on a UtilitySpecification, in order to meet the legal requirement and/or to give the Buyer proper informations. Note that these suplementary specifications are related to one common ConsumptionPoint as specified in UtilityChargeableConsumption/ConsumptionPoint above. "]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Correction","The specification of correction, for examples heating correction."]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Extended Specification","The class contain the detailed / extended specification."]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Tele Specification Line","This class contain a tele specifikation on line level. Here you can make up unitprice /itemprice related each service."]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Call","Informations about each call"]
["Utillity","Peter L. Borresen","plb@ebconnect.dk","Procurement","Billing","Duty","Specification of duties - both call duties and time duties."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Qualification Resolution","The result of economic operator evaluation in this tendering process, such as accepted or rejected."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Capability\n","Criteria that should be required to a tenderer in order to evaluate its capacity. "]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Requirement","An action or statement that is imperative"]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Tendering Terms","General tendering terms for this tendering process"]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Appeal Terms","Information about the terms to present an appeal."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Awarding Criteria","Criteria that should be required in order to evaluate a party capacity. "]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Evaluation Criteria","Criteria that should be required to a tenderer in order to evaluate its capacity. "]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Tender Qualification","The evaluation that the Contracting Authority party requests to fulfill to the tenderers."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Request for Tender Line","The goods or the service which is the subject to be procured in the tendering process. 16FEB06 - Specific goods or services expected to be delivered in this tendering process."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Event","A significant occurrence or happening related to an object process, or person."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Completed Task","Completion of a mental or physical effort to a specific purpose in the tendering process."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Contract Prolongation","Information about the possible extensions of a contract."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Required Guarantee","The Information about the bond guarantee of a tender or bid submitter to actually enter into a contract if they are the successful bidder."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Framework Agreement","The information about a tendering framework agreement."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Award Justification","Information needed to justify certain tendering processes"]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Tenderer Party","Information about a tenderer."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Tender Line","Reference to a line on a document"]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Short List","Information about the creation of a short list for a tendering process"]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Motivation","Information about the motivation for an action."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Procurement Project","An endeavour carefully planned to achieve a procurement of goods, works and service."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Business Profile","Distinctive features or characteristics required for a business in the tendering process such as number of employees, number of operating units, business type."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Power of Attorney","Information about the power of attorney."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Tendering Process","The process of a formal offer and response to execute work or supply goods at a stated price."]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Tender Result","The result of the bid opening in the tendering process"]
["Codice","Oriol Bausà","oriol@invinet.org","Procurement","Tendering","Subcontract Terms","Information about the subcontract of a contract."]