But what if you want to see all your deadlines within a unique calendar view?

You can use the super calendar

Configuration

After installing the module you can go to

Super calendar → Configuration → Configurators

and create a new configurator. For instance, if you want to see meetings and phone calls, you can create the following lines

Then, you can use the ‘Generate Calendar’ button or wait for the scheduled action (‘Generate Calendar Records’) to be run.

When the calendar is generated, you can visualize it by the ‘super calendar’ main menu.

Here is a sample monthly calendar:

And here is the weekly one:

As you can see, several filters are available. A typical usage consists in filtering by ‘Configurator’ (if you have several configurators, ‘Scheduled calls and meetings’ can be one of them) and by your user. Once you filtered, you can save the filter as ‘Advanced filter’ or even add it to a dashboard.

As usual, you can find code and bug tracker on our launchpad project.

The first, the most common I think, is to copy & paste an existing module (or an empty one), rename it, and replace all the bits to fit your needs. The second is to use an IDE like Eclipse or TextMate or Sublime-text and create or load all the predefined snippets you need.

This requires a little time but still, can be avoided. Also, could lead to errors, typos, etc, and this must be avoided.

Starting from my Plone background where tools like ZopeSkel and Paste (coupled with Buildout ) are  today mainstream solutions for bootstrapping our  development environments and creating new packages, I tried to get rid of this c&p approach.

I released a package called openerp_bootstrap aimed at speeding up the creation of new modules and new features. For the time being there are only two templates ready to be used:

• openerp_newmodule that lets you create a basic generic module
• openerp_theme that lets you create a basic custom web theme

Let’s see how to use them. First of all install openerp_bootstrap using python setuptools or distribute:

sudo easy_install openerp_bootstrap

sudo pip install openerp_bootstrap

After that, a new executable called ‘paster’ will be available. You can list the available templates by running:

# paster create --list-templates
Available templates:
  basic_package:      A basic setuptools-enabled package
  openerp_newmodule:  Template for creating a basic openerp package skeleton
  openerp_theme:      Template for creating a basic openerp theme skeleton
  paste_deploy:       A web application deployed through paste.deploy

As you can see, there are two openerp_* templates. You can use them by calling ‘paster create -t $TEMPLATE_NAME’. When you call it you will be prompted with step-by-step questions that will allow you to customize your module while creating it. Let’s see an example:

# paster create -t openerp_newmodule
Selected and implied templates:
openerp-bootstrap#openerp_newmodule Template for creating a basic openerp package skeleton

Enter project name: my_new_module
Variables:
egg: my_new_module
package: my_new_module
project: my_new_module
Enter module_name (Module name (like "Project Issue")) ['My Module']: My new shiny module
Enter description (One-line description of the module) ['']: A module that does this and that
Enter version (Version) ['1.0']:
Enter author (Author name) ['']: John Doe
Enter author_email (Author email) ['']: john@doe.com
Enter category (Category) ['']:
Enter website (Website) ['']: www.johndoe.com
Enter depends (Dependencies [space-separated module names]) ['']: account
Enter is_web (Is web addon? [yes/no]) ['no']:
Creating template openerp_newmodule
Creating directory ./my_new_module
Copying __init__.py to ./my_new_module/__init__.py
Copying __openerp__.py_tmpl to ./my_new_module/__openerp__.py

And, here we go! We’ll find all the data we need into our module’s manifest (__openerp__.py):

# cat ./my_new_module/__openerp__.py
# -*- coding: utf-8 -*-
{
    'name': 'My new shiny module',
    'version': '1.0',
    'category': '',
    'description': """A module that does this and that""",
    'author': 'John Doe (john@doe.com)',
    'website': 'www.johndoe.com',
    'license': 'AGPL-3',
    'depends': ['account'],
    'init_xml': [],
    'update_xml': [],
    'demo_xml': [],
    'active': False,
    'installable': True,
}

Let’s create a theme now:

# bin/paster create -t openerp_theme
Selected and implied templates:
  openerp-bootstrap#openerp_theme  Template for creating a basic openerp theme skeleton

