subject:"Re\: \[OpenERP\-users\] Version 6.0"

Ok, we have the first conclusions of what should be done for a full migration 
from a v5 implementation to a v6 one.

First of all, with Terminatooor scripts, we are used to make initial load of 
data (partners, products, initial stock...) that it's purely the creation of 
new records for each object. This approach, as concluded with RaphaÃ«l Valyi, 
is not useful at all for the full migration between v5 and v6, mainly because 
of workflows and object ids.

So the migration should be pure database to database, with two initial 
options:

--  Modify the schema, tables and relations of an existing v5 database, 
according to the ones of v6
-- Migrate the full data from v5 database into a v6 database already created, 
with OOOR Scripts. Best option from my point of view.

So, the steps (we have missed some, because we have not tried then) we have to 
follow for a migration should be:

-- Study v5 implementation, including:
  o Modules installed and version of them.
  o Database schema.
-- Study v6 implementation, including:
  o Modules installed and version of them. Are they ready for v6?
  o Database schema.
-- Study the differences between both schemas:
  o Names of fields that have changed
  o Table relations diffs between both schemas
  o Table fields diffs between both schemas
-- Prepare the custom migration(s) script(s): Hard work!!!
  o Run the scripts: Hard work too, with a lot of iterative testing.
  o Test the v6 new installation integrity.

So, IMHO, it's not easy and I fully understand OpenERP SA point of view here.
[/u][/b]


Carlos LiÃ©bana Anero
www.ting.es




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61308#61308

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@sharoonthomas

Another example is the 'certification' of modules. The most recent being the
certification of magento openerp integration, where customers pay hefty to
openerp to give them a certified version of a community module (supposedly
with better quality). I assume the module then gets added to
openobject-addons (a branch closed for commit rights to openerp SA employees)
and also made available on ODOO. (Note:This has not happened yet with magento
erpconnect). The customer gets the module, the original developers continue
the development (supposedly without quality) but the customer is not allowed
to get the new improvements because its not certified. He has to use
certified legacy code, because his maintenance contract is otherwise invalid?
Well, is this free as in freedom? I would prefer to call this highest order
restriction! a clear violation of GPL?

I completely agree with you on this, as I noted absuletly the same - just as
the certification idea appeared. It seems, that all of that is going to happen.
This is clear policy of lockin. And the freedom in this case is as in pocket.

Fabien are depressing transparent circulation of information (in case of
updates of software and copyright statements), providing community and general
public with bended truth and disinformation. Completely ignoring the
fundamentals and principles of FOSS. The policy and statements (and their
inconsistency) is getting more and more look alike to those from the big old
proprietary software corps.

Unfortunately general public is unable to follow all the statements and glue
them together to find out what is the reality.

Still I am pleased that more and more community members are noticing the real
situation.

@fabien

https://docs.google.com/leaf?id=0B8I9h53mJ-C_MjkzNThjMDYtMTIyNC00YzViLWI5NzQtYmRmYzIyZDQ3Nzdhhl=en_GB

You are referring to a nonoperational webpage.

And I am really sorry, but your statements are getting more and more unrelated
to the real movements.

m2f

--
http://www.openobject.com/forum/viewtopic.php?p=61309#61309

m2f

___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@albertnan

We offer support for the ERP implementation. We dont differentiate 'certified', 
non certified, commercial/propreitary etc in our implementations. Its one 
support and just one, whether he has a bug in the purchase module, or another 
community module, we fix it.

Flat price or per hour pricing is just a commercial detail and depends on what 
the customer purchases.

@liebana



 -- Study the differences between both schemas:
 o Names of fields that have changed
 o Table relations diffs between both schemas
 o Table fields diffs between both schemas
 -- Prepare the custom migration(s) script(s): Hard work!!!
 o Run the scripts: Hard work too, with a lot of iterative testing.
 o Test the v6 new installation integrity.
 
 So, IMHO, it's not easy and I fully understand OpenERP SA point of view here.


It's the poor coding methodology (Cowboy Coding 
http://en.wikipedia.org/wiki/Cowboy_coding) and process within Open ERP SA that 
make this difficult. Please have a look at this piece of code from tryton sale 
module:

http://hg.tryton.org/1.6/modules/sale/file/0b436b131d56/sale.py#l143

This shows how easily migrations are managed in Tryton because, migrations are 
part of the module's object itself. Easy to maintain, manage and deploy. Tryton 
does not accept contributions which have a schema change and do not provide 
migration scripts along with it.

In my not so humble opinion, OpenERP SA wants to sell the migration scripts, 
and hence dont do the migrations along with the schema changes, and not because 
they really cant do it?

Or, is there something I am really missing here? please correct me if I am 
wrong. I don't understand why you have to make this migration such a complex 
process when the framework already supports it?

