developer toolbox

instalirao openerp - installer mu je baš dobar

ima web i gtk klijent, i app server

pretraga šifrarnika po nazivu fino radi i u web klijentu

nije baš da mi je intuitivan ali stvar definitivni nije loša

pdf je standardni output za sve izvještaje

https://launchpad.net/openobject

ja se ništa u ovom launchpad-u ne snalazim

http://openerp-team.blogspot.com/

mali milion modula: http://doc.openerp.com/modindex.html

http://rvalyi.blogspot.com/2009/02/openerp-running-on-java-jython-round-1.html

...

So my conclusion was that even if I needed to learn Python, I would get the work done faster with OpenERP than with any of those existing Java based ERP's. My experiments proved me that I was right. With OpenERP, extending the relational model, the forms and making it fit to my needs was faster than with any of the other tried ERP's, even while being a Python noob. One year later, with a few successful implementations behind me, I'm only recommending it more than ever.

http://code.google.com/p/tryton/

http://www.tryton.org/news.html

openerp za generaciju pdf dokumenata koristi http://www.reportlab.org/index.html

http://www.reportlab.org/whatsnew_2_0.html

Unicode support

This is the Big One, and the reason some apps may break. You must now pass in text either in UTF-8 or as unicode string objects. The library will handle everything to do with output encoding. There is more information on this below.

Since this is the biggest change, we'll start by reviewing how it worked in the past. In ReportLab 1.x, any string input you passed to our APIs was supposed to be in the same encoding as the font you selected for output. If using the default fonts in Acrobat Reader (Helvetica/Times/Courier), you would have implicitly used WinAnsi encoding, which is almost exactly the same as Latin-1. However, if using TrueType fonts, you would have been using UTF-8. For Asian fonts, you had a wide choice of encodings but had to specify which one (e.g Shift-JIS or EUC for Japanese). This state of affairs meant that you had to make sure that every piece of text input was in the same encoding as the font used to display it.

...

bin/osv/orm.py

# Object relationnal mapping to postgresql module
#    . Hierarchical structure
#    . Constraints consistency, validations
#    . Object meta Data depends on its status
#    . Optimised processing by complex query (multiple actions at once)
#    . Default fields value
#    . Permissions optimisation
#    . Persistant object: DB postgresql
#    . Datas conversions
#    . Multi-level caching system
#    . 2 different inheritancies
#    . Fields:
#         - classicals (varchar, integer, boolean, ...)
#         - relations (one2many, many2one, many2many)
#         - functions

hernad@nmraka-5:~/devel/openerp/account_balance$ tree

