<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="country-region"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"/>  <style>  </style>  </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> Fellow microformat enthusiasts,<o:p></o:p> <o:p> </o:p> I work in Intuit’s Technology Innovation Group, which explores new and emerging technologies and helps Intuit product teams adopt them. (For those outside <st1:place w:st="on">North America</st1:place>: Intuit is the leading vendor of financial and tax software for individuals and small business. In <st1:place w:st="on"><st1:country-region w:st="on">America</st1:country-region></st1:place>, our products Quicken, QuickBooks and TurboTax are household names.) <o:p></o:p> <o:p> </o:p> Our group is interested in microformats – specifically the possibility of a receipt microformat. We believe that a receipt format for online stores could significantly reduce data entry for our users. <o:p></o:p> <o:p> </o:p> Following the “why a new microformat” process:<o:p></o:p> <o:p> </o:p> The PROBLEM: our users currently enter expenses into our software manually, even when the information is available in digital form. This is done in lump sums, which hinders further analysis and categorization. All this can be automated. (Indeed it is already automated through screen scraping, but this is unreliable, error-prone and not future-proof.)<o:p></o:p> <o:p> </o:p> Is there a SIMPLER PROBLEM? Some components of a receipt are simpler problems that have been solved. Billing address and delivery address are obviously vCards; price could use the proposed hCurrency. But data such as the line items (Product X in quantity N at price Y) would not make sense out of the context of a “receipt”. (hProduct and hListing obviously come close and might possibly be integrated somehow.)  In short, we don’t see a simpler problem to solve, since we already have some microformats in place.<o:p></o:p> <o:p> </o:p> Has the problem been SOLVED? As far as we can tell, no. Martin Owens and Joe Osowski exchanged ideas on this microformat earlier, and we’d like to build on their work. (<a href="http://microformats.org/discuss/mail/microformats-new/2007-May/000394.html" title="http://microformats.org/discuss/mail/microformats-new/2007-May/000394.html">http://microformats.org/discuss/mail/microformats-new/2007-May/000394.html</a>)<o:p></o:p> <o:p> </o:p> In case the purpose of the microformat is not clear, imagine the following use case: The customer, a Quicken user with the (hypothetical) Quicken Browser Toolbar, is shopping at Amazon.com and is ready for checkout. After paying for the purchase, the customer wishes to enter the data into Quicken. Instead of manually typing everything into Quicken, the customer selects “Save receipt” from the Quicken Browser Toolbar, which imports the expense into Quicken. Another possibility is to use a JavaScript-powered button to copy the receipt to the clipboard and support pasting the microformat from within Quicken.<o:p></o:p> <o:p> </o:p> We are looking forward to your input and participation. Has the problem been solved before? Are there other useful microformats already in existence that could be included in a receipt format? <o:p></o:p> <o:p> </o:p> Thanks,<o:p></o:p> <o:p> </o:p> Leif Arne Storset<o:p></o:p> Technology Innovation Group, Intuit<o:p></o:p> </div> </body> </html>