@fabien


 (we are not the evil big company you pretend we are 


I agree, OpenERP SA is not 'big' evil compared to many companies out there, but 
the fact remains - from your own examples of failed opensource projects - they 
are also commercial open source projects like OpenERP.

Also fabien are you publishing the migration scripts along with the other SFD 
modules? (Sorry to repeat if you have explained elsewhere)


Sharoon Thomas
Business Analyst  ERP Consultant
CEO at openlabs.co.in




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61311#61311

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0


liebana wrote:
 
 So the migration should be pure database to database, with two initial 
 options:
 

The kn-dati alternative is pure openerp to openerp and should be considered 
also.
data transformation is made on a per-module configuration, which means for me 
that a custom module publisher can include migration configuration (xml) in his 
module, and so we would be able ideally to manage any module combination 
whatever the version of other modules is.
sraps might elaborate on this.

We may need both approaches


Dominique
http://sisalp.fr/demo.html , Hebergement 
http://sisalp.fr/openerp-serveur-gratuit.html




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61312#61312

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

Hi Carlos,

your right, modify the schema isn't the way to go.
Migrate full data is the way to go.

As long as mapping the fields one to one between 2 database, the work is 
doable, but as always with ERP version upgrades, many new fields are added, 
some are deleted, logic is changed and accordingly values get a different 
meaning. (e.g. see changes for accounting types to support new P/L reporting)
Therefore logic should be created into the migration script to fill the new 
fields with some reasonable date and recalculate values based on changed logic.

This is a hugh work. So one needs to know how many migrations will 
approximately be done, before investing time in this piece of migration 
software and which modules should be covered.
Plus as every installation is different there will be parts that the migration 
software can not cover. This can be reported and should be done manually 
afterwards.

So yes,  it's not easy and I fully understand OpenERP SA point of view here 
too. (It's not e.g. internetbrowser software that's to upgrade.)


Jan
www.veritos.nl
www.supportandmaintenance.org




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61313#61313

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@Bounaberdi, and others that are interested in the Migration

By making the migration module we tried to address two problems:
* there was no free migration option at the time of migrating of v4-5. And as 
I understand there is just one around, made around OOR (sorry, I have not 
tested it). But as I understand all of other solutions (those, open and 
proprietary) are just scripts, which are not an option for an advanced user, 
still who is not a developer. As our migration tool is rather a visual (built 
entirely inside OpenERP) scenario constructor, it is pretty simple to install 
it and use it.

* as OpenERP evolves rapidly, correlating to what was said by Bounaberdi, lot 
of modules and models merge/split/disappear. So we saw only one single 
important thing to bring over to a new installation - it is data, of course. 
Custom modules and views need to be revised by developers (guess why...). Data 
is the most valuable thing to preserve.

Still not all data is to be brought along to a new base. With the Migration 
module it is able to split/merge or even create data for new models, and 
connect the data to preexisting records, like countries, etc.

The best scenario is to create configuration manually (there is no other way to 
address all the incompatible changes to the core), and move only part of data, 
which is needed. Usually it is the time of leaving some historical data behind, 
to clean up the base.

We have not thought of supplying the migration scenarios along with other 
modules. This deserves some think-over.

BR

Kaspars
-
http://kndati.lv




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61317#61317

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@sharoonthomas

If understand well, I think you are right and migration can be easier, 
following the example you provided. But, that shows a simple renaming of a var 
(packing renamed into shipment), we have to handle a whole migration carefully.

I think we have to study it deeply, and also I know that Akretion is working on 
a simple tool to truly know diffs between a v5 a v6 instance, this would help a 
lot.




[/code]


Carlos LiÃ©bana Anero
www.ting.es




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61325#61325

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

I guess the Akration tool is only a technical diff tool and that is definitely 
a good start. Perhaps someone of Akretion can comment on this.

But there are several/many changes to the functionality e.g. my example on 
changes in account types to support the new P/L reporting.
This example is even more complex as it has to do with localization and could 
for every country, even per customer be different. (Depended on how accounting 
is set up)

So a migration tool should have a localized part in it too and some data needs 
manual intervention that needs to be reported. At the end migration is not 
doable for normal users, it's a specialized job.


Jan
www.veritos.nl
www.supportandmaintenance.org




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61326#61326

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@janneman

I totally agree with you.


Carlos LiÃ©bana Anero
www.ting.es




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61327#61327

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

Just for the ones that needs some more information about data migration in a 
ERP here is a good overview that covers the area's involved.
http://hosteddocs.ittoolbox.com/Data%20Migration092707.pdf

A must read for everyone who now thinks that migrating is only data mapping 
between 2 different tables. After reading you know that there is more involved.


Jan
www.veritos.nl
www.supportandmaintenance.org




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61328#61328

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0


liebana wrote:
 @sharoonthomas
 
 If understand well, I think you are right and migration can be easier, 
 following the example you provided. But, that shows a simple renaming of a 
 var (packing renamed into shipment), we have to handle a whole migration 
 carefully.
 
 I think we have to study it deeply, and also I know that Akretion is working 
 on a simple tool to truly know diffs between a v5 a v6 instance, this would 
 help a lot.
 


A simple example that shows how tryton migration system is not a general 
solution would be something like this:

- Model M has field F of type integer in module 1 in version 5.0
- Module 2 inherits the same field F and makes it a VARCHAR in version 5.0
- Module 1 has some changes in version 6.0 that make field F integer and in the 
migration process we need to multiply it by 100 (previously its range was from 
0.0 to 1.0 but now they decided 0 to 100 is more intuitive and decimals are no 
longer needed). The migration process of module 1 will try to convert existing 
field which is VARCHAR because module 2 was installed to integer and thus 
migration process will fail.

The only way to avoid that would be that the inheriting module overrided 
auto_init() function and reimplemented all migration code.

The only way I see that a migration process per module could more or less work, 
would be if each field had it's its import migration function. This way, the 
system would not try to migrate fields that are later inherited in another 
module. I also agree that doing schema changes directly is just what we want to 
avoid, otherwise why do we have an ORM?

**Brainstorming Mode**

Haven't thought a about it, but it just comes to my mind something that could 
be a start of a discussion to find out a solution. Let's say that fields, as 
mentioned can optionally have a migration function. This means that fields that 
do not have such a function are migrated AS IS. The rest of the fields could 
have something like this:


class res_partner#40;osv.osv#41;#58;
nbsp; nbsp; _inherit = 'res.partner'

nbsp; nbsp; def _migrate_name#40;self, cr, old_tables, context#41;#58;
nbsp; nbsp; nbsp; nbsp; # In the migration process OpenERP framework would 
rename all
nbsp; nbsp; nbsp; nbsp; # existing #40;previous version#41; tables and 
create the new tables with 
nbsp; nbsp; nbsp; nbsp; # with the correct names. The reference to old 
table names would 
nbsp; nbsp; nbsp; nbsp; # be passed as a parameter to the migration 
function of each field.
nbsp; nbsp; nbsp; nbsp; # This would allow content from model A to be moved 
to model B
nbsp; nbsp; nbsp; nbsp; # in a newer version.
nbsp; nbsp; nbsp; nbsp; old_table_name = 
old_tables#91;self._table_name#93;
nbsp; nbsp; nbsp; nbsp; cr.execute#40;SELECT id, name FROM %s % 
old_table_name#41;
nbsp; nbsp; nbsp; nbsp; for record in cr.fetchall#40;#41;#58;
nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; try#58;
nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; name_int = 
int#40;record#91;1#93;#41;
nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; except#58;
nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; name_int = False
nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; self.write#40;cr, uid, 
#91;record#91;0#93;#93;, #123;
nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; 'name'#58; name_int,
nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; #125;, context#41;

nbsp; nbsp; _columns = #123;
nbsp; nbsp; nbsp; nbsp; 'name'#58; fields.integer#40;'Name', 
migration=_migrate_name#41;,
nbsp; nbsp; #125;
res_partner#40;#41;


What do you think? Maybe this could solve many cases. I'd vote also for having 
a general '_migrate()' function for the model for some rare cases. 
Also a general '_migrate()' function would be needed so, standard behaviour of 
openerp for migration would be to call this _migrate() function for each model. 
The implementation of this function in osv.orm would be to create a record in 
the new table for each record of the old one. If all fields in the model have a 
migration function, _migrate() would just create the records with 'id' filled 
in. This would mean that all NOT NULL attributes should be executed at the very 
end of the migration process.

The system would also need a system to know in what order fields should be 
processed. (For example, to migrate 'total' you may need 'base_amount' to be 
migrated, first). The same could be true between models. And probably some more 
complex needs will arise with the discussion.

More ideas?


Albert Cervera i Areny
http://www.NaN-tic.com
OpenERP Partners

http://twitter.com/albertnan




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61330#61330

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@janneman

Nobody says that it (our migration approach) will fit all the cases. It is just 
an option, which, BTW fits many installations, as most OpenERP setups do not 
handle hundreds of thousand of records.

People just need, what they need, and you can not tell them, that they have to 
purchase proprietary scripts, just because they want to upgrade their ERP with 
basic modules, to a newer version. Ok, basic modules, are not the limit, the 
migration module easily and automatically solves circular references and other 
advanced situations, so it is possible to address most of the cases. And I do 
not care, that somebody, will not be able to create scenario by himself. Here 
comes the service of ours, but we leave an option. If you do not want or do not 
feel like creating scenario yourself, you are welcome, we will create one for 
you.

But stating that it is not viable or possible to release migration scripts, 
just because migration is not a trivial (!!!) task (according to Fabien)... 
Well, you know, ERP as a software class, never is trivial in itself. So 
obviously it is just an excuse, to force you buy something.

Migration is not an easy task, still if somebody managed to implement OpenERP 
in their own company, one will most likely be able to migrate to a newer 
version by using our migration tool. This is what I call a freedom - the 
freedom to choose.

BR
Kaspars
-
http://kndati.lv




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61331#61331

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@scraps

Don't get me wrong, I support a open source migration tool for OpenERP, best to 
have it in OpenERP itself.
The discussion started with data mapping between tables, but in my opinion is 
is much more. That's why I did bring in my comments, so we could together 
brainstorm about the options/solutions we have that covers all issues we see 
and to create the best possible migration tool for V5 to V6 but also for future 
versions.

The comment of @albertca is in line to cover more as only data mapping as it 
dials with inheritance that's an important issue too.


Jan
www.veritos.nl
www.supportandmaintenance.org




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61333#61333

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@scraps, note that I haven't tested your framework, it's in my todo list, so 
maybe it already solves more or less all cases. I think the advantage of having 
the migration process with an external tool instead of inside the modules 
themselves is that it's more flexible when there are exceptions or the default 
behaviour does not fit one's needs.


sraps wrote:
 @albertca
 
 I do not think, that the approach of embedding the migration logic inside 
 module would work, because fields are dependent on each other (think of 
 onchange event), and those may change as well. So it is possible to create 
 the script or scenario manually.
 


I already mentioned the problem of dependencies in my post.


sraps wrote:
 
 The other thing to consider: in many cases enterprise want to add some 
 modules in addition to those which was in the legacy setup. Think of module 
 X, which adds mandatory field ABC (which has no default values) to a model 
 created by other module. What if that module X was not present in legacy 
 setup, but needs to be used on a new one?
 


What's the problem with with doing the migration using the same modules and 
then adding the new ones? Even more, how could that module X work with an 
existing database of the same version if it adds a mandatory field and does not 
have a default value? You will have the same issue installing the module 
whether data is comming from an older version or is from the current one.

Kaspars
-
http://kndati.lv[/quote]


Albert Cervera i Areny
http://www.NaN-tic.com
OpenERP Partners

http://twitter.com/albertnan




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61334#61334

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@albertca


 What's the problem with with doing the migration using the same modules and 
 then adding the new ones?


The problem:if the module if it intended to be installed on a clean database 
without any records in that model. You will not be able to move data and then 
add the needed module.


 Even more, how could that module X work with an existing database of the same 
 version if it adds a mandatory field and does not have a default value?You 
 will have the same issue installing the module whether data is comming from 
 an older version or is from the current one. 


As I said, it is possible to define the value for a field in the receiving 
database, even if the donor do not have one. But this has to be addressed in 
the scenario.




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61337#61337

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0


sraps wrote:
 @albertca
 The problem:if the module if it intended to be installed on a clean database 
 without any records in that model. You will not be able to move data and then 
 add the needed module.
 


Sorry, then IMHO the module is broken and would need to provide a way to solve 
that. But, of course, if we accept that such behaviour is valid, not only do we 
need a migration tool from older versions but a migration tool from current 
versions so one can install the module in an existing database. I don't see 
that as a migration issue between different versions.


Albert Cervera i Areny
http://www.NaN-tic.com
OpenERP Partners

http://twitter.com/albertnan




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61341#61341

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0


albertca wrote:
 
 Sorry, then IMHO the module is broken and would need to provide a way to 
 solve that. 

I think l10n_xx illustrate the case.

albertca wrote:
  I don't see that as a migration issue between different versions.
but this was real life for V4 to V5 migration, and I don't think it will be 
different for V5 to V6.
regards


Dominique
http://sisalp.fr/demo.html , Hebergement 
http://sisalp.fr/openerp-serveur-gratuit.html




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61348#61348

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0


Bounaberdi wrote:
 
 albertca wrote:
  
  Sorry, then IMHO the module is broken and would need to provide a way to 
  solve that. 
 
 I think l10n_xx illustrate the case.
 
 albertca wrote:
   I don't see that as a migration issue between different versions.
 but this was real life for V4 to V5 migration, and I don't think it will be 
 different for V5 to V6.
 regards


Sorry, I meant that I don't think that issue is exclusive of migration 
between versions. It's a problem of the module itself, given that I understand 
a module should (if possible) be installable at any time, including when there 
is data in the tables it modifies.


Albert Cervera i Areny
http://www.NaN-tic.com
OpenERP Partners

http://twitter.com/albertnan




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61350#61350

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@janneman,


Guys,


First: we agree with Carlos Liebana: sometimes you can migrate only some data 
from one OpenERP to an other OpenERP, this can easily be done with 
OOOR/TerminatOOOR scripts or an other tech. But this is not suitable to migrate 
the whole ERP with things like accounting, partial reconciliations etc... (as 
ids, states will changes...)

To achieve full migration, we should indeed migrate the existing database, the 
schema + the data.
Schema evolution is done at 50% by the OpenObject ORM with the --update=all 
option.
Then extra schema changes can be done by modules scripts.

@Sharoon, Just like Tryton, OpenERP handles per module migration scripts, this 
is to be seen here:
http://bazaar.launchpad.net/~openerp/openobject-server/trunk/revision/2722
http://bazaar.launchpad.net/~openerp-bpso/bpso.openerp/migration_script_/revision/2741


I didn't test the Kndati migration tool yet. But if it's per module oriented, 
then that's fine and that could probably be plugged with module initialization 
within the --update=all option. Else, SQL or OOOR/Pythons scripts might be 
called at module init (if OOOR scripts, we could have a method to execute pure 
SQL statements like DDL on OpenERP server, just for the migration purpose).


In any case, how do we make those migration (data + DDL) scripts?
Well, of course, like Sharoon said, I always thought it would have been cheaper 
if migration where thought upfront at each commit (Or well, may be not as so 
many things where amateurish in the past that OpenERP required so many changes 
to become decent). I even proposed to throw up a tool that would have 
subscribed to the RSS of commits where community / OpenERP could have 
collectively commented migration snippets.
Well it has not been done, so now the situation is we have OpenERP v5 and 
OpenERP v6 and we should deal with that and that will be very rock'n'roll.


What we started with OOOR yesterday, is a simple 20/30 scripts that will 
connect to 2 OpenERP installations (v5/v6 or pre/pos  module installation), 
analyse the fields definition of all objects and dump a diff in user friendly 
format.

This script will explicit things like in v6 a sale.order should now have a 
mandatory company_id key, so the migration script should provide one.
Well this should facilitate the work of building those scripts.
Even the guys who will buy OpenERP S.A. scripts will be able to check them when 
they have an issue (and yes, there will be blood).

BTW, if migration scripts start around 1 800 euros, well it's simple, we, for 
instance, have some 2 customers who won't be able to pay that + all the manual 
work from us (or certification work).

Not to say that: our ~8 customers all have at least some 6/7 custom modules so 
that OpenERP benefits are worth the bugs/limitations.

So, sorry, but I don't buy for a sec, anyone else than the integrator could 
migrate customer at a decent cost. I don't buy the upload your database and 
get migrated at flat price for a sec fro anywone using OpenERP v5 in 
production for real and not being a direct OpenERP S.A customer. 

Why? Because the decent OpenERP S.A. resources (provided the difficulty of the 
task), will soon be totally unavailable (we all see how hard it is to hire 
decent OpenERP consultants), the other will not be able to do the job properly 
or any cheaper than those who created the modules. Certifying the modules will 
be too much expensive for lots of users, it will bloat OpenERP S.A., it will 
not work in most of V5 case to achieve reliable V5/v6 migration.

Then how do we do? Well, the integrators should have the scripts to do the 
migration. But if the partner buys the script from OpenERP S.A., what will 
warranty OpenERP S.A. that the partner won't reuse the script for the other 
customers without buying it again? Then I see no practical solution for OpenERP 
S.A. in trying that specific migration business.

Of course, if, in the future, OpenERP gains more quality, like in V6, if 
modules become so generic that less customizations are required, if OpenERP 
real user base gets large enough, if scripts are thought during the 
implementation with rigor, then may be this could work in the future, I just 
don't see it working for v5/V6 because working v5 OpenERP installations where 
to much cowboy styled as I said.


Fortunately, lots of OpenERP users could simply close year 2010/2011 on v5 and 
start next year on V6 after migration some strategic data in an ad-hoc way and 
after having their modules made compatibles (which isn't that hard). 

But I hope to see community based/public migration scripts emerging because 
that the only way I see it possible for all the small companies (say less than 
10 people) using OpenERP v5 today and who will want a full migration. 
Fortunately also, there is no rush, those guys which are okay with v5 could 
migrate to v6 at the end of 2011, but obviously the more they will wait, the 
harder they will find any skilled integrator

Re: [OpenERP-users] Version 6.0

@rvalyi

 But this is not suitable to migrate the whole ERP with things like 
 accounting, partial reconciliations etc... (as ids, states will changes...) 


Our migration tool handles ID mapping automatically out of the box. It is even 
possible to do dynamic mapping, like connecting account movements from donor 
base to accounts created in a new base, by their codes.

If I get asked if it is possible to create per module migration scripts? I 
would say - it isn't. It will create overhead to a developer and no real 
benefit. I have not seen such approach working out of the box, for so 
complicated (not only technically), but rather logically, ERP like system. 
Tryton? They have much fewer modules, and they are coming by more or less 
single group of developers.


 Fortunately also, there is no rush, those guys which are okay with v5 could 
 migrate to v6 at the end of 2011


:) We played around with new 6th version, it is green, no to say more. It will 
be at least 9 months after first official release to be stable enough, to jump 
on, just the same as it was with with 5th version.


 the more they will wait, the harder they will find any skilled integrator 
 wanting to do extension on their v5 version. 


I do not agree, if the software will spread enough, more and more people will 
start working on it. If customer pays the same money, I do not care on what 
version to work.

BR

Kaspars
-
http://kndati.lv




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61354#61354

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0


fabien wrote:
 
 
 In practive, we maintain v5 up to april 2015. (the expected date of the 8.0 
 release.)
 

This is an excellent commitment
So, I agree, my third point maintain old version is no longer useful.

fabien wrote:
 
 PS: not only we maintain in the long term, but we also manage accounting 
 legal issues in the maintenance contract: we guarantee to fix any non 
 conformity to legal requirements of an existing feature in an accounting 
 module. - This will generate a big and continuous improvement in the 
 accounting localisation for different countries. This is what all customers 
 wanted.
 

Which makes the difference between bug fixing and maintenance. We use the same 
words.
Thank you for this information
regards


Dominique
http://sisalp.fr/demo.html , Hebergement 
http://sisalp.fr/openerp-serveur-gratuit.html




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61150#61150

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@fabien


 I just noticed that the report designer is not yet published on Launchpad.


Then it seems, that you have to pay more attention to what is being done by the 
team.


 We stoped and will release the two modules (openoffice  base_synchro), 
 without having been fully funded for this.


Again evidently not true, because in shared funding graphs, published more than 
a year ago, there was 80% fundraise for the Report Designer. So, if I am not 
mistaken, there was ~10% left to charge. Unless you do not count 50% expenses 
on sales procedure, I assume this particular module has been refunded by at 
least 200%.


 You may or may not like the shared funding system, but don't blame us to try 
 to find ways of financing the development of more modules.


I am not blaming for the idea, but the way it is being organized. If people 
fund the project, they has rights to know what is the actual fundraise, and 
when it is going to be released.

About migration scripts...
*Fri Feb 13, 2009 9:30 am
http://openobject.com/forum/topic9175.html

 If you wait between 3 and 5 months, we gave the guarantee to the community 
 that we will release migration scripts as soon as we have reimbursed our 
 development costs for this part. If we did not reimbursed our investment, I 
 gave the guarantee that we will release the scripts within maximum 5 months 
 after the release date. (we decreased from 8 to 5, if you check FAQ). 


What do we have to think?

I am sorry, but this is funny!
 :D




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61152#61152

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0


fabien wrote:
 
 PS2: We also said we will certify all community accounting modules for the 
 different countries. Our dedicated team will start at the RC1.
 

This relates to V6 only,
For V5 long term maintenance, today included accountings are concerned, ie by 
memory Belgium, France, UK and I don't remember if swiss localisation has been 
openerp-certified on V5.
Better than none, thank you.


Dominique
http://sisalp.fr/demo.html , Hebergement 
http://sisalp.fr/openerp-serveur-gratuit.html




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61151#61151

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@sraps

That's nice correlation. You will find that everywhere... information which 
never glue together.

Another example to add: The maintenance contract/support of Open ERP SA costs 
â¬1800 (lowest for 10 users per year) and covers only 'certified' modules. 
But, the same certified modules are there on ODOO and available for 
â¬39/month/user and its covered by the same maintenance contract. So if it is 
bug fix that you need, an integrator could have an ODOO instance, reproduce the 
same bug in that instance, and hurray its covered by maintenance contract. 

Another example is the 'certification' of modules. The most recent being the 
certification of magento openerp integration, where customers pay hefty to 
openerp to give them a certified version of a community module (supposedly with 
better quality). I assume the module then gets added to  openobject-addons (a 
branch closed for commit rights to openerp SA employees) and also made 
available on ODOO. (Note:This has not happened yet with magento erpconnect). 
The customer gets the module, the original developers continue the development 
(supposedly without quality) but the customer is not allowed to get the new 
improvements because its not certified. He has to use certified legacy code, 
because his maintenance contract is otherwise invalid? Well, is this free as in 
freedom? I would prefer to call this highest order restriction! a clear 
violation of GPL? 

and this is what I call a perfectly broken business policy. This is worse than 
proprietary!

@all

According to me the BIG REASON why the openoffice report designer module cannot 
be published is that its a violation of copyrights. The whole program is 90% 
work of Danny Brewer, 10% Open ERP code and its glorious copyright statements. 
They completely omitted Danny Brewer from the code. I had once reported this 
and Olivier Dony of Open ERP accepted it. So essentially, Open ERP SA violated 
GPL code of Danny Brewer by secretly selling his work without his copyright.

I am not surprised to see fabien change his word according to the situation. 
Its quite normal and community members have to get used to it. Everybody at the 
march community meet was given a promise that 'Poweremail' would be integrated 
into the core in 6.0 and in April they started developing a parallel module 
with same functionality and the excuse just like now was the guy who developed 
it from openerp was not aware of the module 
(http://www.mail-archive.com/openerp-expert-framew...@lists.launchpad.net/msg00301.html).

And i repeat the words of sraps: 


 it seems, that you have to pay more attention to what is being done by the 
 team. 



to end on a good note:


 In practive, we maintain v5 up to april 2015. (the expected date of the 8.0 
 release.) 


Thanks for this information, this is really interesting and helps to give 
authentic information to customers. Hope its kept ;)


Sharoon Thomas
Business Analyst  ERP Consultant
CEO at openlabs.co.in




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61157#61157

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@sraps
No, you are still wrong. Here was the graph of the funding:

https://docs.google.com/leaf?id=0B8I9h53mJ-C_MjkzNThjMDYtMTIyNC00YzViLWI5NzQtYmRmYzIyZDQ3Nzdhhl=en_GB

Only 40% of the funds have been raised. I agree the graph is not very clear
(invoiced vs remaining instead of total)

We just stopped shared funding since the new website (10 days ago), don't blame
us if it's not yet published.

I assume the module then gets added to openobject-addons (a branch closed
for commit rights to openerp SA employees) and also made available on ODOO.

I think we are and have always been very clear on this: everything we do is
directly commited to launchpad. Here is the URL of these modules:
http://bazaar.launchpad.net/~openerp/openobject-addons/5.0-certified-addons/

The certification means we keep a stable version of the module (with strict
release policy: no improvements, only bugfixes). It also means it's included in
our OPW: we guarantee to bugfix and make it evolves to new versions. The goal
of the certification is not to replace original version of the modules (which I
consider like a trunk branch, because the authors improves often the modules).
They are complementary: trunk (=original branch) can merge improvements of our
stable and we can merge improvements of trunk before releasing a new version.
Everyone benefits from this.

@sharoon
They are no violation of copyright at all. We do open source and reuse open
source code: that's normal. The code is being published this week in the trunk
branch you will see that there is less than 20% that comes from the library.
(only some snippets of code) - I have to say I did not checked myself, but it
has been a 6+ months work so I hope our developer developed things, and not
only did cut/paste during several months.

If one of our developer did forget to mention a copyright owner (this can
happen, we have 80 developers that plays every days with open source libs) we
fix and change as soon as we are aware of this.

Everybody at the march community meet was given a promise that 'Poweremail'
would be integrated into the core in 6.0

It has been integrated in trunk addons. The name of the module is
email_template. We made a big cleaning so it's slightly different but it's
based on poweremail module.

m2f

--
http://www.openobject.com/forum/viewtopic.php?p=61159#61159

m2f

___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

Hi all,

For my self, I think we can agree or not, or even wonder something else.

But I think OpenERP is now transparent. (A question in my first post was about 
the migration, and this point is now clear for me). For me a cheaper 
maintenance contract should be suitable.

F.ex. including x incidents and then we have to pay additional incidents.

We are a non-profit association, I think, for the use we have, we can have a 
budget for a such contracts, but less than 1000 Euro.




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61162#61162

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@fabien

Thanks for the clarity and very interested to see it in the core. However this
reveals an even bigger problem, that your code always remains legacy code and
the community has absolutely no control over it.

Poweremail has had several improvements since you have forked it. Even on
version 6 (not by me, by Raphael Valyi Co.). So IMHO, Open ERP restricts the
contributions/improvements by locking down the code. Over and above, you take
the unnecessary pain of doing all that you want to do within your employees to
establish your copyright? Had, you created a blueprint for this you would have
got the same development done by the community. Open ERP definitely has a large
community, but as a project leader you are not tapping the potential
effectively.

They are no violation of copyright at all.

Please see:
http://twitter.com/odony/status/15375979932

I have to say I did not checked myself, but it has been a 6+ months work so I
hope our developer developed things, and not only did cut/paste during
several months.

Try a diff with the code here:
http://www.oooforum.org/forum/viewtopic.phtml?t=14409

If one of our developer did forget to mention a copyright owner (this can
happen, we have 80 developers that plays every days with open source libs) we
fix and change as soon as we are aware of this.

I guess you need to educate your programmers on programming with ethics and
values, and definitely on how to respect copyright.

BTW copyrights on poweremail code states as though I forked poweremail. Your
copyright is only since 2010, NOT from 2004-2010 on poweremail.

http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/annotate/head%3A/email_template/__openerp__.py#L5

We made a big cleaning so it's slightly different but it's based on
poweremail module.

You might want to have a lookup at what real cleanup is (still in progress):

http://bazaar.launchpad.net/~sharoonthomas/poweremail/refactoring/files

Sharoon Thomas
Business Analyst ERP Consultant
CEO at openlabs.co.in

m2f

--
http://www.openobject.com/forum/viewtopic.php?p=61166#61166

m2f

___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

 Please see:
 http://twitter.com/odony/status/15375979932

Yes, I know one of our developer forgot the copyright. We sometimes do 
mistakes, I always admited that. What's important is that we fix the copyright 
when we notice it.
But you always cry and claim that we intentionally remove the copyright which 
is totally false. (we are not the evil big company you pretend we are :)

I changed your copyright, thanks for the note.




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61170#61170

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

Although I'm quite new here...

To me especially this thread, but also the new position of a Community Manager, 
the OpenDays and so on create the impression, that Tiny starts to pay more 
attention for us as The Community.

Removed Copyright informations are hopefully things that happened only in the 
past (and maybe systematic back then) - but if things change we should accept 
the will of Fabien to change things like that to a better, a more honest 
behavior. 

I HOPE this is the case and that we will see more improvents in that direction 
in the future. 

If OpenERP spreads around the globe Tiny wil not be able to verify each local 
adoption (what are the tax laws in Madagaskar or the billing laws in Nepal?). 
Tiny will have to accept some day that the way they do it now reduces the 
potential of the system. They create a bottleneck in the developent, because 
they can't do everything anytime.

So maybe now right now, but within the next year(s) we will find we are not 
Locked In any more. From my point of view that is the only consequent 
possibility to fill FREE as in FREEDOM with life.

Thanks for all
ulsc


- was testing OpenERP end of 2009 - now waiting for 5.2/6.0 since Dec. 2009 - 
bored of waiting -




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61188#61188

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0


sharoonthomas wrote:
 @sraps
 Another example is the 'certification' of modules. The most recent being the 
 certification of magento openerp integration, where customers pay hefty to 
 openerp to give them a certified version of a community module (supposedly 
 with better quality). I assume the module then gets added to  
 openobject-addons (a branch closed for commit rights to openerp SA employees) 
 and also made available on ODOO. (Note:This has not happened yet with magento 
 erpconnect). The customer gets the module, the original developers continue 
 the development (supposedly without quality) but the customer is not allowed 
 to get the new improvements because its not certified. He has to use 
 certified legacy code, because his maintenance contract is otherwise invalid? 
 Well, is this free as in freedom? I would prefer to call this highest order 
 restriction! a clear violation of GPL? 
 


Sharoon, do you give unlimited support to modules not developped/verified by 
you at a flat price (not a per hour basis)?


Albert Cervera i Areny
http://www.NaN-tic.com
OpenERP Partners

http://twitter.com/albertnan




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61192#61192

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

I also want to add, that kndati.lv migration scripts from v.4. to 5. where 
designed to be usable in future versions of OpenERP too. I guess we need to do 
some minor changes to run them for 5 to 6 migration, although we haven't tested 
yet. 
At this point I doubt, that v.6 is useful in production and will be in a couple 
of months- especially considering v.5 pain.




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61085#61085

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

Hello,

confirmed points are :
- openerp-sa scripts will only cover certified modules
- one can get these scripts only through a first-level support contract from an 
official reseller
- openerp-sa is not committed in maintaining previous versions

which indicates the following roadmap for the community :
- organize migration of extra/custom modules, probably contributed by the 
module's author
- create/maintain a free migration solution
- organize previous versions maintainance

I agree the publisher cannot do everything for free and his guarantee has a 
price. Nevertheless community is in charge of filling the gap between what the 
publisher delivers and what the real need is, by organizing sharing of 
contributions for all those who prefer master all key aspects of their IS.

Only a first thought after reading this topic.
Regards


Dominique
http://sisalp.fr/demo.html , Hebergement 
http://sisalp.fr/openerp-serveur-gratuit.html




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61090#61090

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

Hello,
Bounaberdi, you are quite wrong on your issues, please read our contracts and 
quality of services. The publisher's warranty:

* OpenERP SA guarantees to maintain versions for 3 main stable (5.0, 6.0, 7.0) 
- minimum 4.5 years. So, you can freely stays in version 5 for a while.
* Cover all certified modules, but you can ask to certify any custom module. 
Just have a look on how much modules have been ported to trunk and you will see 
why it's important - 800â¬ to backport, bugfix and maintain for 1 year (=2 
versions) a custom module is quite cheap. Have also a look on who follows legal 
issues for l10n modules. We probably loose money on this certification service, 
if you do it yourself, I am happy.
* Our migration service cover certified modules but we accept non-certified 
modules, we just don't bugfix them. (so you can focus only on your custom 
modules)




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61098#61098

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@sharoonthomas
I completely agree with you.