.                                                                                                              
|-- __init__.py                                                                                                
|-- __terp__.py                                                                                                
|-- account_move_line.py                                                                                       
|-- account_report.xml                                                                                         
|-- account_wizard.xml                                                                                         
|-- i18n                                                                                                       
|   |-- account_balance.pot                                                                                    
|   |-- ar_AR.po                                                                                               
...
|-- report
|   |-- __init__.py
|   |-- account_balance.py
|   |-- account_balance.rml
|   `-- account_balance_landscape.rml
`-- wizard
    |-- __init__.py
    `-- wizard_account_balance_report.py

hernad@nmraka-5:~/devel/openerp/openerp-server-5.0.0-3/bin/addons/base$ tree

.                                                                                                        
|-- __init__.py                                                                                          
|-- __terp__.py                                                                                          
|-- base.sql                                                                                             
|-- base_data.xml                                                                                        
|-- base_demo.xml                                                                                        
|-- base_menu.xml                                                                                        
|-- base_update.xml                                                                                      
|-- i18n                                                                                                 
|   |-- ar_AR.po                                                                                         
|   |-- base.pot                                                                                         
|   |-- bg_BG.po                                                                                         
|   |-- bs_BS.po                                                                                         
|   |-- ca_ES.po                                                                                         
|   |-- cs_CZ.po                                                                                         
|   |-- de_DE.po                                                                                         
|   |-- es_AR.po                                                                                         
..                                                                                        
|-- ir                                                                                                   
|   |-- __init__.py                                                                                      
|   |-- ir.xml                                                                                           
|   |-- ir_actions.py                                                                                    
|   |-- ir_attachment.py                                                                                 
|   |-- ir_board.py                                                                                      
|   |-- ir_cron.py                                                                                       
|   |-- ir_default.py                                                                                    
|   |-- ir_exports.py                                                                                    
|   |-- ir_fields_description.py                                                                         
|   |-- ir_model.py                                                                                      
|   |-- ir_report_custom.py                                                                              
|   |-- ir_rule.py                                                                                       
|   |-- ir_sequence.py                                                                                   
|   |-- ir_translation.py                                                                                
|   |-- ir_ui_menu.py                                                                                    
|   |-- ir_ui_view.py                                                                                    
|   |-- ir_values.py                                                                                     
|   |-- wizard                                                                                           
|   |   |-- __init__.py                                                                                  
|   |   |-- create_action.py                                                                             
|   |   |-- wizard_menu.py                                                                               
|   |   `-- wizard_menu_view.xml                                                                         
|   `-- workflow                                                                                         
|       |-- __init__.py                                                                                  
|       |-- print_instance.py                                                                            
|       |-- workflow.py                                                                                  
|       `-- workflow_view.xml                                                                            
|-- maintenance                                                                                          
|   |-- __init__.py                                                                                      
|   |-- maintenance.py                                                                                   
|   |-- maintenance_security.xml                                                                         
|   `-- maintenance_view.xml                                                                             
|-- module                                                                                               
|   |-- __init__.py                                                                                      
|   |-- module.py                                                                                        
|   |-- module_data.xml                                                                                  
|   |-- module_report.xml                                                                                
|   |-- module_view.xml                                                                                  
|   |-- module_wizard.xml                                                                                
|   |-- report                                                                                           
|   |   |-- __init__.py                                                                                  
|   |   |-- ir_module_reference.rml                                                                      
|   |   |-- ir_module_reference.sxw                                                                      
|   |   `-- ir_module_reference_print.py                                                                 
|   `-- wizard                                                                                           
|       |-- __init__.py                                                                                  
|       |-- add_new.py                                                                                   
|       |-- wizard_export_lang.py                                                                        
|       |-- wizard_import_lang.py                                                                        
|       |-- wizard_module_import.py                                                                      
|       |-- wizard_module_lang_install.py                                                                
|       |-- wizard_module_upgrade.py                                                                     
|       |-- wizard_update_module.py                                                                      
|       `-- wizard_update_translations.py                                                                
|-- report                                                                                               
|   |-- corporate_defaults.xml                                                                           
|   |-- corporate_odt_header.xml                                                                         
|   |-- corporate_sxw_header.xml                                                                         
|   |-- custom.xsl                                                                                       
|   |-- custom_default.xsl                                                                               
|   |-- custom_new.xsl                                                                                   
|   |-- custom_report.xml                                                                                
|   |-- custom_rml.xsl                                                                                   
|   |-- custom_view.xml                                                                                  
|   `-- rml_template.xsl                                                                                 
|-- res                                                                                                  
|   |-- __init__.py                                                                                      
|   |-- bank.py                                                                                          
|   |-- bank_view.xml                                                                                    
|   |-- country.py                                                                                       
|   |-- country_view.xml                                                                                 
|   |-- ir_property.py                                                                                   
|   |-- ir_property_view.xml                                                                             
|   |-- partner                                                                                          
|   |   |-- __init__.py                                                                                  
|   |   |-- crm.py                                                                                       
|   |   |-- crm_demo.xml                                                                                 
|   |   |-- crm_view.xml                                                                                 
|   |   |-- partner.py                                                                                   
|   |   |-- partner_data.xml                                                                             
|   |   |-- partner_demo.xml                                                                             
|   |   |-- partner_report.xml                                                                           
|   |   |-- partner_view.xml                                                                             
|   |   |-- partner_wizard.xml                                                                           
|   |   |-- report                                                                                       
|   |   |   |-- __init__.py                                                                              
|   |   |   |-- business_card.xml                                                                        
|   |   |   |-- business_card.xsl                                                                        
|   |   |   |-- partner_address.xml                                                                      
|   |   |   `-- partner_address.xsl                                                                      
|   |   `-- wizard                                                                                       
|   |       |-- __init__.py                                                                              
|   |       |-- wizard_clear_ids.py                                                                      
|   |       |-- wizard_ean_check.py
|   |       |-- wizard_sms.py
|   |       `-- wizard_spam.py
|   |-- res_company.py
|   |-- res_currency.py
|   |-- res_currency_view.xml
|   |-- res_lang.py
|   |-- res_lang_view.xml
|   |-- res_request.py
|   |-- res_request_view.xml
|   |-- res_security.xml
|   `-- res_user.py
|-- rng
|   |-- board.rng
|   |-- calendar.rng
|   |-- form.rng
|   |-- graph.rng
|   |-- inherit.rng
|   |-- tree.rng
|   `-- view.rng
`-- security
    |-- base_security.xml
    `-- ir.model.access.csv

