Odoo Experience 2017 – Key Takeaways (A)
While I did manage to make it to a few sessions on the final day, I decided to make myself content by annoying some of the exhibitors and Odoo staff at the open area and try to dot some more i’s and cross some more t’s.
So as I race across the flats on an Intercity Express to Netherlands, here’s a couple of summaries. It’s partly for readers, and partly as a way of documenting for myself and the technical team back home.
Let’s boost productivity and consistent test environments by using a CI tool like Travis CI - Not a trivial task to get happening, I do agree.
Potentially, we can test better if we create our development environments with Docker or similar – this is lower priority as it has rarely been an issue before..
A cheap and easy boost will be to increase the number of unit tests, and for moderate to large changes to get a “tour” which is automatically run in testing.
Getting developers to use pylint and others before making Pull Requests, and manually invoking test suites.
We need to implement more consistent revision numbering, and build in conversions based on these.
Our team need to increase the frequency they use tools like pyflame and flamegraph, and Odoo’s new line profiler.
We should standardise the way we work with git, using team members to work on branches rather than forks.
Implement the changes from our postgres knowledge that we have yet to take on.
In the area of Stock I have mentioned some of these things before, but I have tackled Odoo staff and have a bit more of an understanding. It is still listed here with the proviso that there are gaps in the information, and some of it is just not known at this point in time. Even the Odoo staff were unable to give me a firm answer for every question. Either they weren’t sure and will let me know (it is a big team), or the feature is not finalised, or they thought my ideas were good and would look to see if it would be a good approach in the future.
As I said, this is all to be taken with the understanding that it is just my current interpretation, not based on any documentation or viewing any code.
There is no longer a model for procurement.order. There still are procurements, pull/push rules and routes, and a dictionary of information is passed around which contains much of what procurement.order used to. I don’t know if this will make it hard for us to work out what order can from where, or whether it will now be easier.
This means there are no procurement exceptions, and procurement exceptions are raised in real time to the operator. If they come in batches (for example in stock min/max calculations), then the errors will be logged against the actual item and be mailed to the product owner.
There is a new model, stock.move.line, which replaces to some degree what stock.pack.operation used to do. The model stock.move now representss what the system wants you to do, stock.move.line is what will be done, and when complete, stock.move is what was done.
This new model can, to some degree, be hidden. It can be configured by operation type and wont appear on a separate tab.
Allocations can be optionally be ignored, either forcing the operator to key what lots and serials, will move or simply getting them to confirm what the allocation was by displaying it in the current way.
There will still be that anomaly where “original demand” reflects the final move quantity when the move is finalised, but the column will be hidden (a new feature in the API is conditionally hiding a complete column using attrs!).
The implementation of quants mean that they now act as containers with a balance, as opposed to a unit of stock that moves through the system, and they can now be combined. This is a BIG change to the architecture.
There will be negative stock quants created at the supplier locations.
Quants don’t have a cost (??!!??!!??) but maybe this will not be a problem – we need to look at the true impact on real time costing.
Certainly, FIFO costing has been improved and is now true FIFO costing! The first cost out will be the first cost in, company wide, not just by location. (This was really only FIFO allocation).
The stock moves in and out of the company have a concept of unmatched quantity (and cost) and this can be used to match up to outgoing moves. This is potentially a problem for returned items and adjustments (as an incoming will always pick up the last value), but is how FIFO costing is achieved. Individual clients will need to be consulted about whether this implementation is adequate – it is sound in its accounting principals.
Stock moves have a much better link to accounting moves. There appears to be some technically correct scenarios which end up looking odd on the screen, especially if a historical move is adjusted. This is where training in interpretation of the figures will assist, and a sound understanding of the accounting involved will allow us to make solid analysis.
Done stock moves can be unlocked and changed, but it is effectively a true manual adjustment back dated. Responsibility will lie with the operator if there are on-flowing consequences of this change (such as back order quantities on another picking).
Alterations to stock moves are dated at the stock move date, but the accounting adjustment is done at the current date-time. I suspect some people will want to turn off this new feature and force operators to do a true stock adjustment to fix a mistake.
Many2many links have been implemented both forwards and backwards in stock.move to dest_move_id. This is particularly to improve performance in pick-pack-ship environments.
Part B still to come - to round off the blogs for this visit to Odoo Experience.