> - you are almost the unique OpenERP integrator that didn't learn programming > along you functional skills. You are almost the unique exception and you > could start a sustainable activity only recently (one year ago you would not > have make it, too many bugs).
I can't believe I'm the only one working like this!!! There should be more freelance consultants than me!! > - even with that, you still rely on programmers like us to manage some of > your own projects. I mean, We or Zikzakmedia and the other gave you a hand on > your projects (Elsenordelmar, Logiscenter... for us). How would you do > without engineers? > I mean I absolutely do not criticize what you do and I'm happy when we can > team together, but what is your point coming here and telling programming > skills are optional? They are optional if you pay somebody do it for you, > otherwise I don't want to see how you'll migrate your data/version or close > you accounting period. > Raphaël is totally different managing a project or AFTER passing the start-up, customer decide to make some programming/adapting module to make easier they operative. As you say you built a very concrete and concise module for El Sr del mar: Stock in 2 measure units, but the 98% of functionality needed was filled by standar modules, spanish localization and another few extra modules. El sr del mar was working by now when you made the module. Logiscenter needed prod_lot_autosplit and publicated last version had a bug. Your team built the module so I thought you were the best to repare it. Again. rest of functionality used is taken just from publicated on stable branch. And Yes... when I need an extra functionality to my customers i have to contract a programmer and pay for it. My customer agreed with this. But I always try to investigate just publicated modules before contracting programmers and 80% of times is possible to find something that fit customers needs. Thank you all guys publicating on extra-addons. > I mean this is pretty much when you came here to tell hey folk we can > integrate OpenERP in 5 days, and then you Gtalk me during week ends because > you are totally lost with data importation and OpenERP bugs, why do you need > to come and tell it's so easy then? What the benefit of this, getting a ton > of noobs jumping in that will fail their projects and then tell OpenERP is > crap? For your customer to pay you even less days for your projects, so we > don't have the skilled integrators ecosystem that make the product more > mature? > I understand nothing about this paragraphe. I NEVER and say again NEVER said that you can integrate OpenERP in 5 days. The most quick project I made is 1-2 month long even if it's a very little company. I just gtalk to you to offer a work or asking some punctual easy doubts for 4 or 5 times. I asked to you about migration, not because I was "totally lost" but because the origin system was an old dinosaur ERP and I just offered to you the posibility of making a quotation. After that I offered the work on launchpad. My operative is, if there is a bug I report on launchpad. If customer has got a technical support contrat, I send it to company who is supporting my customer and after reparing we always publish patch. So easy like that. If a final customer wants jumping into OpenERP, first have to learn about openERP and contract technical support. He does not need programming. > Don't get us wrong, coding is not only about creating new modules to meet > exotic requirements. It's also very much about only getting rid of the nasty > blocker bugs. All versions have critical bugs. On a small scope you can may > be find a version that fit your basic needs. On a larger perimeter, like for > instance when accounting is required, that's impossible (or do you think we > fight on Launchpad bugs just for fun?) > Why you get ungry with me? I use only spanish localization modules. It fits 99% of spanish customer needs. It's good made. We try don't migrating old fiscal data but mantaining them on old system for consulting. I customer want's to pay migration... it depends on origin data the cost of it so he must agree with price. > > I'm suspicious Spain is not where accounting is the most challenging. But I > know that in France there were much more issues. I bet @Gavin in the US is > totally lost. Now for us in Brazil, we need module such account_tax_include > to respect the fiscality (+ a good deal of other modules). > account_tax_include have rounding bugs such as this one: > https://bugs.launchpad.net/openobject-addons/+bug/510726 > Do you really think that's good to tell: hey folk no problem you can go in > prod with this out of the box? Well I don't. I don't know in other countries. In spain localization project is very mature. Thanks to everyone who colaborate on it. OK, we all agree on this; this doesn't scale at all. And that's one of the reason the community recently have an argument with Tiny because they were giving no direction tho the community: http://n3.nabble.com/Simple-things-we-need-from-Tiny-for-better-bug-planning-management-tc132053.html#none Thanks God we agree on something!!! ------------------------ Manuales, Videotutoriales de OpenERP en http://www.openerpsite.com http://www.aulaerp.com -------------------- m2f -------------------- -- http://www.openobject.com/forum/viewtopic.php?p=50467#50467 -------------------- m2f --------------------
_______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman2/listinfo/tinyerp-users
