This problem is exacerbated in the European Union where the requirement to document and validate value-added taxes (VAT) results in the creation and exchange of over 30 billion invoices every year, at an estimated cost of €30 per invoice.  Add to that staggering cost environmental pressures to “go green” and reduce waste.  Add to that the loss in business agility resulting from delivery times and internal routing.  And then add to that the human errors attendant with the transposition of data from these paper documents to electronic systems, which can cost over €100 per incident.  Facing a global economic recession, the benefits of moving to electronic, or e-, invoicing systems are real: expected cost reductions on the order of 80%!

The EU acted in 2001 to harmonize invoicing legislation and encourage the use of e-invoicing across all 25 EU member states (Council Directive 2001/115/EC ).  These regulations mandated a common set of master data fields in addition to the use of technologies to better manage the integrity and authenticity of invoice content.  Yet even with this harmonization framework, there are still over 200 e-invoicing systems in place all over Europe, making it very difficult to exchange electronic invoices across national borders.  Given this challenge, the CEN/ISSS Workshop on Compliance of eInvoices works to create standards and best practices for a more universal solution that can be implemented on a broader scale and provide for improved accessibility, efficiency, and cost-savings. 

A solution based on the PDF file format (ISO 32000) and Adobe LiveCycle ES is a good example of those best practices in action.  LiveCycle Enterprise Suite is built on open standards like PDF and XML.  LiveCycle ES can also protect integrity with digital signatures; import data into a PDF document; archive those documents with the ISO ratified PDF/A format; distribute and then also process, verify, and validate e-invoices on the way back in.

Nick Pope, Technical Editor of the CEN/ISSS Workshop on Compliance of eInvoices, had this to say about the solution:  “By combining two de-facto standards – XML for data portability and PDF for human readable documents – with the power of digital signatures, intelligent PDF supports trading between virtually any two partners with fidelity and easy accessibility.”

E-invoicing systems based on LiveCycle ES have already been successfully deployed by several organizations.  Poste Italiane estimates that more than 1.5 million pages have been converted to digital resulting in substantial cost savings.  Cuatrecasas, Spain’s second largest law firm, has reduced invoicing costs by thousands of euros annually.  And Europcar leveraged e-invoicing to not only reduce costs but also improve interoperability with their clients' ERP systems, enhancing the customer experience.

To read more about Adobe’s e-invoicing solutions using PDF and LiveCycle ES, please read the whitepaper, “Applying best practices for secure, automated electronic invoicing.”

Other links:

• E-Invoice Gateway
• LiveCycle Digital Signatures
  

Tags:Adobe,e-invoicing,digital signature,electronic signature,LiveCycle,PDF

Repetitive Code

The form had a large block of script that executed before print that looked like:

if (Page1.InvestProdSupp.InvestProdSupp1.MplsInd.rawValue == 0)
   {Page1.InvestProdSupp.presence = "hidden";}
   else
   {Page1.InvestProdSupp.presence = "visible";}

if (Page1.CompMan.CompMan1.MplsInd.rawValue == 0)
   {Page1.CompMan.presence = "hidden";}
   else
   {Page1.CompMan.presence = "visible";}

if (Page1.Oversight.Oversight1.MplsInd.rawValue == 0)
   {Page1.Oversight.presence = "hidden";}
   else
   {Page1.Oversight.presence = "visible";}
...

This pattern shown 3 times above was repeated 31 times in the method.  A total of around 155 lines of code. Whew.  I enjoy writing code as much as the next person, but this repetitive code is tedious and error prone.  Added or removed a new subform? Don't forget to update this script. Copy and pasted some script code?  Hope you updated all the relevant pieces correctly.

The general pattern is that there are a bunch of fields called "MpIsInd" under nested subforms.  When the value of this field is zero, hide the parent subform, otherwise make it visible.  Here are two alternative approaches:

Solution 1: Use Recursion

We could define a method to recursively search for fields called "MpIsInd" and apply the logic to each one we find:

