[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Purchase parts/services same as sales?
- Subject: Re: Purchase parts/services same as sales?
- From: Keith Nybakke <..hidden..>
- Date: Mon, 15 Jan 2007 19:48:01 -0600
Title: Re: [Ledger-smb-users] Purchase parts/services same
as sal
At 4:12 PM -0800 1/15/07, Josh Berkus wrote:
I think that it may not cover a lot of
cases. Let's not rush this.
I agree.
This is a vexing set of problems.
Before working out a solution, please give just a little more
consideration to the problem.
There are basically two pools of resources that we tap. One is
labor and the other is materials. In a job shop, these are just lumps.
The labor has no value until it is expended on a specific job, before
which it was simply an expense. Materials are very similar. They don't
have value beyond their costs until they are transformed by labor into
something of value to the customer.
I am seeking a solution that captures the actions that add value
but generally ignores the non-value-added states of labor and
inventory. You may think of this as activity-based costing and you
wouldn't be too far off.
The points in a job shop work flow that are important to capture
are:
quotes/estimates/proposals
sales orders or work orders or job orders (they all have
basically the same information, just different formats)
productive labor expended on specific jobs
materials consumed by specific jobs
shipments
invoices
payments
Of course, the last three are easy. Any accounting system can
capture those. In fact, there are hundreds of accounting programs for
conventional manufacturing or conventional service but not very many
for job shop work flow.
Labor and material consumed by a job can be accounted for. But,
because each job is different, the material cannot be part of a
typical assembly bill-of-material like those prepared for stock items.
If there is a bill of material and an assembly, it is short-lived and
is of no further use after the product is shipped.
I understand that a similar bill of material might be generated
for a similar project in the future, but it really is not related to
any previous bill of material, even if it is identical to some
previous bill of material. I think this is important. It is tempting
to think that we can just create a template or something and then
modify some things to make it unique. It is much better to make the
construction of every unique bill of material so easy that re-using
previous bills of material doesn't provide any benefit.
And beyond that, we can have the situation where we can
relate to inventory or materials as a lump of assets to pull from as
needed without the need for any bill of material.
If you can view inventory as just a lump of material, then the
material can be consumed by specific jobs as needed.
Accounting for that material as raw material inventory and as a
not-for-resale asset makes the most sense to me.
This allows me to purchase these materials using a conventional
purchasing system with part numbers and standard prices, but I don't
track the material out of inventory in the conventional manner with
pick lists or part kits. I just increase my inventory when a shipment
arrives and I reduce my inventory when a shipment is made to a
customer. The job tracking information (work orders) will be loaded
with material consumption numbers as the material is consumed, but not
as part of a scheduled assembly.
This is another key difference between conventional manufacturing
and job shop production. We care whether we have enough material, but
we can't schedule its consumption, like with an MRP system. We
purchase common materials as needed, using a system like a kanban or
demand flow. Unique materials are purchased for jobs specifically and
only when a sales order says its okay to buy the unique
material.
So, to sum up, I need a system that records quotations, turns
them into sales orders and allows manual entry of labor and material
consumed, by job. This is a job shop system, in its simplest
form.
Should I keep working with Ledger-smb, or am I describing
something that is not part of 2007 work?
Thanks and best regards,
Keith