@To Whom It May Concern

I want to add, to what was said by Sharoon, that this lock in and anti-feature 
policy is present in other places of OpenERP. Let it be manual introduction of 
new reports in OpenERP system and change of the templates for existing ones. 
This feature is available in generic OpenERP and TinyERP, although, it has been 
intentionally hidden no to leave it open and force buying GPL licensed (!!!) 
Report Designer.

You would ask GPL licensed?, yes it is GPL licensed, that's what the code 
says and the About box of Report Designer states as well. One would ask for 
proof, here you are:
http://doc.openerp.com/developer/7_23_RAD_tools/index.html#about
And I have been testing Report Designer with statements of GPL license, by 
myself, and I would not hesitate to modify one for using with 
report_openoffice, if it would not be a crap-ware...

This is clear evidence of selling a software licensed under GPL. So if somebody 
have paid money for this software, and poses a copy of one, you are absolutely 
righteous to release Report Designer to the general public! Because it is 
licensed under GPL, no kidding!

@ OpenERP SA
If there is some idea of removing this GPL statement from web page or the 
Report Designer itself, as this have been done with requirements for new 
partners, it is absolutely useless. I have copied the page and will provide a 
copy to anybody who want to use Report Designer rightfully licensed under GPL.



What requirements for partners?
- Those requirements, which asked partners not to release any software (which 
was developed under Shared Funding initiative, in particular) to a third party. 
Software, which is being provided to them during contract with Tiny Sprl. (at 
the time), software still licensed under GPL! These requirements were removed 
from web page after a rant on a forum, to hide the actual policy from general 
community. Isn't it against GPL?