function printPrep(vObject)
{
    // Have we found the trigger field?
    if (vObject.name == "MplsInd")
    {
        if (vObject.rawValue == 0)
            vObject.parent.presence = "hidden";
        else
            vObject.parent.presence = "visible";

        // Once we've found the field, we can exit early.
        return;
    } else if (vObject.className == "subform")
    {
        // Call this method recursively for each child.
        for (var i=0; i<vObject.nodes.length; i++)
            printPrep(vObject.nodes.item(i));
    }
}
// Set visibility based on all the nested MplsInd descendents
printPrep(Page1);

The end result is 21 lines of script instead of 155 -- and a form that is easier to maintain.

Solution2: Use wildcards in SOM

But recursion is not for everyone.  It certainly would not come easily to a novice script writer

The form author could also have used SOM expressions to find all the MplsInd fields.  We are used to using the wildcard character (*) inside braces to indicate "all occurrences". e.g. po.item[*].subtotal.  I suspect it is not widely known that the wildcard character may also appear in place of an element name to indicate "all elements".  Using the wildcard this way, our SOM expression to find all MplsInd grandchildren of Page1 is : Page1.*.MplsInd.

Given that these fields occur as either grandchildren of Page1 or as great-grandchildren, we can use two calls to resolveNodes() to find them:

// Generate lists of the descendant MplsInd fields...
var vList1 = xfa.resolveNodes("Page1.*.MplsInd");
var vList2 = xfa.resolveNodes("Page1.*.*.MplsInd");
for (var i=0; i<vList1.length; i++)
{
    var vChild = vList1.item(i);
    vChild.parent.presence =
                  vChild.rawValue == 0 ? "hidden" : "visible";
}
for (var i=0; i<vList2.length; i++)
{
    var vChild = vList2.item(i);
    vChild.parent.presence = 
                  vChild.rawValue == 0 ? "hidden" : "visible";
}

Relative SOM expressions

There are buttons on the form that insert subforms after the current ancestor subform.  The click event script looks like:

fields.Page1.RevSec.RevSec2.Table1.Row1.Table2.Row1.Cell1::click - (JavaScript, client)fields.Page1.RevSec.RevSec2.Table1.Row1.instanceManager.insertInstance(this.parent.parent.parent.index+1);

That is pretty verbose.  A more readable form of this would use relative references to the instance manager and to the ancestor subform:

fields.Page1.RevSec.RevSec2.Table1.Row1.Table2.Row1.Cell1::click - (JavaScript, client)
Table1._Row1.insertInstance(Table1.Row1.index+1);

Resolving SOM expressions involves what we call "scoped matching".  In this case, the starting context is the Cell1 button (the field hosting the script).  When asked to find Table1, we look for a match by looking at the children of Cell1.  If not found, we expand the scope of the search by moving up the hierarchy and checking the parent element: Row1 and the children of Row1.  This continues until we encounter Table1.  Note that because there were two Row1 elements in the hierarchy, we differentiated them by including Table1 in the SOM expression.  Note also that we did not worry about which instance of Row1 was returned.  The scoped match will find the direct ancestor before any of its siblings.

The replacement code found the instance manager using its name: _Row1 whereas the original used Row1.instanceManager. Using _Row1 is a better practise, because when there are zero instances of a subform, the search for Row1 will fail, whereas _Row1 is always available.  The naming convention for instance managers is the subform name prefixed with an underscore.

Locking a form

The form had a script to lock all the fields in the form:

function lockForm(sState){
    try{   
        // Get the field containers from each page.
        for (var i = 0; i < xfa.layout.absPageCount(); i++) {
            var oFields = xfa.layout.pageContent(i, "field");
            var nodesLength = oFields.length;
            // Set the access type.
            for (var j = 0; j < nodesLength; j++) {
                var oItem = oFields.item(j);
                if (oItem != this) {
                    oItem.access = sState;
                }
            }
        }
    }catch(e){
        app.alert("Error in function lockForm() - " + e);
    }
}

Notice that this script is as efficient as possible when it loops through the children in a list. It declares a variable to hold the size of the list, and uses that variable in the "for loop". The advantage of doing this is that in a "for loop" the condition gets evaluated for each iteration of the loop.  It is more efficient to reference a JavaScript variable than it is to evaluate a list.length property.  If you have a "for loop" in an area of performance critical code, this is good practise.