15 directories, 138 files

kde client http://bazaar.launchpad.net/~openobject-client-kde/openobject-client-kde/5.0/

čitao sam uputstvo (openerp book) pa hvatao engleske knjigovodstvene termine

reconciliation - pomirenje, izmirenje

reconciliation, balancing --
(getting two things to correspond;
"the reconciliation of his checkbook and the bank statement")

• General accounting (or financial accounting) is for identifying the assets and liabilities of the business. It’s managed using double-entry accounting which ensures that each transaction is credited to one account and debited from another.
• Analytical accounting (or management accounting, or cost accounting) is an independent accounting system which reflects the general accounts but is structured along axes that represent the company’s management needs.
• Auxiliary accounting reflects the accounts of customers and/or suppliers.
• Budgetary accounts predefine the expected allocation of resources, usually at the start of a financial year.

... they’re reconciled to each other (sum of credits = sum of debits).

Usually, different transactions are grouped together and handled at
the same time rather than invoice by invoice.
This is called batch work or lot handling

OTVORENE STAVKE:

• at data entry for the accounting statement
• manually from the account records - ručno zatvaranje stavki
• automatically using Open ERP’s intelligent reconciliation. - automatsko zatvaranje stavki

In a single reminder you’ll find the whole set of unpaid invoices as well as unreconciled payments,
such as advance payments.

Povrat naloga (računa) po default-u nije dozvoljen:

By default Open ERP won’t allow you to cancel an invoice once it has been approved.
Since accounting entries have been created you theoretically can’t go back and delete them.
However in many cases it’s more convenient to cancel an invoice when there’s an error than to produce a credit note and reconcile the two entries. Your attitude to this will be influenced by current legislation
in your accounting jurisdiction and your adherence to accounting purity.

hehe accounting purity

Various methods of creating accounting entries can be used. You’ve already seen how an invoice creates its own entries, for example.

• managing bank statements
• managing cash
• manual journal entries

write-off -- (the act of cancelling from an account a bad debt or a worthless asset)
=> cancellation (the act of cancelling; calling off some arrangement)

• losses or profits,
• exchange differences,
• discounts given for rapid payment.

write-off - zatvaranje razlika - zaokruženje

dispute, difference, difference of opinion, conflict --
(a disagreement or argument about something important; "he had a dispute with his wife";
"there were irreconcilable differences"; "the familiar conflict between Republicans and Democrats")

kontrola knjiženja

Control of data entry (prenosni konto)

In accounting it’s not a good idea to allow a data entry directly from bank account A to bank account B.
If you enter a transaction from bank A to bank B the transaction will be accounted for twice.

To prevent this problem, pass the transaction through intermediate account C.
At the time of data entry the system checks the type of account that’s accepted in the bank journal:
only accounts that aren’t of type Bank are accepted.

If your accountant defines this control properly,
non-accounting users are prevented from transferring payment from one bank to another, reducing your risks.

petak sam čitav dan utrošio na openerp

ono što je krajnje interesantno je njegova hackabilnost, o tome dosta govori ovaj rails - openbject projekat koji uvezuje openerp server sa rails aplikaciojom

