On Wed, Sep 07, 2005 at 01:35:53PM -0400, Timothy Miller wrote:
> On 9/7/05, Jack Carroll <[EMAIL PROTECTED]> wrote:
> > On Wed, Sep 07, 2005 at 07:36:23AM -0400, Timothy Miller wrote:
>
> [snip]
>
> > For discussion, I'll call everyone who initiates creation of a
> > document, or addition of a part to inventory, a "designer".
> >
>
> [snip]
>
> At the moment, with three designers, assigning part numbers won't be a
> problem. But as the organization grows, we'll need something like
> what you describe. This looks like something I could throw together
> using a basic LAMP setup. And I could add something to read/write
> backups in ASCII form that's also human-readable.
Yes. Of course, it's too soon for this to be a priority. At the
beginning, one designer could probably keep the number log as a
tab-separated text file, made visible through a web site. A Wiki or a
custom application could come later.
Would you like me to continue developing the number system? The
next step would be the first draft of a category list. To do it quickly,
I'll have to stay with FrameMaker, and convert the document to OpenOffice
later on. (From what I've been hearing, OOo 2.0 should be adequate for
table-heavy engineering text documents, but I haven't yet climbed that
learning curve.)
We will also need a format rule so that product part numbers (aka
catalog numbers) can be generated fairly freely, without colliding with the
internal stock numbers for piece parts. They'll exist in the same MRP data
base and inventory, so they must be distinguishable. I've been thinking
about that, but don't yet have a firm suggestion. The idea I'm playing with
is this:
A product part number must begin with at least two letters or an integer of
at least four digits. Beyond the required initial characters, the root
number for a family of products may have any format or internal structure.
A stock number for an off-the-shelf part must have a category code of either
a single letter or an integer of no more than three digits. The category
code must be terminated by either a character from a different subset at the
beginning of the family field, or a dash.
A part number for a product-specific custom part can begin with the root
number of the product family, then continue with the category and family
fields. (My last company used that format, and it worked well. I'll put it
in the next revision of A-100A1.)
One side effect of that format rule is that a well-known commercial
part number like RC07GF-103J couldn't be imported intact. We would have to
call it R-C07GF-103J, or do some other ugly hack. That's why I want to
think about this a while longer, and look for a more elegant solution.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
