I am looking for an accounting package to use for the back-end grunt work for a PHP application, and am evaluating what is available. What I can't tell, is just how the API interacts with the accounting functionality of OpenERM.
From what I can tell, the API I have seen described in the docs is one that is designed to split the very front end GUI interface of the ERP system from the business functionality. So the API supports the GUI pages, if I understand it correctly.
What I would be looking for is something lower level than that - I may want to generate an invoice, accept a payment, add an account, update a contact, move cache between ledger accounts, create and apply a credit note, etc. Is the API able to support that kind of need? If there are any examples of this being done, I would love to see it. But so far, I simply cannot find any examples or documentation that puts it all into context, so I just cannot tell if OpenERP is the tool I need.
Just by comparison, I have looked at Xero, and the API is spot-on, just what I need. The problem with Xero is that it aims itself at companies of a limited size, with a limited number of API transactions. They have firmly drawn a box around their aimed market segment. Being Open Source, OpenERP is more limited by the resources that you want to throw at it, so you have more control. That's cool, but I still need to see how I would use it before investing more time into exploring its use in our wider systems.
The OpenERP API can definitely do what you want, and the reason is very simple: the UI indeed uses that very same API to talk with the backend. So what the UI can do, you can do it programmatically too.
However the OpenERP API is designed in a completely generic way: it is structured around
models (i.e. business classes backed by database tables), which by default only offer a very simple set of methods: the CRUD basics, named
unlink()) + some utilities like
export_data(), etc. Have a look at the technical documentation for the details. The technical memento may also be a good reference.
So in this sense the API is not business-centric, but the advantage is that you only need to learn one set of methods to access everything in the backend. As long as you know a given model exists, you can interact with it using the basic API, introspect it, follow relationships, etc. And that's what the UI does: to create an invoice it will call the
create() method of the relevant model, passing the data that has been input by the user.
Accounting being implemented by OpenERP models like anything else, it is easily accessible using the API, for example:
- You can access invoices and refunds using the API of the
- You can access journal entries and journal items (the double-entry bookkeeping) using the API of the
- You can access payment vouchers using the API of
account.voucher, and bank statements via
Now, in addition to the pure CRUD part, most business models will define extra bits of API:
- Business workflows are defined on the main models (invoices, sales orders, etc.), and are driven by signals sent to the workflow when users click on certains types of buttons
- Extra API and helper methods may be defined and called indirectly by CRUD methods or bound to certain buttons on the screens
Discovering and mastering those is required if you plan to do complex things on the backend without using the UI. But they're obviously specific to each model and not well documented. The best way to learn is to read the source code of the the relevant business models you're interested in. If you're not sure where to start, one helpful thing to do is to watch the API in action by looking at the RPC calls sent by the UI when you go through the relevant business flows. To do so you can either use the network debugger of your browser and watch the XHR calls, or start the OpenERP server with the
--log-level=debug_rpc_answer option and read the extra log.
To answer the last part of your question, yes there are many users who are using the OpenERP API to manage their business data remotely from other applications (including invoices, accounting, and everything else). Unfortunately I do not have any code pointer to share, as most of them are doing that for specific use cases dealing with other proprietary products, or simply do not consider their use case generic enough to publish the source code. Perhaps other people could elaborate on this by providing links?
I hope that helps a bit...
Please try to give a substantial answer. If you wanted to comment on the question or answer, just use the commenting tool. Please remember that you can always revise your answers - no need to answer the same question twice. Also, please don't forget to vote - it really helps to select the best questions and answers!
About This Community
|Asked: 3/24/14, 8:41 AM|
|Seen: 2001 times|
|Last updated: 3/16/15, 8:10 AM|