openobject on rails

Why?

OpenERP has lot's of built-in business modules (350+) and makes it really straightforward to create/customize business applications. That's complex persistent data-models
featuring
- ACID transactions on PostgreSQL
- role based
- modular
- integrated BPM (Business Process Management)
- integrated reporting system
...

In a word OpenERP really rocks when it's about quickly creating the backoffice of those enterprise applications. OpenERP is a bit higher level than Rails (for instance it's component oriented while Rails is REST oriented) so if you adhere to the OpenERP conventions, then you are done faster than coding a Rails app (seriously).
Adhering means: you stick to their views, their widget, their look and fee*l, *their way composing components, their ORM (kind of ActiveRecord), the Postgres database ...

But sometimes you can't afford that. Typicall examples are end users application like e-commerce shops.
So what happens if you don't adhere to the OpenERP framework? Well that's where Ooor comes into action. It allows you to build a Rails application much like you want,
where you totally control the end user presentation and interaction. But Ooor makes it straightforward to use a standard OpenERP model as your persistant model.
An other reason why you might want to use Ooor is because you would like to code essentially a Rails or say web appication
(because you know it better, because the framework is cleaner or because you will reuse something, possibly Java libraries though JRuby)
but you still want to benefor from OpenERP features.
Finally you might also want to use Ooor simply to expose your OpenERP through REST to other consumer applications. Since Ooor juts does that too.

pregledao sam http://www.openerp.tv/ screencat: "Open Object in action Post : 21-04-2009"

pola toga nisam pohvatao ali sveukupno screencast pokazuje da je openerp odnosno openobjects zaista moćan za office aplikacije

takođe sam podesio na 143 amd-u (jaunty i386) openerp ... tu sam dosta izgubio na setovanje baze.

• podesiti da se openerp-server (/usr/bin/openerp-server ... exec python -> python2.5) pokreće sa pyhton25
• instalirati python-xml sa (pokupiti tar.gz sa interenta, pa onda python2.5 setup.py)
• kreirati usera openerp, ALI NE I BAZU kako README.Debian kaže ! Naime sa OpenERP 5.0 inicijalno se baza uvijek kreira sa klijentom - preskočiš inicijalnu authentifikaciju pa onda ideš na kreiraj novu bazu i tu te openerp provede kroz wizard

OpenERP za dodavanje novih opcija ima uvijek set wizarda za podešavanje tekućih postavki ...

ma koncept njegovih pluginova je zaista dobro riješen

šta ne radi: naša slova (ali sam našao post kako to da se podesi)

šta mi se ne sviđa: reporti koje sam vidio mi se generalno nisu svidjeli, recimo xtuple openrpt je puno moćniji onoliko koliko sam brzo pohvatao

šta je openerp moćno riješio: definiše view-ove, menije (čak i workflow čini mi se) u xml fajlu, te iste xml-ove koristi i rich i web klijent

web klijent mi izgleda responsivan, a i dobro izgleda; rich klijent me nije fascinirao ali nije ni rugoba

činjenica je da taj generički pristup koji koriste klijenti za widgete ne daje neki high level look&feel ali definitivno nije rugoba

moram reći da je za novog korisnika orjentacija kod unosa podataka upitna

posebno za naše korisnike bi enteri izazvali niz nepoželjnih akcija

http://pydev.sourceforge.net/download.html

• Urls to use when updating with the Eclipse update manager:
  • 1.4.3 onwards: http://pydev.sourceforge.net/updates/
  • Nightly builds: http://nightly.aptana.com/pydev/site.xml

• Get zip releases: SourceForge download

• Eclipse 3.2, 3.3 or 3.4 (python requires only the platform release, and jython also requires JDT)
• Python and/or Jython
• Java 1.4 or higher

http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine

http://blog.bigcurl.de/2009/04/running-sinatra-apps-on-google.html

http://code.google.com/p/magento-openerp-smile-synchro/wiki/GettingStartedWithOpenERPDev

detaljna analiza openerp-a, istina sa stanovišta jednog pravog openerp fun-a

Python and OpenERP - why¶