Notice another clever part of the script -- it makes sure not to lock the current field.

Unfortunately, it was hard to tell how the script was actually used, because it was not referenced anywhere on the form.  But a couple of observations:

As of Reader 9.0, the access property is now available on subforms.  If your target version is Reader 9, you can code: subform.access = "readOnly" and the result will lock all the descendant fields of the subform.  Setting this property on the root subform would lock the entire form -- in one JavaScript statement.

Removing a Subform

The form has buttons to remove subform instances with code that looks like this:

fields.Page1.RevSec.RevSec2.Table1.Row1.Table2.Row1.Cell2::click - (JavaScript, client)
fields.Page1.RevSec.RevSec2.Table1.Row1.instanceManager.removeInstance(this.parent.parent.parent.index);

For starters, we can simplify the SOM expressions as described above. But the other problem is that this particular Row1 subform is defined to have a minimum of one instance.  This means that if the user clicks on the button to remove the last instance of Row1, Reader will generate an error.  The way Reader handles JavaScript errors is to write them to the JavaScript console.  The end user does not get an indication that there was an error.  But in the console you will see:

GeneralError: Operation failed.
XFAObject.removeInstance:1:XFA:fields[0]:Page1[0]:RevSec[0]:RevSec2[0]:Table1[0]:Row1[0]:Table2[0]:Row1[0]:Cell2[0]:click
The element [min] has violated its allowable number of occurrences.

This version of the script protects against attempting to remove beyond the minimum number of instances:

fields.Page1.RevSec.RevSec2.Table1.Row1.Table2.Row1.Cell2::click - (JavaScript, client)
if (Table1._Row1.count > Table1._Row1.min)
    Table1._Row1.removeInstance(Table1.Row1.index);

If the number of subforms has an upper limit, you should similarly guard code that adds instances.

When testing a form it is good practise to leave the JavaScript console open and make sure that it is clear when testing is complete. 

I've been using the new Beta, v 0.85.0.7935, on my N95-3 for a couple of days now - here are my impressions. Keep in mind that Skyfire is a Beta. There are parts of Skyfire that are clearly not finished and in my opinion keep Skyfire from being a good choice as your primary browser.  But other aspects of Skyfire are incredibly good.  In this review I'm going to speak frankly about the good and the bad.

If you download Skyfire remember that you are a Beta tester.  Skyfire is not a finished product, there are bugs. If you find a bug please report it to the Skyfire team using the Beta Forum.

Great For Video

First of all, if you have any interest in watching video on your phone, get this browser. There's nothing else like it. Sure, S60 3rd edition phones like have pretty good video capabilities out of the box. They do a great job with mobile video formats and can even play Flash 8 FLVs.  But Flash 8 is old and most web based video sites have upgraded to Flash 9 which S60 can't handle by itself.  I've tried most of the major web video sites  and the only ones where videos actually still play in the N95's native Webkit browser are YouTube and Blip.tv.

Skyfire can display almost any web based Flash or Silverlight video or animation. I had no trouble watching videos from Daily Motion, Vimeo, Veoh, Hulu uStream, fastcompany.tv, Blip.tv and of course YouTube using Skyfire.  With a good3G connection or WiFi video playback is very smooth, with no stuttering or hangs at all. The latest Skyfire Beta is also very stable when streaming video. I spent about an hour watching videos on all the sites mentioned above with the longest clip being over 15 minutes long and Skyfire handled them all perfectly. This is a huge improvement over the first Skyfire S60 Beta five months ago which consistently crashed after 2 minutes of video streaming.  The Skyfire team has done a great job of archiving faultless video playback and stability. Skyfire is absolutely the best Flash player I've ever used on my N95. I'm also a fan of the standalone player Mobitubia, but it's limited to Flash 8 and its built in catalog and search functions only work with YouTube.  Skyfire is a full-web browser. Using Google you can find and play almost any video on the web.

