diff --git a/account_move_batch_validate/__openerp__.py b/account_move_batch_validate/__openerp__.py index 394effd2d..e2d3fba83 100644 --- a/account_move_batch_validate/__openerp__.py +++ b/account_move_batch_validate/__openerp__.py @@ -36,14 +36,40 @@ This module provides a wizard to post many Journal Entries in batch. it uses the queue system introduced by the OpenERP Connector to handle a big quantity of moves in batch. + + The module account_default_draft_move introdoces a workflow where the + Journal Entries are always entered in OpenERP in draft state, and the + posting happens later, for example at the end of the period. The core + account module provides a wizard to post all the moves in the period, + but that is problematic when there are many moves. + + The posting of a move takes some time, and doing that synchronously, + in one transaction is problematic. + + In this module, we leverage the power of the queue system of the + OpenERP Connector, that can be very well used without other concepts + like Backends and Bindings. + + This approach provides many advantages, similar to the ones we get + using that connector for e-commerce: + + - Asynchronous: the operation is done in background, and users can + continue to work. + - Dedicated workers: the queued jobs are performed by specific workers + (processes). This is good for a long task, since the main workers are + busy handling HTTP requests and can be killed if operations take + too long, for example. + - Multiple transactions: this is an operation that doesn't need to be + atomic, and if a line out of 100,000 fails, it is possible to catch + it, see the error message, and fix the situation. Meanwhile, all + other jobs can proceed. + """, 'website': 'http://www.camptocamp.com', - 'init_xml': [], - 'update_xml': [ + 'data': [ 'account_view.xml', 'wizard/move_marker_view.xml', ], - 'demo_xml': [], 'test': [ 'test/batch_validate.yml', 'test/batch_validate_then_unmark.yml',