The Model

The Siwapp core model classes are under continuous development and subject to lots of change. In the meantime, here are some notes on how it's implemented, possible ideas for a not-so-far future, how the inheritance scheme is defined, which methods are suppossed to be there, etc...

Default Bundles

There are a few, but regarding the invoicing-related models, Siwapp comes with four bundles:

• SiwappCoreBundle: This is the one that holds as much of the common functionality as it's possible. Other invoicing-related modules are going to use it by inheritance (Invoices, Recurring Invoices and Estimates for starters). Think of it as an abstract bundle with methods, entities, meant to be inherited by the actual bundles that will do the job.
• SiwappInvoiceBundle: This is a bundle which describes and operates on standard invoices.
• SiwappRecurringInvoiceBundle: This is a bundle which describes and operates on Recurring Invoices. Recurring invoices are templates to generate standard invoices under certain conditions of periodicity.
• SiwappEstimateBundle: This is a bundle which describes and operates on estimates.

SiwappCoreBundle

AbstractInvoice

Take into account that a Recurring Invoice generates Invoices and that an Estimate will probably be promoted into an Invoice so these three models share a common structure and methods. An AbstractInvoice defines common data and methods, and: * Has no database representation * Has relationships with no other model * Has custom methods, intended to be used by the models inheriting from it.

Custom methods

• addNewItem: to add an item to the invoice-like object. It calls the addItem method of the class that inherits it. Takes care of the inverse relationship (by calling the setParent method of the item) and recalculates amounts.
• removeItem: takes either an item object or an index as an argument. remove it from the items collection and recalculates amounts
• getRoundedAmount
• getDecimals
• calculate: calculate certain values aggregating them throug the items of the object.
• setAmounts: self-explanatory
• preUpdate: Before updates and persists, it checks invoice-like object status, by calling its checkStatus method (which has to be present)

AbstractItem

All invoice-like objects have related items that describe the purpose of the invoice (in short words, what you are selling). An AbstracItem:

• has no database representation
• has no relationships whatsoever
• Has custom methods, intended to be used by the models inheriting from it.
• its descendants must implement a getParent method

Custom methods

• recalculate: It's called right before updates
• getXXAmount:
• getTaxesPercent
• a few __ magic methods to provide dynamic tax amounts and the sort

Tax

Taxes can be of different types. Usually they represent an increase of the final price of a product in a certain percentage. Other times is a percentage based from the base amount of the invoice that the buyer must retain to give it to the State, which reduces the final amount received by the seller.

• Do have representation in the database.
• They have no custom methods and no defined relationships (although other instances do have an unidirectional relationship with taxes).

This does not mean that you can not repeat class names, but you need to know if they already exist and use them in the proper context.

What now??

As you can probably see by now, this is a heavily work-in-progress thing. At the time being, let's just say that, if you want to take advantage of the core bundle, and build some invoice-items like model structure, the only thing you need to make sure is to

• add the custom methods setParent method to your 'item-like' object and the checkStatus method to your 'invoice-like' object.
• to add or remove items, use always the addNewItem, removeItem methods from the AbstracInvoice.