Like Opera Mini, Skyfire is a proxy based browser. Skyfire servers do most of the work of interpreting and displaying pages and handling user interactions.  The data sent between server and client is not html but a highly compressed binary representation of just the portion of a page that the user is currently viewing. Skyfire uses Firefox as its rendering engine.  The exact details of how Skyfire works haven't been disclosed but based on hints on the Skyfire forums, I believe that it uses some sort of image based rendering.  Instead of converting pages into a  binary page description language, which is what Opera Mini does, it looks like Skyfire captures an image of all or part of the rendered page,  compresses it and sends it down to the client to display.  There is probably some kind of incremental update that resends just changed parts of the page as needed. You can see evidence of this when scrolling, new parts of the page first appear out of focus and slowly sharpen like a progressive jpeg on a slow connection (image above, left).  Video, which needs to refresh at least 10 times per second, must use a different technique.  Regardless of how Skyfire actually works, pages load very quickly with excellent support for JavaScript and AJAX in addition to Flash and Silverlight. Rendering is very accurate too. Most websites look the same as they do in the desktop Firefox browser.

Video and  JavaScript support and rendering accuracy are the best features of Skyfire at this point in its development. In the rest of this post, I'm going to discuss where I feel the browser needs work.  I'm not doing this to be negative, I think Skyfire is an amazing effort.  It's clear that the Skyfire team has focused their efforts so far on video performance, stability and scaling the back end and they have succeed admirably in these efforts.  What's needed now is attention to  usability, power consumption and connection management.  Skyfire is already the best S60 video player, with some improvement in these areas Skyfire can be the best S60 browser overall.

Inefficient User Interface

The user experience, especially when dealing with pages that are mostly text leaves a lot to be desired.  It takes more key presses and time to get through common tasks like checking email or keeping up with a hundreds of feeds in Bloglines using Skyfire compared with Opera Mini, Webkit or Opera Mobile.  There are a number of different reasons, all of which are basically usability issues:

• Issues with zooming: Skyfire is a "keyhole" browser like WebKit or the Opera browsers in "Desktop" mode.  You have a choice of viewing a web page zoomed out which shows a miniaturized overview of the whole page or zoomed in for a detail view of a small portion of the page.  This design maintains the page's original layout and is great for viewing tabular data or fine detail in images.  Skyfire has five levels of zoom and you can quickly zoom in or out a level at a time with the 1 and 3 keys.  The problem is that Skyfire always loads every page fully zoomed out and requires multiple key presses to get to the point where text is readable. First you press the center Dpad button which changes the virtual mouse cursor to magnifying glass.  Then you have to move the cursor before a focus rectangle appears.  Then you move the rectangle to select the portion of the page you wish to view. As soon as you click a link and load a new page you have to repeat the whole process.  The fully zoomed out view is only useful for navigation.  For most sites it would be faster and easier to start fully zoomed at the top left of the page and just start reading - which is the default behavior in other keyhole browsers.  Both Opera in "Desktop" mode and Webkit  initially load pages fully zoomed in and readable and zooming all the way in or out requires only a single key press. Skyfire seems to be moving in that direction, a new feature in 0.85 is that recognized mobile web sites are loaded fully zoomed in. I hope Skyfire adds an option to do this with all sites.

• Word wrap problems: Like all keyhole browsers, Skyfire reformats text into columns that are narrow enough to fit the browser's width so you can read without horizontal scrolling.  Skyfire's implementation, which they call "SmartFit", doesn't always work.  On many pages including Yahoo Mail (image), gMail, Google Reader and both the classic and Beta versions of Bloglines, Smarfit removes links, truncates text or turns the page into a jumbled mess of overlapping text and images.  The screen shot shows the Yahoo Mail Inbox.  Not only does it look bad but the the title of each message is missing. The title is the link to open the message so with SmartFit on you can't even open your emails.  Fortunately. you can turn SmartFit on and off.  There is even a hotkey to do it with a single keypress.  You often have to turn off SmartFit to navigate and then turn it back on to be able to read text. Toggling SmartFit reloads the page, zooms it out and moves your position to the top of the page so you need more keypresses to find your place and zoom in again. An alternative is to leave SmartFit off all the time but that means that to read text you have to scroll horizontally across each line which I find so frustrating that I refuse to do it.

