Re: [Proposal]: New schema for Invoices

I'm finally getting around to this.

I think Invoice is different than Order in that I may receive an invoice
that is not really attached to an Order. For example, a utility bill is not
really attached to an order, so much as an ongoing account.

To address some of the comments, I have updated the schema at
https://github.com/vholland/schemaorg/blob/sdo-bills/data/schema.rdfa.
Specifically, I

- Added Invoice to the domain for paymentMethod to coordinate with Order.
- Removed payFromAccountId in favor of the existing paymentMethodId.
- Added a property referencesOrder to link an Invoice to one or more Orders
if applicable.

I wrote up some examples at
https://github.com/vholland/schemaorg/blob/sdo-bills/data/sdo-invoice-examples.txt
(using your furnace suggestion).

In the example, I have allowed for an Order to refer to a service. If
people object to that, I can take it out. Currently, one can only
Order/Offer something of type Product.

- Vicki

Vicki Tardif Holland | Ontologist | vtardif@google.com


On Mon, Dec 22, 2014 at 1:28 PM, Tom Marsh <tmarsh@exchange.microsoft.com>
wrote:

>
>
>
>
> *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>
> 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
>
>
>