This is more of a functional qus.
Consider the scenario
Multi-step route is configured(pick and deliver)
A huge order is delivered with back-orders, let's say in 3 partial deliveries
Now, the sale has 6 entries (3 for pick and 3 for WH/OUT)
Is there a way to identify which pick is related to which out-delivery ? If yes, what is the relational field ?
Thanks.
Yes, there is a way.
Picking documents has a relationship with stock moves. Stock moves have a relationship with stock moves called Linked Moves (Origin Moves & Destination Moves).
How can you verify this data?
Go to Inventory > Reporting > Stock Moves
Find your PICK document number as a Reference
Open record in a form view and verify record in Destination Moves.
If you open a destination moves record, it will show you relation OUT picking record in a Reference field.
Example:
While trying to understand Odoo model for delivery slips I have realized that some stock_moves rows do have procurement_id populated and others do not.
Why is this? When is procurement_id populated?
Procurement_id is populated when the stock move is generated by a procurement. Stock moves created by a sale order are created throught a procurement. A stock move created by purchase order will not have a procurement id because purchase orders do not create stock moves.
As I am attempting to set up a new installation of Odoo I am trying to figure out how to use the manufacturing tool correctly.
What I am trying to do is take a roll of material and cut it down to sheets. In this case one roll equals 30 sheets.
Is there a way to tell Odoo that when I request 10 sheets that it should use the entire roll and create 30 sheets so that I'm not left with a fraction of a roll?
EDIT: I figured out that i can set the product rounding of the consumed item to be set to one full item. But now i have a different problem. If I ask Odoo to produce say 40 items it will produce exactly 40 and use 2 rolls, which means im missing 20 items. Is there a way to set the produced quantity to a factor of the amount of items i can get out of the roll?
You could create:
A product called sheet-Unit
Then in the BOM page of the sheet-unit you write 40 units under quantity and you put your roll as BOM. Basically you're saying that 40 unit of sheet-unit = BOM
Sheet for sales (your sales product) BOM = 1 sheet-unit
Then test it.
When you sell a sheet-sales-product and a sheet-unit is needed according with your settings (make to order - manufacturing - minimum qantity in stock-etc) a MO for 40 sheet should start.
I am developing a custom module for OpenERP 7 that will track hardware installed in various venues. I have the total stock levels recorded in the Warehouse module, but I want to be able to calculate and display amount of each product that is available and the amount that is currently deployed. I'm having trouble figuring out how to do this. I have been looking at this rent module and they seem to do something with stock picking and workflows, but I'm new to OpenERP and not really sure how that works.
The other way I was thinking of was to loop through the deployments and simply calculate the amount of each item, and use functional fields to display it, but I'm not sure if that would even work, or how to do it without hard-coding all the various items.
Have a look at product.py in the stock module, specifically the get_product_available method. This allows you to pack various filter parameters into the context and then it calculates and returns stock as the net of inbound and outbound stock moves.
This method also gets used in the functional fields qty_available, virtual_available, incoming_qty and outgoing_qty. There is reasonably good explanations in the help comments in the module.
In OpenERP, something is in your stock when there's a stock move (object stock.move) with that product to your physical location as destination location, defined on Warehouse object for "Inventory Location" field. Let's say you have recorded 2 moves:
Move 1
Source Location: Supplier
Destination Location: Stock
Qty: 2
Move 2
Source Location: Stock
Destination Location: Deployed Products
Qty: 1
If you open your products list you'll see that you have 1qty of your product available. OpenERP sums all the moves for that product to and from your Stock location. So if you have no other specific needs, recording moves to some sort "Deployed Products" location should be enough.
I am making a small personal application regarding my trade of shares of various companies.
The actions can be selling shares of a company or buying. Therefore, the details to be saved in both cases would be:
Number of Shares
Average Price
Would it be better to use separate tables for "buy" and "sell" or just use one table for "trade" and keep a field that demarcates "buy" from "sell"?
Definitely the latter case - one table, simple one field (boolean) defining whether it's selling or buying. You should define tables by entities, not by actions taken on them.
This is actually a tricky one. The table you're talking about is basically a trade table, detailing all your buys and sells.
In that sense, you would think it would make sense to have both buys and sells in a single table.
However, in many jurisdictions, there is extra information for a sell order. That piece of information is which buy order to offset it against (for capital gains or profit purposes). While this is not necessary in a strict first-bought, first-sold (FBFS) environment, that's by no means the only possibility.
For example, under Australian law, you can actually offset a sale against your most recent purchase, as long as you have the rationale written down in clear language before-hand. Even though my company follow FBFS, I am allowed to receive bonus issues or supplemental shares which I can then sell immediately. These are offset against the most recent shares bought, not ones I've held for X number of years (this is often handy to minimise taxes payable).
If you follow a strict FBFS, then you don't need that extra information and your trades are symmetrical. Even where they're not, I've implemented it in one table with the extra information, useless for buy orders of course. That seemed the easiest way to go.
You could do it as two asymmetrical tables but that makes queries a bit more problematic since you often need to pull data from both tables. My advice is to stick with a single table with the extra information if needed.
I would also never store the average price. I prefer the quantity, the price per share and the brokerage costs. Every other figure can be calculated from those three, for example:
AvgPrice = (Brokerage + SharePrice * ShareQuant) / ShareQuant
but it's sometimes impossible to work backwards from just the average price, since you don't know what the brokerage was.
And I wouldn't have a boolean for buy/sell, it's just as easy to use negative numbers for the sell orders and it makes balance-sheet-type calculations a lot easier since you just sum values irrespective of the order type instead of needing to negate some of them depending on that order type.
Update: If, as you seem to indicate, you're only going to store aggregate information for each company, I would go for the following:
Companies:
CompanyId primary key
CompanyCode indexed
CompanyName
CompanyBuyQuant
CompanyBuyAvgPrice
CompanySellQuant
CompanySellAvgPrice
then you update the individual columns depending on whether it's a buy or sell. You don't need a separate row for the buy/sell stuff. When the company is first added, both quantities and prices are set to 0.
Your entity is now the company so this makes more sense. One thing you may want to consider is to store the aggregate values of shares bought and sold rather than the average buy and sell prices. That will simplify your update calculations and you can still easily get the averages by dividing the aggregate by the quantity.
So, the following table:
Companies:
CompanyId primary key
CompanyCode indexed
CompanyName
CompanyBuyQuant
CompanyBuyValue
CompanySellQuant
CompanySellValue
When adding a company, set all quanities and values to 0,
When buying M shares at N dollars each, add M to CompanyBuyQuant and N * M to CompanyBuyValue.
When selling M shares at N dollars each, add M to CompanySellQuant and N * M to CompanySellValue.
Get average buy price as CompanyBuyValue / CompanyBuyQuant.
Get average sell price as CompanySellValue / CompanySellQuant.
I'd go with a single table.
You can use negative quantities to indicate a sell. This is a fairly standard sort of indication. Subtraction is the same as adding a negative number!
One table. Each row/item is a trade, whether it's buy or sell.
Also, the aggregate of the quantity column will give you your current position. And cash too (-1 x quantity x price**) aggregated.
Buy or sell if inferred by the sign of the quantity: no need for separate column, unless you want to make a computed column derived from quantity.
**cash: When you sell (negative quantity) you get cash back (positive cash), hence -1 multiplier in case anyone wonders.
"Trade" can be ambiguous and it's not entirely clear to me what you want to do here. Are you interested in storing only your current position in each share or also the history of transactions that show how the position developed?
If you just want to record your holding ("position" might be a better word if you can be short) then I'd simply record for each share the number held. You mention average price, but I'd be cautious about that if you expect at any time to be able to sell part of a holding. What's the average price if you buy 100 at 50, 100 at 60 and sell 50 at 70?
Unless you expect your buy and sell transactions to number in the millions, I'd be more inclined to record each individual purchase or sale as a separate row in a single table and show the totals on demand as the derived results of a simple query.