• No "Fit to Width" mode:  SmartFit is not the same as "Fit to Width"  With SmartFit, when it works, you still have to scroll left and right to navigate around images, etc. when reading text. With "Fit to Width" the page is reformatted and reflowed so that everything fits in a single column the width of the screen. It's not pretty but is much more efficient for reading large quantities of text. Most mobile browsers have a Fit To Width mode including Opera, PIE, Netfront and the BlackBerry Browser.  When using these browsers I generally use Fit to Width 90% of the time, only switching to Keyhole mode to view tables, videos and detail in images. Fit to Width is so much more efficient for reading text, which is what I do most in a browser.

• No dedicated Page Up and Page Down Keys.  Most browsers provide HotKeys that let you perform common actions with one or two clicks.  SkyFire has some Hotkeys; "2" to enter a URL or search phrase, "4" to add a bookmark, "5" refreshes the page, "6" toggles SmartFit, "3" and "1" zoom  in and out respectively,  But what to me is the most critical pair of HotKeys is missing, page up and page down. They are crucial for efficiently reading text. The only way to move through text in SkyFire is line by line. It's easy to undershoot or overshoot the beginning of the next page so that you have to scroll back and forth to find the  last line read.  It's so much faster and easier to just read a screenful, press "Page Down" once, read the next screenful and repeat until you reach the end of the text.

There are also no hotkeys to go to the start page or to your bookmarks.  I realize that there are only 10 keys available, but surely page up and down and returning to the start page and bookmarks are more common actions than saving a new bookmark or entering a URL.  I'd really like to see SkyFire do something like Opera Mini which has both one key shortcuts and two key ones invoked by pressing * or # followed by another key.  I hardly ever use the menus in Opera Mini because everything is just a click or two away.

Battery Life

The technology that is so good at rendering complex animation and video, also seems to require a constant connection and generates constant traffic between server and client.  This obviously increases power consumption.  My N95 gets noticeably warm just browsing the web with Skyfire without even viewing any videos. That doesn't happen with Webkit or Opera Mini. I didn't do a formal battery run down test but my battery lost about 25% of it's charge in just 30 minutes of surfing.  Skyfire has made reducing power consumption a major goal in the development process. Starting with this release the browser drops the connection after the user is idle for five minutes and reconnects when a key is pressed.  Further optimizations will be needed before my phone's battery will get through my typical day of a couple hours of browsing while simultaneously using the music player plus the odd phone call or text.

Connection Issues

SkyFire doesn't manage connections very well on S60 phones.  There is no way to set a default access point for native applications within the OS and SkyFire doesn't have an access point setting either.  So SkyFire prompts for an access point on startup.  Lots of apps do that and I actually like it as it makes it easy to use a faster WiFi connection when available. The problem is that SkyFire prompts three times during startup while other apps only prompt once.  Plus, SkyFire closes the connection after five minutes of inactivity to conserve battery power.  When you wake SkyFire up it tries to reconnect and again prompts you to choose an access point three times. And when using WiFi, reconnection almost always fails for me, prompting indefinitely for an access point without ever reconnecting.

Another connection related issue is that SkyFire uses non-standard http ports (reportedly 1321 and 4243) so it won't work on many mobile networks that require traffic to pass through a proxy, including Spain's Yoigo and the lower priced data plan from T-Mobile USA.  These proxies only pass traffic to "well-known" ports like 80 and 8080. The nonstandard ports also keep SkyFire from working with some public hotspots.

Conclusions

SkyFire is in many ways the most exciting new mobile browser I've seen this year.  The ability to watch just about any web video simply doesn't exist with any other mobile browser, not even Safari on the iPhone. But at this point, SkyFire is quite immature and needs a bit of work before I can recommend it as a general purpose browser. Of course that's why it's in Beta. In fact, most of the issues I've mentioned above are acknowledged by the SkyFire team and are being worked on.  Download SkyFire and use it.  You will enjoy the experience, especially with video.  If you find something that doesn't work right or is harder to use than it should be, do SkyFire and future users a favor and report it on the SkyFire Beta Forum.  You can log into the forum with the email address and password that you registered SkyFire with.  If you haven't registered, you should.  Your bookmarks are stored on the SkyFire servers and will be lost when you upgrade to the next Beta release if unless you are registered.