UBL 1.0 Public Review Comments

UBL 1.0 Public Review Comments

Date: 2004-06-12

Submitting organization: The Swedish Association of Local Authorities, (SALA) and the Swedish Federation of County Councils through the SFTI Inititiative

Submitter: Anders W. Tell on behalf of SFTI, <

Submitting org. website: <http://www.eh.svekom.se/>

Please accept the following comments and change requests regarding UBL Committee Draft, version 1.0, currently in public review phase.

Anders W. Tell

Comments and change requests

UBL Name / Object Class / Justification
InvoicingPeriod / Invoice / The need for this element arises in two situations:
1) when summary invoice is drawn up for several separate supplies of goods or services. The summary method is was asked for, as one option, when the scope of transaction was defined
2) when a credit note is issued, for example triggered by the purchase volume over a period rather than by individual invoices. In this case period is a legal requirement
UBL Name / Object Class / Justification
DeliveryTerms / Invoice / Delivery information would normally be set in contract, order or a response message from the supplier. This new electronic invoice is to work in situations without assumptions on formal foregoing message exchanges - the focus is on many small suppliers applying heterogenous practices. In this case the information is needed to help the receiver of invoices to assertain that how the goods/ services were supplied.
UBL Name / Object Class / Justification
IntitialInvoiceDocumentReference / Invoice / Legal requirement in credit notes. (Only in exceptional cases a period may be used if individual original invoices cannot be identified)
UBL Name / Object Class / Justification
RequisitionistDocumentReference / Invoice / This new electronic invoice does not presuppose that a requisition or order is registered in the buyer’s system. The key reference in the electronic invoice is a reference set by the requisitionist, i.e. a person dealing with the seller. This reference may be a name, a department, a project, a requisition number, etc, and it is used by the buyer’s system to determine who is to deal with the invoice in a work flow type of system. (Hopefully, clever requisitionists will strive towards a system of individual order numbers, but currently the reference does not carry such qualities.)
UBL Name / Object Class / Justification
AllowanceChargeBaseAmount / Allowance Charge / Allowance and chages at invoice level normally, but not always, apply to all invoice lines. Stating an amount on which allowances/ charges are based seems to be acceptable in manual/semi-manual environments. According to VAT rules this amount has to be included in totals for taxable amount per tax category/VAT rate (or exemption, if that applies).
UBL Name / Object Class / Justification
RoundOffAmount / Legal Total / The amount to pay is commonly rounded by systems to nearest amount expressible in notes/coins of the invoicing currency. Although the function should not be necessary in electronic invoicing, companies repeatedly object to changes in the systems because of electronic invoicing being introduced.
UBL Name / Object Class / Justification
PayeePartyName / Payment Means / A seller can sell or transfer the value or “claim” represented by an invoice to a financial institution. The payee’s name and account number(s) are then notified to the buyer in the invoice.
For this mechanism to work it appears sufficient to add party name under payment means. (The alternative, to introduce a new party “Payee”, would generate more overhead.)
UBL Name / Object Class / Justification
TaxCurrencyTaxAmount / Tax Sub Total / VAT has to be stated in invoicing currency and in home currency, if not the same. The requirement of the Swedish tax authorities is that this VAT information has to be broken down per subtotal, i.e. per tax category/VAT rate or extempt. These figures have to be shown explicitly, it is not sufficient that they can be derived or calculated from other data in the transaction.
UBL Name / Object Class / Justification
IntitialInvoiceTaxAmount / Tax Sub Total / This applies to credit note only. The credit note has to explicitly state the amount of VAT, per tax category/VAT rate, in the original invoice(s).
(This is in addition to the VAT figures that applies to the credit note itself.)
UBL Name / Object Class / Justification
PaymentInstructionID / Financial Account / When payment is made, the seller (or other party to whom he has delegated it) wish to have an automatic match against the register of expected payments. Sometimes an invoice number may work, but commonly a specific payment reference is allocated and printed on the invoice so that the buyer can make reference to it when paying. The number may be specific to the payment means or account - OCR numbers is one such example.

Background information

The Swedish Association of Local Authorities/ Federation of County Councils

The Swedish Association of Local Authorities (SALA) and the Federation of Swedish County Councils (FCC)represent the governmental, professional and employer-related interests of Sweden´s 290 local authorities,18 county councils and two regions.

The Association and Federation strive to promote and strengthen local self-government and to create the best possible conditions for the work of their members. Their activities are largely financed by membership fees.

The organisations co-operate on many issues and have several joint political committees and administrative units. This cooperation makes the organisations´ active monitoring of their members interests more effective, and strengthens their role as employers´ representatives.

