anajuaristi wrote:
We had no customer's implementation including only certified modules.
IIUC, openerp-sa provides a service, they don't sell a script.
l10n_fr and l10n_be are certified.
They would cover spanish l10n_ if someone pays for certification, same for
other modules. This implies the
[quote=sharoonthomas]...@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
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
@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
@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
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
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
@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
@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
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
@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
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
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
@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
@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
@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
@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.
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.
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
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
@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,
@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
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
@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.
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
@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
@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
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
@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
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
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
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
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
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
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
@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
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
@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
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
@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
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
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
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
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
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
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
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
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
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
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
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
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
--
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
Hello Fabien,
Your clear explanation states that you are not releasing the migration scripts
because it causes frustrations. I assure you it will not create more
frustration than what existing openerp modules could create or have already
done.
If you had made the statement after publishing
54 matches
Mail list logo