- From: Tom Marsh <tmarsh@exchange.microsoft.com>
- Date: Mon, 22 Dec 2014 18:28:45 +0000
- To: Vicki Tardif Holland <vtardif@google.com>
- CC: Martin Hepp <martin.hepp@unibw.de>, W3C Web Schemas Task Force <public-vocabs@w3.org>
- Message-ID: <BL2PR03MB1140641A3B72C75264CD4AFE5560@BL2PR03MB114.namprd03.prod.outlook.com>
From: Vicki Tardif Holland [mailto:vtardif@google.com] Sent: Monday, December 22, 2014 8:47 AM To: Tom Marsh Cc: Martin Hepp; W3C Web Schemas Task Force Subject: Re: [Proposal]: New schema for Invoices On Sun, Dec 21, 2014 at 1:02 PM, Tom Marsh <tmarsh@exchange.microsoft.com<mailto:tmarsh@exchange.microsoft.com>> wrote: What is the difference between Order and Invoice? With the use of orderStatus == OrderPaymentDue (or lack thereof for paid invoices/orders), it looks like I can specify the same things that I can with Invoice. How would a publisher know when to use one vs. the other? The Invoice type is intended for cases where there is no original purchase from the entity owed money. For example, credit card or utility bills do not have a single purchase associated with the debt. I am fine with rolling this type into the existing Order, but it should be simple to say "this is a water bill for December" or "American Express is billing me for November". After the new year, I will send along some examples. [Tom] Agreed on the use cases. I was expecting those to be modeled as orders for services, which is why I suggested we might want to extend the range of orderedItem to include Service. Assuming that we added Service to the range, separated out paymentStatus, and made Invoice inherit from Order with just the addition of the billingPeriod property, for the water bill example, you would end up with something like: 1) A Service (+ offer) to describe the water service, the service location, etc. 2) An Invoice that used the totalPaymentDue, minimumPaymentDue, accountId, etc. properties from Order to describe how much was due and when. The billingPeriod from Invoice would specify that it was December that was covered by the bill/invoice. As another example, let’s say that I buy a new furnace where there is a down payment before installation and then a final payment after installation. Then you would have something like: 1) A Product (+ offer) to describe the furnace 2) A Service (+ offer) to describe the installation (assuming the contractor separates out labor & materials) 3) Two orders (or, if you prefer, two versions of the same order): one to describe the down payment and one to describe the final payment. I would expect both orders to have almost identical properties, differing only in totalPaymentDue, paymentDue, and description (which would likely be the only way to describe that one was a deposit and the other was a final payment). The order(s) could equally well be Invoices, but since there is no billing period, the types are synonymous in this scenario. BTW, you have a typo on the label of some of the ranges (e.g., for totalPaymentDue), which are labeled as “Domain: “ instead of “Range: “ Thanks for the heads up. I'll clean these up. - Vicki Vicki Tardif Holland | Ontologist | vtardif@google.com<mailto:vtardif@google.com>
Received on Monday, 22 December 2014 18:29:15 UTC