tehoLogistics

[brian]

I have released a program called tehoLogistics which is for managing production of the boards I make and the inventory related to making them.

A blog post with screencasts about and how to use the program can be found here:
http://teholabs.com/2012/01/tehologistics/

The source is MIT Licensed and can be found here:
https://github.com/teholabs/tehoLogistics

The documentation wiki page for the project is here:
http://teholabs.com/docs/tehologistics:overview

The main features of the program currently are:
* Imports invoices Mouser PDF, Digikey PDF, Arrow HTML (email)
* Keeps current inventory and average unit cost of application identical parts in CSV file
* Removes inventory via "building" lists (AKA making PCBs), lists defined externally via CSV file
* Look up and modifiy inventory data amount of single parts
* Check if parts are on hand for production of set of designs and create shopping list if needed
* Create buy lists for lowest cost source importable at Arrow, Mouser, Digikey parts needed a production run

I suspect there are bugs in the code and many cases I haven't see yet. Consider release 0.10 a very early alpha.

[spanner888]

Hi

very nice. Just had a quick explore for now, need to test with a couple of "my" projects to get the full feel!

Quick question - is your part lookup based on "Part Number 1" from "Source 1", and if present "Part Number 2" from "Source 2"?
ie does this mean you need a valid part number/source, or does the code use the the descriptive name for lookup, or only as the link between the inventory and the project lists?

[brian]

Good question spanner.

You must have at least 1 valid source. (If the CSV is malformed it will likely crash the program as it does no checks at this time.) The sources typically would come from importing an invoice.

That is you go do your part selection buy some parts and then import an invoice normally rather than changing the CSV by hand (however you can write the inventory by hand if you like). The number in "part number 1" would be the part number on the invoice.

For Mouser the number is the Mouser part number, Digikey it is the Digikey part number. Arrow uses the manufacture's part number as far as I can tell on the invoice.

On invoice import a part number is checked against all "part number X" fields. If it doesn't find a match it says the part doesn't exist in the inventory.

The description string is used to match against the "lists.csv" file. Therefore it needs to be unique but can be anything you want other than that. Category can be anything.

Edit addtional:
Completing the inventory CSV description let me say if you put something that cannot be parsed as a number in count or cost it will probably blow up also.

If your lists.csv looks for a part that isn't in the inventory it might explode (I don't remember it it just says OPPS on the command line or not).

You probably need at least 1 dummy part in inventory.csv to start with but I would just import everything from invoices.

Again, this is in no way complete software. Just the sketch of how it will work conceptually, and it seems to work okay for me with proper inputs in limited testing. So beware and have fun playing with it.

[ian]

Nice, I am going to check it out now.

[brian]

I think that means you are going to break it now. I expect many bugs. I only tested about 10 parts per source at most and the most recent invoices I had (one for each source).

When it explodes, the files I will need are inventory.csv and lists.csv then of course what commands were issued. Unless it is import invoice that blows up in which case I would need the invoice file.

I expect to have someone's wrath by the end of the day... But its free and open source so you are welcome to fix it also. ;-)

Since there was talk in the how do you manage your parts thread I just wanted to get it out there so people could see what I have been working on and the lines I was thinking along more concretely.

Also one item I want to mention that is talked about in the "code" screencast, that I don't remember highlighting in the "use" one is the fact that the abstract name say "0603 5% 330 ohm" can and probably should aggregate different manufactures parts. Pretty much all 5% carbon resistors are interchangeable so there is no reason to source only Murata or Vishay or Xicon. This happens with regulators and crystals and other things also, and is an important area in which the pricing feature goes beyond findchips or octopart like price minimization.

However it should be clear the software is really designed to keep the cost of repeated building to lowest value while keeping in house inventory small.

[ian]

I think that means you are going to break it now.

I'm primarily interested in the work flow you designed. I'm having trouble operationalizing a workable system for component management. Taking inventory is easy, but I've never found a useful/easy way to keep it up to date. Going to a website and "checking out" all the parts for a project seems...well, like a silly extra step. Importing the BOM is a good idea, but I always figured the difficulty is in the fuzzy matching (or anal retentive part naming). I'm going to peek into the source and see how you do it :) Maybe I can borrow it wholesale for our silly project manager.

[brian]

Going to a website and "checking out" all the parts for a project seems...well, like a silly extra step.