Enter project name: my_custom_theme
Variables:
  egg:      my_custom_theme
  package:  my_custom_theme
  project:  my_custom_theme
Enter module_name (Module name (like "My Theme")) ['My Theme']: My brand new theme
Enter description (One-line description of the module) ['']: Customer X project theme
Enter version (Version) ['1.0']:
Enter author (Author name) ['']: Mr Foo
Enter author_email (Author email) ['']: mr@foo.com
Enter category (Category) ['']:
Enter website (Website) ['']: www.foo.com
Enter depends (Dependencies [space-separated module names]) ['']: project
Enter has_css (Needs CSS? [yes/no]) ['yes']:
Enter has_js (Needs Javascript? [yes/no]) ['yes']:
Enter has_xml (Needs QWeb XML? [yes/no]) ['no']:
Creating template openerp_theme
Creating directory ./my_custom_theme
  Copying __init__.py to ./my_custom_theme/__init__.py
  Copying __openerp__.py_tmpl to ./my_custom_theme/__openerp__.py
  Recursing into static
    Creating ./my_custom_theme/static/
    Recursing into css
      Creating ./my_custom_theme/static/css/
      Copying +normalized_name+.css_tmpl to ./my_custom_theme/static/css/my_custom_theme.css
    Recursing into js
      Creating ./my_custom_theme/static/js/
      Copying +normalized_name+.js_tmpl to ./my_custom_theme/static/js/my_custom_theme.js
    Recursing into xml
      Creating ./my_custom_theme/static/xml/
      Copying +normalized_name+.xml_tmpl to ./my_custom_theme/static/xml/my_custom_theme.xml

This will create a web module with all the static resources you need ready to be customized.

# cat ./my_custom_theme/__openerp__.py
# -*- coding: utf-8 -*-

{
    'name': 'My brand new theme',
    'version': '1.0',
    'category': '',
    'description': """Customer X project theme""",
    'author': 'Mr Foo (mr@foo.com)',
    'website': 'www.foo.com',
    'license': 'AGPL-3',
    'depends': ['project', 'web'],
    'init_xml': [],
    'update_xml': [],
    'demo_xml': [],
    'active': False,
    'installable': True,
    'web':True,
    'css': [
        'static/css/my_custom_theme.css',
    ],
    'js': [
        'static/js/my_custom_theme.js',
    ],
}

# ls my_custom_theme/static/*
my_custom_theme/static/css:
my_custom_theme.css

my_custom_theme/static/js:
my_custom_theme.js

Was that difficult? And now the most important – but still missing – part: add modules’ contents like views, classes, fields, etc. Using PasteScript ‘local commands’ we’ll be able to add sub-templates for adding new objects and customize them on the fly, doing something like:

# cd my_new_module
# paster addcontent newmodel project.custom.model
[...]
# paster addcontent field project_custom_model
[...]

Wouldn’t be great? That’s all for the moment.

The development package it’s on github. Feel free to fork and contribute back or to submit issues.

NOTE: the package is still in alpha state so it could be a little bit buggy

Here is the clue: you can “easily” inject an handler for a given event (openerp-web specific ones) by doing like this:

openerp.yourmodule = function(openerp) {
    openerp.webclient.on_logout.add_first(
        function () {
            alert('thatsme!');
        }
    );
}

You must pay attention to 2 things particularly:

1. you MUST use “openerp.webclient” and not “openerp.web.WebClient”
2. you MUST use your module name in order to get the JS loaded

This last point is among the few informations you find in the not-so-official docs contained into the web module (see my previous blogpost on how to get them).

Using “add_first” I’m adding an event handler for the logout event which will be executed before any existing handler.

If you look at the original code of the web module you’ll find other “hooks” like “add_last” which in turns add your handler at the end of the queue.

first of all install sphinx if you don’t have it in your system (assuming you are using a linux system):

$ sudo pip install sphinx

or

$ sudo  easy_install sphinx

then you have to compile the docs. Go to the web package doc folder:

$ cd  web/trunk/doc

(if you have downloaded OpenERP trunk following elbati’s how-to you’ll have the web client in this path)

