Royal Bank of Scotland selects Accountis for e-invoicing

The Royal Bank of Scotland (RBS) is implementing technology from Fundtech-subsidiary Accountis to provide bank-branded electronic invoicing services to its corporate customers.

The Accountis platform uses UBL standards for its documents.

RBS has signed a multi-year contract for Accountis’s electronic invoice presentment and payment (EIPP) technology which it will use to provide VAT-compliant e-invoicing services to corporate customers in the UK.

The application provides detailed status information – such as proof of delivery, acceptance, query and approval status – for all documents involved in a business transaction, from purchase order to invoices. The service also provides real time dispute management.

Accountis says RBS customers that implement the service will be able replace slow and costly paper-based processes with a faster and more environmentally-friendly technology. It also facilitates the bank provision of invoice-based financing services.

“For our customers we see e-invoicing as a fast-track to saving time and money,” says Ian Watkinson, head of e-invoicing, RBS. “In addition to eliminating paper and automating manual processes, users of the service will quickly benefit from real-time document management, faster settlements and better working capital optimisation.”

Watkinson says e-invoicing is a “strategic addition” to the bank’s product portfolio.

“By offering additional transaction services such as e-invoice delivery, we will gain greater visibility of our customer’s end-to-end, financial supply chain transactions. This will help us to improve our understanding of their business and strengthen our long-term relationship,” he adds.

Source: http://www.finextra.com/fullstory.asp?id=18595

ESB Interoperability Standards

Thousands of Enterprises worldwide have adopted the principles of Service Oriented Architecture (SOA). SOA provides an architectural approach that brings the flexibility and agility required by today’s global business environment. An Enterprise Service Bus (ESB) is a vital ingredient of SOA that facilitates the interaction of business services by mediating the message exchanges between them.

ESB infrastructure products are available from a number of software vendors, but there is a lack of consistency between them when it comes to standards support. This has led a number of ESB customers to ask for an industry-wide agreed list of standards supported by an ESB. This Whitepaper documents the essential standards requirements for an ESB, using a scenario-based approach.

ESBs extend the capabilities of SOA and advance the realization of SOA. Mediations can be employed to facilitate interactions between mismatched service requesters and providers. The ESB also provides a common model for accessing, managing and administering system-wide services.

Today’s fast-paced business world demands the ability to change and adapt rapidly. With an Enterprise Service Bus, you can connect your business applications and processes quickly and easily as you respond to business challenges and opportunities when they arise.

By adopting a standards-based approach leveraging Web services a customer has the assurance of the flexibility and the interoperability that such a strategy provides.

Read the full Whitepaper by Thomas Freund and Peter Niblett here: http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-esb-interop/ESB_Interop_Standards_WP_060208.pdf

The Global Justice Reference Architecture (JRA) ebXML Messaging Service Interaction Profile Version 1.0

The purpose of this document is to establish a SERVICE INTERACTION PROFILE (SIP) based on the ebXML family of technology standards.

A Service Interaction Profile is a concept identified in the Global Justice Reference Architecture ([JRA2]). This concept defines an approach to meeting the basic requirements necessary for interaction between SERVICE CONSUMERS and SERVICES. The approach utilizes a cohesive or natural grouping of technologies, standards, or techniques in meeting those basic interaction requirements. A profile establishes a basis for interoperability between service consumer systems and services that agree to utilize that profile for interaction. A Service Interaction Profile guides the definition of SERVICE INTERFACES.

In an SOA environment, every service interface shared between two or more information systems should conform to exactly one Service Interaction Profile. Service consumers who interact with an interface should likewise conform to that interface’s profile. The profile discussed in this document is based on the ebXML family of technology standards, defined as follows:

• OASIS ebXML Messaging Services, Version 3.0: Part 1, Core Features, 2007 [ebMS3]
• OASIS ebXML ―Conformance Profiles Gateway RX V3 or RX V2/3 for e-Business and e-Government applications [ebMS3-PROFILES]

