Hello,

I would like to explain a little bit more why this merge proposal was rejected, in 2 parts: first explaining our policy for merge proposals, then giving some hints about this specific merge proposal.

1. Merge Proposal Acceptance Policy
===================================
There may have been contradicting messages about how and when it is useful to make a merge proposal.
We would like to state this policy very clearly, especially now that extra-addons have been deprecated due to the introduction of OpenERP Apps. So we have now added an official Merge Proposal Acceptance Policy to our contributor documentation:  http://bit.ly/openerp-contrib-mp

Here is the important part:
"""
OpenERP's R&D expects to receive merge proposals from the Community in these areas:
  - patches to correct a bug in an official addons
  - patches to improve an existing official addon, such as extending a feature or adding one

OpenERP's R&D does *not* expect to receive merge proposals from the Community in these areas:
  - addition of an extra feature to an official addons, when the feature
    should really provided by a separate (new) module
  - addition of a new module to the official addons

For these last cases, it is better to put the feature into new modules entirely maintained by their authors in their own Launchpad repository, and published on OpenERP Apps, to be visible by the whole Community. This is totally unrelated to the quality of the proposition: there are tons of great community modules on OpenERP Apps, some of them already downloaded thousands of times!

However, including a module in the official release is a big commitment in terms of review maintenance, support, etc. In addition, it would quickly bloat the OpenERP core if done too often, compromising its agility and maintainability, and thus the future of the product.
On the other hand, by progressively integrating OpenERP Apps better in the product, we should reach the same visibility for Community modules, without incurring these risks.

Therefore the process of including a community module into the official addons is entirely driven by OpenERP R&D based on the product strategy. In addition to features selected by OpenERP Product Managers, features that are considered REQUIRED to use OpenERP in a certain market/domain will also be considered for inclusion.
Deciding whether a feature is REQUIRED is quite subjective, but the following hints are useful:
 - if most established competitors on the given market/domain implement this feature, and
   this domain is normally addressed by official OpenERP addons, then it's likely REQUIRED.
 - on the other hand, if *no* established software competitors on the given market/domain
   implement this feature, then it's probably NOT REQUIRED
This certainly doesn't mean we don't want to innovate (that's the part where Product Managers choose new features!), this is only for deciding that a module is REQUIRED and thus it is *necessary* to include it in the default installations.

Of course, on top of the above, a merge proposal needs to pass the functional and technical review by OpenERP’s R&D, and even though we do our best to process them in a timely fashion, there is no guarantee it will be accepted, nor when.
"""


2. Remarks specific to this merge proposal
==========================================
In approximate order of importance:

- based on your minimal description, it looks like it is a general purpose extra feature that would be a great addition for OpenERP Apps, as explained in the policy, but does not need to be included in official addons now
- the size of the merge proposal diff is large (+1419 lines) compared to the scope, and it looks like you're copying/overriding many columns and methods, namely from account.invoice. Are you sure this is really necessary?
- use of deprecated API elements, for example:
 + wizards using the deprecated wizard system, should be osv_memory based in 6.0+
 + old logging API
 + fields.function has no method=True parameter anymore
- lots of related fields and stored function fields with complicated store triggers.. these increase the size and complexity of the code, are they really all necessary? 
- module name is "Zip" in module manifest
- no description of the features in the module manifest, nor how to use them
- many references to "UPS" stuff, while the module itself looks like it should be generic?
- some remaining commented out code lines, should be removed

I hope this helps,

Thanks!