Anybody with say 2 years of experience in any object oriented language like Java, PHP5 or C++ is able to catch up with the minimum required level of Python programming for OpenERP in one to two weeks. Beginners can even start on Python although they will need more time.

Also bare in mind that despite not being that popular Python is one of the simplest object oriented programming language around. It's probably because Python states "there should be only one way to do things". Python is also a good trade-off between a first class OOP abstraction and a good speed: almost an order of magnitude faster than PHP (while still being an order of magnitude slower than Java or C++; there is no free lunch). Of course, those are only algorithmic considerations. Better productivity leading to more time for architectural or database optimizations always make more difference. And Python is still rising in popularity, reaching rank #6 in the famous Tiobe index.

Also, believe my deep comparison or check by yourself, OpenERP requires somewhat 10 times less code than Java ERP's around to do the same functional stuff (let's call those two "Java based" even if they are actually more like PSQL/procedural coding oriented, at least for their business code layer, which unfortunately is the one that matters) Needless to say OpenERP actually does much more instead. Just investigate data migration, cost of customization, versatility, fixtures loading, project management, CRM, complex stock management...

Finally, this would be quite off-topic, but I think the key why Python or any good Dynamic OOP language (like (J)Ruby) is the good choice to build an ERP is because an ERP really needs both functional flexibility and a good relational database persistence system. But achieving both modularity, runtime data model flexibility and a static language like Java is really a hard thing that real Java ERP's generally failed to achieve so far.

Indeed, in a static language, the OOP model, mapped to the database structure is supposed to be mostly fixed at compilation time. Gaining runtime flexibility like with the application dictionary of Compiere or Openbravo means too often losing some OOP power like inheritability or encapsulation. Oh yes that would still be possible, but that would mean over-engineering an ERP platform just like OSGI or the Eclipse RCP. Ultimately, you'll find guys able to do that. But will they do it as open source and will they master also the functional part of an ERP? Quite unlikely. So choosing a static language as the main language for an ERP results either in non functional/non mature boiler plate code, either functional code that is really to badly designed to fit any different context without a ton of non maintainable coding. So a dynamic OOP language is the good choice, at least for the business layer of an ERP.

Also, for those fearing runtime errors in OpenERP because it uses a dynamic language, I would say that in OpenERP:

• there is roughly 5 times less code than is an equivalent Java language based code, or even 10 times less code than a procedural ERP like SAP, Openbravo or Compiere. So that's much less code to watch for the same features. Also bare in mind that PLSQL, HSQL, JSP, XML IOC like Spring and all those usual techs won't provide you more static security either: they are dynamic stuff too even if they are bad at OOP.
• OpenERP comes with a bunch of unit and functional testing.
• The compiler might do less work, there is a huge community testing the software, that's valid too.

So Finally, a dynamic language such as Python is a very good choice for an ERP.

hernad: i ja ovo mislim

The runtime errors that might occur will always be discovered and fixed at implementation time, so they will not be a trouble at runtime.
Why the hell didn't they used Rails instead?

Well, first you might know that Python and Ruby are really close, almost as close as C# and Java. No question Rails is an outstanding framework. But building a full blown ERP is not an easy task, building a business mature ERP won't take less than 3 years. This is not only about getting the technical platform right (while that's a minimal condition and I predict resounding failures of leading brands because they didn't really passed that first stage), this is also about getting all the functional right, and since the functional stuff is too large for a unique open source team, this is even about getting a true (unlike some hyped oss products around) community catalysis right. OpenERP achieved all that, no too shabby.

