7.x-2.x Proposal

I would love to take the lead on development, if you're ok with it. And I'm open to any ideas or preferences you may have in the matter as well.

It may be a little while before I can dedicate some real time to it, but I've been working on an Accounting suite of modules for Drupal (currently a distribution sandbox that mainly uses my Ledger module), so an Invoice component will certainly be necessary sooner or later.

Would you like to get together in an IRC chat sometime to talk about it?

Thanks P.Vogelaar! I will use this issue to flesh out the ideas of this proposal.

Here are my initial thoughts on the 7.x-2.x branch of this module. Let me know what you think...

First, this branch will be a rewrite from the ground up. As such, it will not maintain backwards compatibility with the 7.x-1.x branch during development. Once the main pieces are in place, we can write an upgrade path from 1.x -> 2.x (if needed).

Architecture

The project will be a collection of modules, organized by their function. Similar to the Commerce and Ledger modules, there will be a separation between "model" and UI components, to help organize and compartmentalize functions.

The entity types that it would provide are: "Invoices" and "Invoice Items". Invoices contain a list of Invoice Items, as well as any other fields that the entity needs.

Invoice ownership

Each Invoice would be "owned" by a Drupal user (whoever creates it). The Invoice module would provide each Drupal user the ability to customize their address information, logo, etc, which would be displayed in the viewed invoice.

Customers

Each invoice will need to have a customer name and address information associated with it, so that it can be addressed properly to the recipient. In the 1.x branches of this module, a separate "customer" entity (in essence) is provided, however I think there's a better way to do it...

There are a number of Drupal modules that already provide some kind of "customer" record, so maybe we can find a way to provide integration, rather than implement our own. This is tricky, though, because it requires mapping information from an arbitrary entity type to the fields that we need to display in the Invoice. Perhaps we can add configuration to the Invoice module that allows site builders to configure which entity is their "customer" entity, and then allow properties of that entity type to be mapped to placeholders in the Invoice template. I'm open to ideas on this.

Invoice templates

Initially, it might be easiest to just provide a single basic "view" page that renders a full invoice in a generic fashion.

I like the idea of having multiple invoice templates to choose from, but in lieu of the "Invoice ownership" stuff above, it raises questions about who "owns" the templates. Are they site-wide? Or can each user have their own? Just things to think about... I think we need to discuss this more to see what's necessary.

Also, in the future, perhaps we could provide individual invoice components as panel panes so that Invoice layouts could be customized using Panels.

Other considerations

VAT and other taxes

I think tax support should be provided by separate modules (ie: invoice_vat, invoice_sales_tax, etc), so that site builders have the option of including one, if they need it. Such modules could hook into the Invoice and Invoice Item modules to provide support for tax calculation and UI.

PDF generation

Can we offload the PDF handling (as well as print/fax versions) to the Print module: http://drupal.org/project/print ?

First steps...

I think we can get up and running pretty quickly with this by using similar existing modules as a starting point. The Ledger module does a lot of the same things we'll be doing, so we can save time by copying code and just altering what we need to. For example, the Invoice and Invoice Item entity types would share a lot of similarity to the Transaction and Account Entry entity types in Ledger. Both use the concept of a parent entity that can have multiple child entities.

We can start by creating the Invoice and Invoice item modules (and their UI counterpart modules), which will provide all the functionality and UI necessary for creating and managing Invoices and their items. In addition to providing the necessary entity API functions, they would provide forms for editing entities, a page for viewing an entity, and default Views for admin management lists.

From there we can figure out what needs to happen next... whether it's taxes/pdf support, or what. I'm open to ideas on the best way to go about it. What do you think?

Here is a quick brainstorm of the initial submodules that would need to be written to start with:

Invoice

-Provides an "Invoice" entity type and all core invoice hooks and functions.
-Depends on Invoice Item.

Invoice Item

-Provides an "Invoice Item" entity type.

Invoice UI

-Provides user interface elements for managing Invoice entities (ie: forms and Views).
-Depends on Invoice.

Invoice Item UI

-Provides UI for managing Invoice Items (ie: form element).
-Depends on Invoice item.

Open to all feedback and ideas!

The benefit of making an Invoice entity type is a better overall data architecture. While it is definitely possible to use the Node architecture to represent Invoices, it comes with a lot of other baggage that isn't necessary. By creating an Invoice type, we can be more specific about what an Invoice is, how it works, and what people can do with it.

The Commerce module provides a bunch of entity types: Products, Orders, Customer profiles, etc (http://www.drupalcommerce.org/developer-guide/core-architecture/entities). The decision to make these into entity types instead of nodes makes sense, because each of them has specific goals in mind. The same is true with Invoices.

"Nodes" in Drupal 7+ are generally used to refer to "content". That's a pretty general idea in itself, but it comes with a lot of assumptions. They have a published/unpublished status, and can be "promoted to front page" for example, among many other node-specific things. These are functions that make sense for content like pages, blog posts, and other public-facing stuff, but when you're dealing with items that are more behind-the-scenes, like orders or invoices, you don't necessary need or want all of that. With the entity system, you can still achieve all of that if you want, using Fields and Views, but it isn't forced upon you. You can start with a more lightweight system and build from there.

More info about entities in Drupal 7: https://drupal.org/node/1261744

Regarding the price field in Commerce: could you go into more detail about what you mean?

I agree we should take a look around to see how other modules are dealing with prices, and I have some ideas there too (ie: #1125706: Price Implementation for Commerce 2.x). Generally speaking, though, it would be best to make sure that we minimize dependency as much as possible. I think it will be great to create integration between Commerce and Invoice... it would simplify the responsibilities of both... but they should also be able to operate independently.

To answer your question: yea, I think the "Invoice Item" or "Invoice Line Item" (whatever we call it), would be responsible for storing price information of some kind (and probably quantity too). That still needs some more definition. What kinds of information would we want to store in each item? The Invoice module currently stores line items with the following fields:

• Invoice item id
• Description
• Quantity
• Unit cost
• VAT
• Weight
• Invoice id
• User id
• Creation date

We probably want many of the same. VAT can be added by another module, so that we don't make assumptions about tax requirements (see my comment #6 above). I don't know if we need User id or Creation date, because those would be set on the Invoice itself. The same thing goes for Weight, I think, because the Invoice itself will be managing references to Invoice items, so it will also be storing the sequence that they are arranged in.

So that just leaves:

• Invoice item id
• Invoice id
• Description
• Quantity
• Cost

Are there others that would be needed? All of this is still up for discussion, of course, I'm just proposing an initial path.

@hauptm: I agree 100% that there should be no dependency on Commerce. Ideally, the Invoice module and the Commerce module could be used together. Perhaps that can be accomplished with Rules, instead of any integration modules (ie: when an order is created, create an invoice, and keep it's line items in sync with the order's).

@slashrsm: I also agree that the 2.x branch should use Drupal's theme system for templating.