• OASIS ebXML Business Process Specification Schema v2.0.4 [ebBP]

• OASIS ebXML Collaboration-Protocol Profile and Agreement Specification Version 2.0 [ebCPPA v2]

• The Web Services Interoperability Organization (WS-I) Basic Profile, Version 1.1, dated April 10, 2006 (noted in this document as [WS-I BP]), ebXML Messaging Services v3 is conformant with Section 3 MESSAGES and Section 6 SECURITY and all standards that those sections reference. Section 4 of WS-I Basic Profile does NOT APPLY to ebXML. ebXML does not specify WSDL for service descriptions and service bindings.

• The WS-I Attachments Profile ([WS-I AP]), Version 1.0, and all standards that it references

• The WS-I Basic Security Profile Version 1.0 (dated March 30, 2007, 37 noted in this document as [WS-I BSP]), all current Token Profiles, and all standards that they reference.

For more information please visit: http://it.ojp.gov/topic.jsp?topic_id=242

Make use of WS-I resources to test for Web service interoperability

The Web services technology has promised us to provide a high level of interoperability between software components. But what does this mean in practice?

In theory Web services are especially designed to offer “reusable” features that are discovered and bound at runtime using technical “loose coupling.” The Open Solutions Alliance (OSA) has been formed expressly to help speed the creation and adoption of integrated, interoperable business applications based on open source. The OSA recommends that each vendor or project lead should carefully think about which functions in their to need to be triggered by other applications, and ensure that they are exposed in a loosely coupled way so customers and integrators can take care of implementing the process. These functions should be exposed as a service and should be implementation language neutral, so for example a PHP application can invoke a feature in a Java application.

Having in mind that Web services are used by consumers unknown at design-time, and looking at the “Publish-Discover-Invoke-Paradigm” based on standards it will become evident that Web services are fundamentally about “interoperability”. In reality, however, the “standard” protocols are not standard enough to ensure automatic interoperability. Most of the risks stem from subtle variants in implementing a same standard or some borderline option of it (“corner cases”), and from different approaches in integrating several of these standards in the same implementation. Other problems rely on the different programming language implementations of data types like “Date”, “Floating Point” or “BigDecimal”, e.g. when looking at Java & J2EE vs. Microsoft .Net with C++ or C#.

There are many definitions in the industry and academic research that tell us how to interpret the term “interoperability” for Web services. In Microsoft’s “Pattern & practices for building interoperable Web services” book we can find a definition that has been adapted by most of the tool providers in this area:

“An interoperable Web service is one that works across platforms, applications, and languages as well as with Web services from other vendors.”

However, we saw above that interoperability needs consensus, a clear understanding of requirements, and adherence to specifications. In response to these needs, the Web Service Interoperability Organisation WS-I was founded.

WS-I is an open industry organization “chartered to establish Best Practices for Web services interoperability, for selected groups of Web services standards, across platforms, operating systems and programming languages”. The organization is a consortium of Web services companies to provide guidance, recommended practices, and supporting resources for developing interoperable Web services in the SOA world…

To read the full article by Klaus Berg please visit:
http://www.javaworld.com/community/?q=node/828

European eProcurement Capabilities Survey

The eProcurement Forum, the DG Internal Market and Services and IDABC e-Invoicing and e-Ordering project of the European Commission and the CEN Workshop on Business Interoperability Interfaces for Public Procurement are kindly inviting you to complete an eProcurement online questionnaire.
The objective of this survey is to gather information about existing eProcurement systems and supporting tools that can help fulfil the vision of seamless, standards-based electronic public procurement across Europe as committed in the i2010 eGovernment Action Plan. With this aim we are inviting you to provide us with some information about the capabilities of your organisation and your initiatives on this domain, including the usage or development of IT applications.

For more information visit:
http://www.epractice.eu/info/82/6

You can access the survey by connecting to the IPM Tool at:
http://ec.europa.eu/yourvoice/ipm/forms/dispatch?form=eProcurementSurvey

Information R/evolution