• the ORM is dynamic ActiveRecord pattern, with similar extra features like single and multiple table inheritance and associations.
• ORM with two cache levels since OpenERP 5. Almost as good as Java Hibernate, but much easier and versatile...
• the code is very DRY all the way. Not a single duplicated line.
• MVC architecture.
• Stateless design. Rails wins here because it's also fully HTTP REST compliant while OpenERP doesn't benefit yet the idempotence of most of HTTP methods and use HTTP POST instead to tunnel its XML/RPC, while also supporting the fast NetRPC protocol (similar to Java RMI) or HTTP via eTiny, more specifically a thin Turbogears/CherryPy layer), but that's not as RESTful as Rails yet.
• fixtures with several formats (CSV, XML, no Yaml yet) with fixture relative ids like in Rails 2.x which make loading demo or config data a piece of cake unlike with other ERP's.
• no HQL or yet an other scripting SQL language wrapper like Hibernate, but, just like the Rails ActiveRecord philosophy a simple CRUD ORM API + an easy way to fire custom pure SQL request whenever it's required.
• built'in unit test infrastructure. Not as good as Rspec, but hundred times better than what other ERP's offer.
• Unlike Rails, OpenERP views are a pure XML simple widget components oriented dialect with no interpreted code inside. That's because an ERP doesn't claim to be as flexible as a shiny web2.0 HTML page but rather focus on productivity inside the ERP interface paradigm. Still, the eTiny extra layer can offer that flexibility if you really want too.

1. Rails was not available yet when OpenERP has been built.
2. Rails would boost ERP productivity by say 10% only. But running 10% faster while starting 5 years late would make absolutely no difference at the end; this is really not like running 5 times faster than the Java language and starting almost at the same time. So I believe 10% this is not enough to make the difference considering all the other involved factors like functional perimeter, quality of the governance, community momentum...

Finally Python and OpenObject are by far good enough for OpenERP to be the best ERP around, and I would bet quite heavily that no product will ever pass it in the coming next 5 years at least, this is very much written already.

Smile OpenERP Synchro

openerp translator: https://translations.launchpad.net/~josip-c

evo šta srbijanci pričaju na temu ERP rješenja: http://arhiva.elitesecurity.org/t343597-Informacioni-sistem-pod-linuxom

bzr clone

hernad@nmraka-5:~/devel/bzr$ bzr clone lp:~openerp/openobject-server/trunk openobject-server
...

hernad@nmraka-5:~/devel/bzr$ ls

openobject-addons  openobject-client  openobject-client-web  openobject-extra-addons  openobject-server

hernad@nmraka-5:~/devel/bzr$ du -s -h

353M    .

http://www.nan-tic.com/index.php?option=com_content&task=view&id=10&Itemid=11&lang=en

OpenERP

OpenERP is an open source ERP (Enterprise Resource Planning) and CRM (Customer Relationship Management) Software that allows the combination of the best of ERP programs with the best of custom made software.

With OpenERP you will have the advantages of an ERP with constant innovations but with the possibility of making modifications and new sections as you'd have with a custom application.

KTiny is the project we carry on at NaN which uses the solid base of OpenERP and extends it to offer a new set of possibilities such as full text search, text recognition or appearance customization. Everything using technologies offered by Qt and KDE on Linux, Mac and Windows.

hernad@nmraka-5:~/devel/bzr$ bzr clone lp:~openobject-client-kde/openobject-client-kde/trunk openobject-client-kde

hernad@nmraka-5:~/devel/bzr/openobject-client-kde$ find -name jasper

./server-modules/jasper_reports
./server-modules/jasper_reports/jasper_report.py
./server-modules/jasper_reports/jasper_demo.xml
./server-modules/jasper_reports/demo/partner.jasper
./server-modules/jasper_reports/report/document_header.jasper
./server-modules/jasper_reports/report/report_header.jasper
./server-modules/jasper_reports/java/lib/jasperreports-3.1.4.jar
./server-modules/jasper_reports/java/lib/js_jasperserver-common-ws-3.0.0.jar
./server-modules/jasper_reports/java/lib/jasperreports-chart-themes-3.1.5-SNAPSHOT.jar
./server-modules/jasper_reports/java/lib/jasperreports-dejavu-fonts.jar

hernad@nmraka-5:~/devel/bzr/openobject-client-kde$ find -name "*ui"

./Koo/ui                                                           
./Koo/ui/about.ui                                                  
./Koo/ui/searchviewitem.ui                                         
./Koo/ui/searchreference.ui                                        
./Koo/ui/tree.ui                                                   
./Koo/ui/admin_passwd.ui                                           
./Koo/ui/searchform.ui                                             
./Koo/ui/error.ui                                                  
./Koo/ui/choosedb.ui                                               
./Koo/ui/dbcreateok.ui                                             
./Koo/ui/video.ui                                                  
./Koo/ui/binary.ui   
...