and run

$ make source html

That’s it! Now you can browse the docs by going to the newly generated folder web/trunk/doc/build/html and opening index.html into your favorite web browser.

As any other OpenERP documentation is quite un-finished but it’s a good starting point for skimming trough the new web client capabilities.

UPDATE: docs are now available here: http://planet.domsense.com/docs/openerp-web/en/index.html

Download the script:

 $ bzr cat -d lp:~openerp-dev/openerp-tools/trunk setup.sh | sh

Run the script:

 $ make init-trunk

Wait…

Run:

$ make server

Go to http://localhost:8069

Or to localhost:8069/mobile if you want to try the mobile interface (or even to localhost:8069/?kitten=1…)

Update 2012-03-31

Please everyone note, since OpenERP 6.1 has been released one month ago, the described method will download the trunk branches (6.2).

Correct branches for OpenERP 6.1 are the following:

lp:openobject-addons/6.1

lp:openobject-server/6.1

lp:openobject-client/6.1

lp:openerp-web/6.1

The module we developed is called account_fiscal_position_country, and can be found on apps.openerp.com.

Configuration

Go to Sales > Configuration > Address Book > Localisation > Countries.

Choose a country, and enter the default Fiscal Position for that country.

Usage

Done that, when you create a Sale or Purchase Invoice and select a Partner, the Fiscal Position you defined for the country of the Partner will be selected. Note that the standard OpenERP behaviour is still defined: if you set a specific Fiscal Position for that Partner, that one (and not the one from the Country) will be used.

Sale Orders

To get the same functionality in Sale Orders, install the module account_fiscal_position_country_sale as well. The modules are kept separate to minimize dependencies.

Of course, feedback is welcome! You can use the bug tracker in launchpad for that:

https://bugs.launchpad.net/domsense-agilebg-addons

The module provides two main macro-functionalities:

• Print follow-ups (increasing the follow-up level associated to payment)
• Re-print sent follow-ups

Let’s see how to configure and use the module.

Configuration

First of all, you have to configure the follow-up levels. Going to

Accounting > Configuration > Miscellaneous > Follow-Ups

you open the follow-ups list and can create a new one.

For instance, my follow-up has three levels. This is one of them:

Also, I configured the following two payment terms

 Use

I issued four invoices:

For Thomas Winteler, I used the first payment term (’25% at 14 net days, remaining 30 days end of month’). For Domsense Srl, the ’30 Days End of Month’.

Thanks to account_due_list, you can see the list of payments with their due date, if any. You can find the list at

Accounting > Journal Entries > Payments

Now we can follow-up some payment. Go to

Accounting > Periodical Processing > Billing > Open Follow-Ups

If you print the follow-up at 30 November 2011, you’ll find the following situation:

We developed a new module to better handle the follow-ups. Its name is account_followup_choose_payment and it is configurable through account_followup but, unlike account_followup, it allows to send follow-ups selecting the single (overdue) payments you want to notify to customers.

The module provides two main macro-functionalities:

• Print follow-ups (increasing the follow-up level associated to payment)
• Re-print sent follow-ups

Let’s see how to configure and use the module.

Configuration

First of all, you have to configure the follow-up levels. Going to

Accounting > Configuration > Miscellaneous > Follow-Ups

you open the follow-ups list and can create a new one.

For instance, my follow-up has three levels. This is one of them:

Also, I configured the following two payment terms

 Use

I issued four invoices:

For Thomas Winteler, I used the first payment term (’25% at 14 net days, remaining 30 days end of month’). For Domsense Srl, the ’30 Days End of Month’.

Thanks to account_due_list, you can see the list of payments with their due date, if any. You can find the list at

Accounting > Journal Entries > Payments

Now we can follow-up some payment. Go to

Accounting > Periodical Processing > Billing > Open Follow-Ups

If you print the follow-up at 30 November 2011, you’ll find the following situation:

Now, you can select which payment to follow-up. I select them all, and run the wizard Follow-UP. Here is the result.