I would not say anything if OpenERP would be semi commercial software from the 
very beginning, and anybody had a right to contribute a proprietary licensed 
modules. Still this right is delegated only to OpenERP SA and it's partners, 
which sell their OpenObject related developments under proprietary licenses 
just like that.

I am sorry but this is clear policy of lock in!

Is OpenERP SA open minded?
- Despite their statements -No.

Is OpenObject and OpenERP really FOSS?
- Yes, because it is the merit of community. Fortunately community is strong 
enough to cover the breaches.

Best regards!
Kaspars
-
http://kndati.lv




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61099#61099

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

hello,

fabien wrote:
 Hello,
 Bounaberdi, you are quite wrong on your issues, please read our contracts and 
 quality of services. The publisher's warranty:
 * OpenERP SA guarantees to maintain versions for 3 main stable (5.0, 6.0, 
 7.0) - minimum 4.5 years.

This is good news, can you provide us with a pointer to this contract ? I 
couldn't find it.
Does it mean V5 will be supported as long as you have a valid contract signed 
by someone who stays in V5 with a limit of 54 months after contract signature ?
Can you translate it in practice : is there already a date before which we can 
be sure support of V5 won't be dropped ?

regards


Dominique
http://sisalp.fr/demo.html , Hebergement 
http://sisalp.fr/openerp-serveur-gratuit.html




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61102#61102

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

 @elBati
 Still this right is delegated only to OpenERP SA and it's partners, which 
 sell their
 OpenObject related developments under proprietary licenses just like that.