http://en.wikipedia.org/wiki/XML-RPC

Some people prefer XML-RPC to SOAP because of its simplicity, minimalism, and ease of use.

JSON-RPC is similar to XML-RPC.

http://ws.apache.org/xmlrpc/

http://www.ibm.com/developerworks/webservices/library/ws-pyth10.html

a ovo ide preko unix socket-a izgleda a ne preko http protokola

    protocol = {
        'XML-RPC': 'http://',
        'NET-RPC (faster)': 'socket://',
    }

openerp koristi turbogears koliko sam pročitao za web klijenta: http://turbogears.org/

http://docs.turbogears.org/1.0/GettingStarted/BigPicture

• CherryPy makes it easy for your controller to get information from the web and string together all of the pieces that comprise your website.
• SQLObject makes it easy to define and work with your model.
• Kid makes it easy to generate good HTML for the browser.
• Additionally, the combination of MochiKit and JSON make it easy to implement complex in-the-browser behavior and can even be used to format output in AJAX requests that skip over Kid.

http://www.sanjaypatel.name/2007/07/why-i-chose-turbogears.html

Before I express why I chose Turbogears, I must confess that I am essentially a business application developer and not an expert in python or web technologies. I do not claim my choice to be the right one, and comments are most welcome.

...

...

I was happy evaluating RoR, until I found out that the default ORM of RoR does not support certain things like composite primary keys, and hence it might be difficult for me to integrate to existing enterprise databases, or develop complex applications.

This left me with Turbogears and Pylons. Among these two, Turbogears seemed more complete, having many readily available/integrated components like identity management and widgets.* I felt that if I went with Pylons, I might still have to write some top level layers or plumbing code, which Turbogears could readily provide. Also, Turbogears was much more mature and popular, having a big user group, from which I guessed that development and debugging would be faster.

http://blog.feedly.com/2009/03/03/jsonrest-vs-xmlsoap/

ovi ljudi svakih par dana izbace nešto novo i to nešto pravo dobro

http://openerp-team.blogspot.com/2009/05/faster-formating-of-html-reports-using.html

http://openerp.com/forum/topic5572.html

here are several differences. Although module availability and functionality are key issues for a particular decission there are also some other important things to consider. Module availability is subject to change in just a few months depending on the community push on any of the projects.