I am not sure what you mean??? The only time it goes to a website is when you want to place an order from a build list (IE I'm out of parts time to order new ones).

It has to get the current prices to find out what sourcing would be the best. Prices do change so it can't just keep that info from the invoice.

My BOMs (AKA part lists) don't say where to get the part only what part I need to construct an object.

It isn't just pricing either. In the end it will check stock and use a backup source (that might be more expensive) if there is nothing at the lowest cost one (this isn't in the code base yet).


Let me explain the logic of the cost finder a bit here:

PART A (LDO) :
Manufacture 1 (Ti) - > Source A, B, C
Manufacture 2 (ST) -> Source D, E

You file the Ti and ST LDO together. So all that maters is what the price is for A, B, C, D, E.

Let's say source D requires 60 units to buy but is cheapest. E requires 80 units to buy but is second cheapest. A is cheapest for 1 unit.

You ask for 10 units, it selects source A. You ask for 58 units it selects source D and buys 60 units, because rounding up is cheaper.

If D is out of stock and you ask for 50 units maybe it even buys E at 80 units rather than A. B and C might just be backup for quantity 1 sourcing.

You can't know any of this until you know how many you are going to order. You might get the cost info once and that might be good enough if the prices aren't moving around but out of stock handling requires you to go to the web every time so is designed to go to the web every time you want to source parts for when I add handling for out of stock parts. Plus it just makes the costing more accurate.

[brian]

Workflow Design: (numbers are command numbers in program)

Think of board design.
Select parts.
Design board.
Buy initial parts quantity.

A:
get parts in mail, import invoices in tehoLogistics (1)

B:
Make sure parts on hand for project (2) -> no: goto C; yes: continue
Sit down and physically build the boards
Withdrawal parts (3) - tells you what it cost to build what you just made
sell widgets for more than they cost to make
goto B

C:
source best cost for parts needed from "2" (5)
goto A

Edit: added (5) label

[ian]

No, no, I was saying that the work-flows I had designed involved some poor sap (eg, this guy) adding a new step to every project build: surf a crappy (DIY) web interface and 'check out'/buy/remove from inventory the parts for the project. Yuck. You use a BOM import, which is a fantastic idea. I'm sorry I was unclear.

If I were to play off this idea, I would import CSV into a php page, parse and match it to inventory, then display a 'invoice' of the programs best guesses (maybe drop-downs for unknown or multiple-options). Make sure everything is correct and hit update to update the inventory. Non-stock (eg new to your projects) and out of stock parts would be easy to identify, and shopping lists (at least a list of links to distributors) would be easy to show on a single page.

[brian]

Sorry I didn't realize you were talking about your system! Hopefully my basic like workflow explains how my program concept works for anyone who doesn't understand from the use video.

This discussion is helping me add to my doc wiki page.

[ian]

Yes, I am looting tehoLogistics' source for ideas for our internal system.

[Shaos]

I'm also thinking about creating my own inventory tracking software, because existing open source (and even commercial) solutions can't do simple task - adjusting cost of particular item in inventory to include freight-in cost (for example see here).

[brian]

I mentioned this on your comment in the blog post but let me expand on it here also.

I think to the extent possible including shipping overhead is essential. However it is difficult because pricing of shipping is based on weight and 10 units isn't linear to 100 units because of packing materials. Neither Digikey nor Mouser quote an exact shipping value until after sending them Therefore for pricing selection it will have to be based on estimation of shipping. And flat overheads are certain to make it into an upcoming version of part selection.

In terms of real costing of inventory, both taxes and shipping are factored in. The parts simply are weighted by the line item cost verse the total cost. IE an item that was 10% of the bill gets 10% of the shipping overhead and tax bill.

I think the estimated shipping will be good enough for cost efficiency. The only time shipping efficiency really matters is for very small orders, where there is typically less than 10 dollars of cost savings on single sourcing verse dual sourcing. For me it is important for sure but what is even more important is full overhead accounting and inventory control to minimize overall order numbers. You can always hold orders until shipping falls below a certain fractional cost as well.

[Shaos]

of cause freight-in cost can not be known until actual purchase (or even a few days later when they shipped purchased items and charged credit card)

about tax - should it be treated as expenses instead of including to cost?

[brian]

Personally I am only interested in cash flow not accounting in this. It is written solely to help me optimize overheads and inventory utilization. You are welcome to change it for your own needs. Depending on where you live tax might be deductible but that depends on accounting methods and all sorts of things, the place for that is a tax program not a cash flow or logistics program. Unit costs as written project the average forward cost of producing boards, which is what is important to set fair prices with acceptable margins when labor is included.