OpenERP does not sell any proprietary module and we have no other licences than 
our open source ones !

If someone else develops proprietary module, we sometimes redevelop it for free 
at our own charge. (ex: outlook plugin in v6)




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61105#61105

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

It's written on the pricing page. We don't give a guarantee in term of years, 
but in term of versions. (current + two major stable versions) The release 
policy is to do one new stable minor version every 6 months, one new major 
stable version every 18 months.

The program and contract is not yet online because usually these contracts 
are sold by partners. We have no ambition to resell this in direct: we want to 
work with the partners. Our second level maintenance contract has been made 
to be included in partner's first level support contract. Just write to 
sa...@openerp.com is you want a copy of the brochure and the contract. (the 
brochure is quite similar to what's on the website) - I think  you got a copy 
during the  community meeting: we made small changes, but the main articles 
remains the same.

I will think if it's a good idea to publish the contract directly online.

In practive, we maintain v5 up to april 2015. (the expected date of the 8.0 
release.)

PS: not only we maintain in the long term, but we also manage accounting legal 
issues in the maintenance contract: we guarantee to fix any non conformity to 
legal requirements of an existing feature in an accounting module. - This will 
generate a big and continuous improvement in the accounting localisation for 
different countries. This is what all customers wanted.

PS2: We also said we will certify all community accounting modules for the 
different countries. Our dedicated team will start at the RC1.




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61104#61104

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

@fabien

What are you talking about? These statements of yours can convince only novice 
community member, because it is nothing in common to the reality. This is 
communication policy usually executed by large corporations - the truth is on 
the side of the one who speaks louder.


 OpenERP does not sell any proprietary module and we have no other licences 
 than our open source ones ! 


Selling of GPL software is not prohibited, but requiring customer not to 
release the GPL licensed (even though he bought a copy) software to community, 
definitely is. So despite being licensed under GPL, it is actually being 
distributed under proprietary license.


 We stopped shared funding modules.


Evidently, stopped the project by not releasing the result. OpenERP SA raised 
funds (by observing to the fundraise graphs, I assume even more than that was 
spent to develop particular software), but fooled all the customers (community) 
who funded the project, by not releasing the software. And I speak about Report 
Designer, which was the most popular item, and raised the most of funds (again 
by observing to the fundraise graphs, I assume even more than that was spent to 
develop particular software).


 The idea was good


No doubt, it was! Still you ruined it by not following the rules, drafted by 
yourself. So nobody will be able to make the scheme run again, at least for the 
nearest future!

I am sorry, if you have not bother enough to read my previous post carefully. 
There are clear evidences of the proprietary policy executed in practice, and 
these are not the only ones.




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61113#61113

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

The link has forbidden access for me.

Regards,
Ruben




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61129#61129

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

Ok, seems like the old site filters IP addresses. Here is a copy and paste:

In order to boost the growth of OpenERP, the Shared Funding Development (SFD) 
projects allow everyone to request and pre-finance new features to be developed 
in OpenERP.

The feature is then developed and sold until we reach the development cost of 
the project to reimburse the one who pre-financed the module. Once the 
development costs are paid, the module is freely published under the open 
source GPL licence.

If you purchase one of these modules, you directly get it as Open Source, so 
you can do whatever you want for yourself. We just ask you to not distribute it 
so that the SFD project keeps being a success.

From the old FAQ:

Why should I pay for a module which is already developed ? 

Most of the development in Tiny ERP are financed by the Tiny company. If a SFD 
project is opened, it means that the development was requested by several 
companies but not planned in Tiny development budget. So, we need to finance 
the development through these companies investment.

If the module is freely available, nobody will pay for it. That's why, during 
the funding period, the module will be only accessible to contributors. Of 
course, after this funding period, the module will become public.


How to propose a new feature ?

To request a new feature, you must send a request for quotation in english to 
the Tiny ERP team: sales AT tinyerp.com . You must provide a complete 
description of the need with some examples, demo data and a description of a 
complete test case.

Then you will receive a detailed quotation with...

In that way, if you need this feature you have two solutions:
* Pay this amount to subcontract the development of the module and get it 
quickly
* Start a Share Funding Development project, paying 15% of the total costs. 
Others members of the community can pay amounts to get the module. We start the 
development when a good part of the module's development cost are funded.


 I repeat that we decided to stop these shared funding activities. If a 
customer wants to get a development, he will have to pay the full amount of the 
development costs (to OpenERP or to a Partner). We have no more ways to share 
the funding of the RD for generic features, but we avoid frustrations and 
misunderstandings about our goals with SFD. 




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61131#61131

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

are you planning to release them?


Davide Corio
davide.co...@domsense.com
http://www.domsense.com




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61135#61135

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

Although I don't like everything I read in this thread I am very thankful that 
things are discussed and not surpressed. 

Especially I want to thank Fabien for his postings and links, as there are too 
many possible sources of information for me to find them all. Thanks to your 
links I know some more now.


Regarding the migration I think its a good idea to have a community driven tool 
for standard migrations. Tiny is not in the duty then to fix things where 
this doesn't work. And those who can't afford the service will have at least a 
chance to do things themselves.

Best regards
ulsc

...who stopped th eintroduction of v5 and waits for v6, avoiding the whole 
migration stuff this way.


- was testing OpenERP end of 2009 - now waiting for 5.2/6.0 since Dec. 2009 - 
bored of waiting -




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61142#61142

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0


tchiboo wrote:
 
 
 I hope it won't be the same as migrating from 4.2 to 5.0, but easier. 
 
 

As far as openerp has communicated on this, you'll have to contract with an 
openerp partner/reseller to get the migration scripts from openerp.
Nevertheless these scripts will only support openerp-certified modules at first.
I think it will be a concern for all those who installed openerp V5 by their 
own, if openerp-sa don't change their mind. They never published V4 to V5 
scripts.
We don't know what will happen to V5 after V6 launch either, I'm afraid nothing 
and V5 may de-facto die.

regards


Dominique
http://sisalp.fr/demo.html , Hebergement 
http://sisalp.fr/openerp-serveur-gratuit.html




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61024#61024

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

Hi, 

For me, if what you say is correct, that mean openerp erp IS NOT FREE.

Because if each migration is mandatory, and for each migration you have to buy 
a script it is like buying openerp and eAch teo years .

That meet the feeling I have. Lets see.

In switzerland we have big project for openerp erp in the non-profit area, we 
are not against paying to have support when needed. But not that way.




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61029#61029

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

Oh,

And that's true, we never saw the promised script V4 V5

[quote=Bounaberdi][quote=tchiboo]

I hope it won't be the same as migrating from 4.2 to 5.0, but easier. 

[/quote]
As far as openerp has communicated on this, you'll have to contract with an 
openerp partner/reseller to get the migration scripts from openerp.
Nevertheless these scripts will only support openerp-certified modules at first.
I think it will be a concern for all those who installed openerp V5 by their 
own, if openerp-sa don't change their mind. They never published V4 to V5 
scripts.
We don't know what will happen to V5 after V6 launch either, I'm afraid nothing 
and V5 may de-facto die.

regards[/quote]




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61030#61030

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

Agree with tchiboo, Tiny's politic with migration scripts isn't really 
acceptable and it's the only point where we can say that OpenERP isn't free (on 
the other hand, no double license, all in AGPL, really thanks Tiny for that).

But this time, I think OpenERP's community is far more mature and I believe 
that there has already a migration script in the making. Someone for confirming 
it?
Anyway, I want to help for this work, especially we have a great tool for this 
purpose with server_migration by kndati.


SociÃ©tÃ© SYNERPGY

SSLL spÃ©cialisÃ©e dans l'implÃ©mentation d'OpenERP en Ile-De-France.




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61039#61039

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0


YannickB wrote:
 
 Anyway, I want to help for this work, especially we have a great tool for 
 this purpose with server_migration by kndati.

I did collaborate with kn-dati for some V4-V5 data migration. I can confirm 
they did a great job and I still look forward to working with them again. I 
like the idea of reproducing data to a fresh new database, nevertheless it may 
not cover all cases of historical data anyway.
rgrds


Dominique
http://sisalp.fr/demo.html , Hebergement 
http://sisalp.fr/openerp-serveur-gratuit.html




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61040#61040

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

I like to bring all datas to a new db toi.

Last time i ve exported, i would be pleased to try or help like you says with. 
The kndati's job.




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61041#61041

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

With OOOR/Terminatooor from akretion, it would be kind of easy to build our 
own community migration script.

We have migrated recently some clients from 5.0.1 to 5.0.14, including:
- Partners
- Products
- Stock inventory
- Invoices
- CRM leads and opportunities.

Not as easy as 
http://kndati.lv/index.php/en/openerp/open-erp-addons/data-migration but also 
working.


Carlos LiÃ©bana Anero
www.ting.es




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61045#61045

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

Hello,

I made a clear explanation of OpenERP SA's point of view about migrations here:
  http://www.openerp.com/node/465

Our goal is to be very transparent on how we work and why we do it that way.




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61068#61068

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0

Thank you for your clear, and complete answer.

I think this way it is transparent.

That's unfortunately too expensive for us.




 m2f 

--
http://www.openobject.com/forum/viewtopic.php?p=61073#61073

 m2f 


___
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Re: [OpenERP-users] Version 6.0