Moreover, opening Sent Follow-Ups, you can see the list of previously sent follow-ups, with date and level. By that list, at any time, you can select and re-print the follow-ups, through the Sent Follow-Up wizard.

OpenERP users often require the possibility to send reports to system printers, in order to print the reports on paper directly.

In OpenERP 5, this functionality was implemented by prinjob module. It provided several functionalities, one of these was to automatically send reports to CUPS printers. After the release of OpenERP 6, the module stopped working. At that point, one of the printjob’s authors said that he wouldn’t have ported the module to OpenERP 6, so many users was left empty-handed.

Recently, I’ve picked up the issue again and, after having analysed the problems of porting printjob to OpenERP 6, I decided to realize a module that would have extrapolated the most important functionalities of printjob and better adapted to printing methods of OpenERP 6. So, base_report_to_printer was born.

Configuration

The base_report_to_printer module is downloadable from apps.openerp.com or directly from our code repository. Once you installed it, the Printing menu will appear.

First of all, you have to load CUPS printers in OpenERP. You can use a wizard that retrieves them automatically. You just have to click on Update Printers from CUPS and printers will appear within the available printers list.

In the next step you will configure the reports to send to the printers.

Through the report form you can define the system’s behaviour while producing the report.

You can set a global behaviour, or differentiate it according to the user who’s printing. In the example, the global behaviour defines to send the report to client directly (Send to Client), therefore without sending it to the printer. But if user elbati is printing, the report will be sent to the selected printer (Send to Printer).

You can also define a default behaviour associated to the user, in order to establish whether a certain user, when not differently set, wants to send the reports always to a specific printer or not.

After finishing the configuration, you will just have to click on printing button associated to the report (or launch the report by a wizard or whatever) and the system will automatically send the report to the previously set printer.

Happy printing.

• sale_subscriptions (it allows to sell products of type ‘subscription’ and to generate a new quotation when the subscription ends)
• sale_subscriptions_alerts (by using email_template, the module allows to configure the alerts to send before the subscription ending)
• sale_subscriptions_delivery (it allows to configure the products composing a subscription and to manage the related delivery orders)

In order to install sale_subscriptions_delivery, you must have nan_product_pack among the available modules. This module allows to configure which products have to be delivered when a subscription is sold.

In order to sell a subscription, first of all you have to define the product selecting the ‘Subscription’ field and the related duration (‘Subscription Duration’). The duration is expressed in days, in the example you can see an annual subscription.

If you are using sale_subscriptions_delivery, the ‘Pack’ tab becomes available and you’ll be able to fill the products to deliver. For instance, if you want to sell an annual subscription of a monthly magazine, you have to insert 12 magazines composing that subscritpion:

So now it is possible to sell the subscription creating a new sale order and selecting the ‘Subscription 1′ product in the order line. The system will fill the fields containing the beginning and ending dates automatically.

If you are using sale_subscriptions_delivery, while saving the order, the system loads the products that have to be delivered.

After confirming the sale order, the system creates the scheduled action that will create, when the subscription is about to expire (06/12/2012 in the example), a new quotation containing the data of the expiring subscription, proposing the subscription renewal to the customer:

If you are using sale_subscriptions_delivery, when confirming the sale order, the system creates the delivery order containing the stock moves established by the subscription. In the example, you can see 12 deliveries planned in 12 months:

Moreover, if you installed the sale_subscriptions_alerts module, you are able to configure the email alerts that will be sent to the customer whose subscription is expiring. Clicking on Tools -> Configuration -> Subscription Alerts, you can configure the alerts to send. Along with the “days before expiration”, you have to insert the email template that will be sent. The template is configurable through the email_template module.

After having configured the alerts, when confirming the sale order, the system will create the related scheduled actions that will send by email the expiring subscription alerts.

The modules are downloadable at the following links:

• sale_subscriptions
• sale_subscriptions_delivery
• sale_subscriptions_alerts

Code and bugs are managed on Launchpad: https://launchpad.net/domsense-agilebg-addons

http://simahawk.wordpress.com/2010/10/04/openerp-how-to-add-a-custom-field-to-an-object