In May 2003, the two congresses decided to merge the organisations and form a new, joint federation from 1 January, 2007. The new headquarter with joint administrative units will be formed in the beginning of 2005.

SINGLE FACE TO INDUSTRY (SFTI)

Electronic commerce in the public sector in Sweden

Many Swedish local authorities, county councils and government authorities have started trading electronically. You can find information of the ongoing work with electronic commerce in the public sector and the industry standard SFTI (Single Face To Industry) on website http://www.eh.svekom.se.

We are more than happy to provide you with information regarding the work and are at your disposal as regards questions and points of views and can provide further information.

Contact people:

Kerstin Wiss Holmdahl, phone directly: +46(0)8-452 79 75, cell phone + 46 070 548 96 86
e-mail:

Regarding technical issues please contact SFTI technical specialists
e-mail:

Background to Standardisation through SFTI specifications

The purpose of SFTI is to establish a single set of specifications for the interchange of electronic commercial transactions with all public operators, whether at governmental, regional (county council) or local community level. To achieve this, a platform of co-operation has been organised where representatives for public sector (local authorities, county councils etc.) meet with representatives for the suppliers to develop a shared view on the public procurement processes and agree common specifications. The purpose in this co-operation is to identify user requirements, agree on standards and have the resulting specifications recognised among the various industries and groups of users.

The Electronic Commerce initiative started with an analysis of public procurement in a broader scope, identifying the areas of work. As much of the Swedish public procurement takes place under framework contracts, the great bulk of transactions are formed by price list - order/call-off - order response - delivery instruction - invoice. The effect of rationalisation is, consequently, high for these types of transactions. The initial activities focused on developing specifications for this phase of procurement and four SFTI business scenarios for message exchange were defined to satisfy various requirements and ambition levels in system design. A fifth business scenario has also been adopted with two alternatives. In one of them the price list and call-off transactions are replaced by a web-based ordering process and with a copy of the order information and the invoice generated as EDI transactions for processing in the buyer's system.

Also, the scope of electronic commerce has been broadened in that two business scenarios for period invoicing have been added, to cover areas like metered services, payment cards, subscriptions, rental and leasing.

Interest is high in product data exchange, and a first consolidation initiative in two pioneering areas resulted in two product data transactions. In yet another effort, a working group is studying the early phases of procurement, like planning, notice and tendering.

So far, it is in the post-contract phases of procurement that implementations are found. Experience show that savings can be made on the administrative side by merely creating system support for automatic matching of invoices against orders. When combined with a review of the logistic flows and organisation of work, more significant savings are indicated from the implementation projects. The nature of changes requires committed and persistent leadership, though.

For the initial development of SFTI a decision was taken to rely on existing techniques and solutions. EAN Sweden message profiles, based on the EANCOM specifications, were chosen to express the SFTI business transactions. These specifications were already in use by suppliers to the private sector, suppliers that also serve the public sector, and it was seen as a cost-effective way for public sector to initiate EDI, as compared to starting with the general UN/Edifact messages. From a European or international perspective, openness and wide recognition of specifications are crucial and, in this respect, it is believed that EANCOM is an appropriate candidate. For certain areas of procurement the functionality of Edifact-based techniques appears limited and more flexible formats are sought.

For communication the initial choice was X.400. While offering attractive solutions in terms of service and security, software support and cost have proven to be disheartening. The move now is towards standards originating within the Internet community, which puts emphasis on adequate security provisions. For this purpose a set of specifications were developed to secure EDI interchanges (S/Mime), to provide acknowledgement/delivery notification and a gateway for the inter-working of X.400 and Smtp/Mime environments. These specifications have received support also outside public sector, notably by the transportation and construction industries in Sweden, and the promotion of them is now placed with Alliance for Electronic Commerce to give them widest possible recognition.

The Alliance is also promoting the Swedish EDI Agreement, which includes standard General Terms and Conditions and a template document for a Technical Appendix where the technical parameters of an EDI relation can be detailed. The EDI Agreement has been adopted as SFTI and its use is now well under way, bringing conformity in the documentation of EDI agreements in a many-to-many environment.

The idea of a uniform public interface through SFTI has received strong support and the work will continue. So far it has been closely linked to traditional EDI, i.e. the use of UN/EDIFACT standards. New technology, like web-based interactive exchange of information, offer interesting features and will be brought into study with a view to complement the existing work. A first development is the specification of an electronic invoice based on UBL and a transport profile based on ebXML MSS, which has triggered these public review comments.