License:
- TinyERP is GPL. With all the pros and cons of it
- OpenBravo has it's own license which is not OSI approved. In fact, I doubt it matches the Open Source Definition, but "Open Source" is not a trade mark so they can claim OpenBravo is an open source project if they wish. They say in some places that it's a Mozilla License but it has an added clause which would be problematic... (http://www.openbravo.com/product/legal/)

Technology:
- They are both based on MVC architecture with some differences
- TinyERP is Python and Postgresql basicly.
- OpenBravo is java, the client is only a web client (although it should be possible to build a different kind of client like Compiere used to have) and although it support several databases their origins are Oracle only. I've heard of some performance issues when Oracle is not used but I wouldnt bet my left hand on that....

Hardware:
- Openbravo is far more demanding than TinyERP even for small installs. Tiny runs on anything....

Ease to tweak:
- Tiny has a very simple core. After some study it's possible to easily achieve very complex tasks. Example: to modify the behaviour of a field type for an specific object is easy and you can find many examples on the modules repository.
- OpenBravo has a nice application dictionary which can help doing many things. If you need go further the code is very complicated: you need to invest quite a bit in education....

Scalability:
- Probably OpenBravo will scale better. I would say that permissions, access managemente etc. is better. (key issues when going large scale)

Community:
- I think TinyERPs community is formed by individuals while at the moment the OpenBravo community is a network of partners. I know they are trying hard to build a community hiring people with experience on the subject (the leader of that area being a former Gnome developer) but I wouldn't say they have succeded yet.

History:
- AFAIK, TinyERP is what it is based on it's success and openness.
- OpenBravo has some big financial support behind: the money was there before the recent success.

Anyway, I think it's good to have different choices. I would say that OpenBravo is targeting on the middle run to larger firms while TinyERP is probably a better choice for SMEs.

Regards,
Pedro

novi posto:

Hi all,

I've been comparing several open source ERP's for some 2 months now for http://www.smile.fr.

I specially looked at TinyERP and OpenBravo, so far my conclusion are:

TinyERP is probably is best on all points. OK, Openbravo might be a little more sexy graphically, but except that I think it's really not as good. Still I would rate OpenBravo number 2. In my opinion Openbravo already outperforms Compiere or will do that during this year if not yet.

for OpenBravo vs TinyERP, I would say:

• OpenBravo is very weak on CRM
• OpenBravo is very weak for services companies
• OpenBravo might be better on POS, while not even sure
• generally speaking OpenBravo has no modularity (hernad ispravka: verzija 2.50 ima module) and won't have soon, so lot's of TinyERP plugin goodness isn't available in TinyERP. So ERP verticalization is not for tomorrow for OpenBravo will it looks in the close future for TinyERP. Functionnal verticalisation is already happening, only a proper packaging will then be required.
• OpenBravo is way too weak on French accounting which matters for us.

• OpenBravo is REALLY inferior to TinyERP. It's modeled at a very low relationnal level (see the pl/pg/SQL code!!!) ((hernad ispravka: verzija 2.50 ima hibernat DAL) whereas TinyERP has true domain object models. So the code of Tiny is small, comparatively bug free and easy to understand withe a predictible behavior. OpenBravo recognize the weakness of their platform, they are promising Hibernate ORM and Spring for modularity, but all that won't be available before 2009 and will still be marginal among the code. Moreover Hibernate is a good ORM but it isn't scritable like Tiny one, so it will still not reach TinyERP flexibility, even by 2010, no way!
• TinyERP exposes all the datamodel though webservices while on OpenBravo you should hardcode the webservice for every service you need! So it make it expensive to ineterconnect with other legacy bloatware.
• Given all the ugly legacy code behind OpenBravo, it's totally impossible OpenBravo to ever compete with TinyERP, even considering the 6M investment beghind it. I would say that 80% of the development effort is wasted into maintaining the ugly SQL code instead of increasing features. Also a lot of their money is wasted into marketing. Only very little money goes into the features. As a result they aren't many.
• As some said, once you need to customize behind simple data structures (specialized method on objects, worlflows (no BPM on OpenBravo...)) OpenBravo is really inferior to TinyERP.

Want to have fun? Go into the src of OpenBravo and try: grep -ri "storage of tires", you'll find plenty of dead code from the beginning of Compiere around year 2000 at Goodyear Germany (same thing happens in Compiere too BTW). So 7 years and 6M later, they aren't able to clean their code. No reason they can do it tomorrow. The codebase is just too ugly. I'm following their SVN and can attest lots of pg/SQL bugs are corrected, meaning there are lots of bugs and you can't trust all that coded blindly.

So, yes you can consider OpenBravo, it's far from evil, but it's really hard to find out one reason to prefer it over TinyERP. Nonetheless, OpenBravo is certainly better than lots of others players, including Compiere and ERP5 and Ofbiz (and probably also Neogia until it's big enough). Also, given the investment, it's even possible they become profitable while probably not the best option. I wish they will as they might still offer better service than a proprietary ERP.

I know that some issues with Tiny are pretty tough (Linux and eTiny installation, interface, marketing, functional details)... But overall I think Tiny is a great product promised to a great future. Praise for it!
By the way, Smile.fr will publish an accurate white paper about ERP's in French in some 3 weeks. So keep in touch.

Hope this helps.

Rapha�l Valyi.

i ja sam uočio da openerp nema kvalitetan pos modul.

treba uočiti da je openbravo pos modul java swing app, da je GPLv3 i da se veže sa drugim sistemima preko web servisa ... tako da uopšte ne bi trebao biti problem integrisati to sa openerp