Isn't segregating parts by class code (there are 4 class code groups to work
with) a better idea than trying to set customized part numbers? Whether it
be a part number, a sales order number or whatever unless you are simply
using unique prefixes for your own reporting purposes, I don't think it is a
good idea. Just my opinion.

-----Original Message-----
From: Johnson, Tracy [mailto:[log in to unmask]]
Sent: Thursday, February 27, 2003 3:56 PM
To: [log in to unmask]
Cc: [log in to unmask]; [log in to unmask]
Subject: RE: [MANMAN:3995] String Permutation -- Why
Importance: Low

-----Original Message-----
From: [log in to unmask] [mailto:[log in to unmask]]

> In a message dated 2/27/03 2:13:14 PM Pacific Standard Time,
> [log in to unmask]:
>
>> But in answer to this thought, in MANMAN, isn't
>> the "Maintain A Part" screen a viewscreen?
>> Seems like it could be compiled to accept a
>> template for a valid part number customized
>> for the company's needs?
>>
> Now how would that 'template' work?  Simple pattern
> matching is one approach.  That would > eliminate many
> many bad p/ns from being entered.  Many companies have
> multiple patterns in place though for varying product
> lines.  The really slick approach is to have an ability
> to 'know' what future p/ns will be.  That's where I got
> stopped in my thinking.  Storing potential p/ns in a
> dataset would work but it's kind of a big waste.
>
> wonder if anyone wrote a p/n FORMAT validator for new
> p/ns?
>
> Wayne

My thoughts revolved around old fashioned 9s, dashes and
alpha (0/9 - A/z) screens in certain character positions
for the part number.

In MANMAN G/L, this is done for the G/L account number
after all (but only numerics and dashes.)

Tracy Johnson
MSI Schaevitz Sensors

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *