Hell in point of sale

1.   def test_paid(self, cr, uid, ids, context=None):     
2.         """ Test all amount is paid for this order
3.        @return: True
4.        """
5.         for order in self.browse(cr, uid, ids, context=context):
6.             if order.lines and not order.amount_total:
7.                 return True
8.             if (not order.lines) or (not order.statement_ids) or \
9.                 Decimal(str(order.amount_total)) != Decimal(str(order.amount_paid)):
10.                 return False
11.         return True
    
    
    Coming from the point_of_sale module in addons, find the hell!
    
    I help you, this code bugs the point of sale when we change the price accuracy of OpenERP

OpenERP Hate from the web

Just take a look:
http://goo.gl/3yZOF

Tryton vs OpenERP: From internet Part 1

If you are going for the other direction (other than Django)I would really recommend tryton and keep the hell away of openerp. Tryton is really open source. openerp is just like compiere, openbenbravo and many others: "Was truly open source" than, came the money!!
We made the change a while ago. I took a lot of work. Spare yourself this trouble. Go Tryton!

From Pim Vergalen on http://stackoverflow.com/questions/2580512/building-a-financial-app-with-django

Annoying bug: XML/RPC should return integer faultcodes

from https://bugs.launchpad.net/openerp/+bug/257581

OpenERP doesn't respect the XML-RPC standards, returning a string as faultcodes, this breaks a lot of Java applications integrations according to the bug.

at www.xmlrpc.com :

"The <methodResponse> could also contain a <fault> which contains a <value> which is a <struct> containing two elements, one named <faultCode>, an <int> and one named <faultString>, a <string>."

Tiny Erp return a string and not an int. It's not very clear on the xmlrpc website but for exemple the apache java xmlrpc client understand only integers

9 hours ago:

Changed in openobject-server:
importance:	High → Wishlist
milestone:	6.0 → none

The OpenERP effect: Richard's Success, are you kidding?

http://www.scribd.com/doc/13773120/Richards-Success

Just take a look,

First, when you integrate a new application in a company, employees are happy if it is like before but faster but changing nothing in OpenERP because the slides don't talk about developments then employees are totally unhappy if you are using standards OpenERP views. They don't want to change they way they work.

If you integrate OpenERP like in the slide 26, you need to have a bridge with the other applications (then there is a cost)

BI module? Where do you have a nice BI module in OpenERP? This is just an unfinished buggy module

Can you do in OpenERP what you do with Outlook? Where? Why does OpenERP creates an Outlook plugin then?

Replacing Isabel? How?

These slides are just commercial but not showing real life, just post your comments about them...

From Twitter: about OpenERP license issues with Fedora

#openerp refused in #fedora because of license issue http://goo.gl/mpK72 and one more copyright/license issue


and one more license issue for #openerp with #pyPDF http://goo.gl/AvGql


http://twitter.com/#!/cedrickrier

Tryton vs OpenERP: Which is the best? Better modules or more modules?

I post the difference between Tryton and OpenERP, simply because I'm looking at Tryton for the moment to see how different it is from OpenERP and if it is better coded and easier for developers. Well for the moment I'm really surprised by the excellent quality of the code. Here is a VS sheet coming from Wikipedia.

Subject	Tryton	OpenERP
Language	Python (>=2.4)	Python (>=2.4) for 5 Series[1], Python (>=2.5) for 6 Series
Versions maintained	2 years	5.X.X Series to 6.X.X Series
Release cycle	every 6 months	when it's stable
Version Policy	No API changes in Series, No XML Change in Series	No API changes in stable versions
Number of Modules	50	> 500
Repository Organisation	1 Repo per Module	1 Repo for official modules
Version Control System	Mercurial (HG)	Bazaar (BZR), hosted on Launchpad.net
Active contributors (commits in May 2010)	40	245
Automatic Upgrades/Migrations	Yes	Yes for minor versions
Python Packaging	Available on PyPi[2]	Not Available on PyPi
Python Module	Can be used as a module[3]	not
Distribution Package	Debian, Gentoo, Ubuntu, Arch Linux, Foresight Linux, Windows (only client), MacOS X (only client)	Available
Code Auto-Reload	Available	Not Available
Architecture	Three Tier	Three Tier
Database Supported	PostgreSQL, MySQL, SQLite	PostgreSQL
Desktop Clients	GTK Based Desktop Client	GTK Based Desktop Client KDE/QT Client(Community)
Web based Clients	SAO based on Google Web Toolkit (Work in progress)	OpenObject-client-Web based on CherryPy, Mako and Mochikit (replaced by JQuery in v6)
Client Access Libraries	Proteus	Not Available
Standalone Clients	Neso	None
Native Gantt Charts	Not Available	Available only in web client
Native Calendar View	Through CalDAV	Available
Native Diagram View	Not Available	Available in v6
Reporting Engines	Relatorio based Openoffice WYSIWYG reports [4] or any custom	RML (official)/Relatorio (on Open Office. Community), Jasper(Community), MAKO(work in progress)
Native Bar/Pie Chart View	Available (with drill down)	Available
Dashboard View	Available (customizable)	Available
CalDAV	Available	Available in series 6.X.X
WebDAV	Available	Available in series 6.X.X
Cardav[5]	Available	Not Available
Unit testing	Covers Server & All modules	Covers modules & reports
Functional Testing	Proteus (Work in Progress) and in unit test	YAML Based Tests in series 6.X.X,Open ERP Scenario (Community Project/Unofficial) [6]
Client Multi Language Programming Compatibility	Possible by use of Pyson Syntax [7]	Not available due to pythonic expressions.
IP v6 Compatibility	Yes	No
Historization	Yes[8]	No
Localization	5	more than 20 languages,  integrated with Launchpad.net

Business model

Subject	Tryton	OpenERP
Editor	Community [4]	Open ERP SA [5]
Project type	Community Open source [9]	Commercial Open Source [10]
Professional Service Providers	Available	Available
Partnership Eligibility	Merits & Contribution to project	Buying Partner Contract
Software License	GNU General Public License[11]	Server: GNU General Public License [12] Web Client: Open ERP Public License[13]

Functionality

The functionality description here is based on the official modules of both projects. Unofficial modules with the functionality may exist, but is beyond the scope of this comparison as any such content would be difficult to maintain.

Subject	Tryton	OpenERP
Accounting & Financial Management	Yes	Yes (Severely limited)
Document Management System	Yes (document size limit: Filesystem limit)	Yes (document size limit: PostgreSQL 1GB)
Analytic accounting	Yes	Yes
Payroll Management	No	Yes
Portals	Yes	Yes
Sales Management	Yes	Yes
Warehouse Management	Yes	Yes
Project Management	Yes	Yes
Purchase Management	Yes	Yes
Manufacturing Management	In Development [17]	Yes
Human Resources	Yes	Yes
CRM	Basics	Yes
Point of Sale	No	No (Fast encoding screen available [18])
E-commerce	?	Integration Magento, Prestashop, ...

Concepts and approach

Subject	Tryton	OpenERP
Accounting	Uses Decimal [14]	Uses Floats [15]
Password Storage	Crypted with SHA1	In clear text
Code review	For all commits through Rietveld[16]	Almost none
float/integer representation	Limited to float or long because using gtk.Entry without limit	Limited to sys.maxint of Python because using gtk.SpinButton

Reference: http://en.wikipedia.org/wiki/Comparison_of_Tryton_and_Open_ERP

OpenERP on_change: bunch of parameters vs dictionaries

def product_uom_change(self, cursor, user, ids, pricelist, product, qty=0,
            uom=False, qty_uos=0, uos=False, name='', partner_id=False,
            lang=False, update_tax=True, date_order=False):
        res = self.product_id_change(cursor, user, ids, pricelist, product,
                qty=qty, uom=uom, qty_uos=qty_uos, uos=uos, name=name,
                partner_id=partner_id, lang=lang, update_tax=update_tax,
                date_order=date_order)
        if 'product_uom' in res['value']:
            del res['value']['product_uom']
        if not uom:
            res['value']['price_unit'] = 0.0
        return res

Look at this on_change, 15 parameters and calling another one with 14 parameters. This is too much, a good idea will be to use dictionaries:

def product_uom_change(self, cursor, user, ids, params, context=None):

        res = self.product_id_change(cursor, user, ids, params, context=context)

        if 'product_uom' in res['value']:

            del res['value']['product_uom']

        if not params['uom']:

            res['value']['price_unit'] = 0.0

        return res

PS: Here I have also a context parameter, OpenERP and his CEO Fabien Pinckaers forget it frequently.

Fabien Pinckaers: OpenERP v6, new logging system for end-users

Fabien Pinckaers: OpenERP v6, new logging system for end-users: "In order to improve the useability of OpenERP v6 and make it easier to use and learn for new users, we added a logging system on main action..."

Today, I saw this new post from the CEO of OpenERP, as always I've watched the code:

http://bazaar.launchpad.net/~openerp/openobject-server/trunk/annotate/head:/bin/addons/base/res/res_log.py

class res_log(osv.osv):
    _name = 'res.log'
    _columns = {
        'name': fields.char('Message', size=128, help='The logging message.', required=True),
        'user_id': fields.many2one('res.users','User', required=True),
        'res_model': fields.char('Object', size=128),
        'context': fields.char('Context', size=250),
        'res_id': fields.integer('Object ID'),
        'secondary': fields.boolean('Secondary Log', help='Do not display this log if it belongs to the same object the user is working on'),
        'create_date': fields.datetime('Created Date', readonly=True),
        'read': fields.boolean('Read', help="If this log item has been read, get() should not send it to the client")
    }
    _defaults = {
        'user_id': lambda self,cr,uid,ctx: uid,
        'context': "{}",
        'read': False
    }
    _order='create_date desc'

Well, this is the logger code, what do you think about it?

Let's look at the get method:

    def get(self, cr, uid, context=None):
        unread_log_ids = self.search(cr, uid,
            [('user_id','=',uid), ('read', '=', False)], context=context)
        ...
        self.write(cr, uid, unread_log_ids, {'read': True}, context=context)
        return result

As you can see the get method returns the unread messages.

Now, imagine you have 2 users using the same login. For example I've a customer using a backoffice login for 4 users.

Imagine 2 users (Mr Smith and Mr West) using the same user. The first connected will see all the unread messages and the other no messages...

base_contact module, heaven or hell?

Well, a lot of companies when they saw the partners (without the base_contact), they think that they need contacts separated from the addresses. In 70% of the cases they don't need it really but if they need it you think directly... base_contact... but this module is hell or heaven?

Just comment it!

Good reading for the CEO of OpenERP:
http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470178450,descCd-description.html

Interview with The OpenERP Developer

Fri, 10/15/2010 - 04:00 — admin

Age: ?? Located in: ?? Occupation: OpenERP Consultant Tweet: openerphell

Tell us about about yourself:

I'm an OpenERP Consultant

Tell us about about you and OpenERP

 If OpenERP was ...what would it be:

• An animal (except an ant of course): The naked mole rat
• A color: Red (it matches the invisible required fields)
• A Dish : Black pudding
• A Song: OpenERP deserves an album of its own “Rage against the machine"

Just kidding...

Caldav in V6, the truth...

A lot of persons are talking about the CalDav implementation in OpenERP in V6, is it really CalDav or ics files with Webdav?

Looking at the OpenERP documentation about CalDav, you can see this:

Looking at this picture, you may think that OpenERP is only working with ics files... But... No, in fact I've tried the CalDav implementation in V6 and it seems that it is a real CalDav implementation... Then the documentation is wrong but the module name (caldav) is fine... 

One good point for OpenERP, I already said in this blog I'm impartial, I only give the truth about OpenERP...