RE: Expanding the A/P Invoice

In these cases I tend to overstate the quote by a large amount to discourage
the fools from taking the route entirely.   If they are then stupid enough
to do so anyway you should look good when you come in under.  This only
works on a time and materials baisis rather than fixed price. 

If you want a quote from a 10year BPCS developer to pass on to them,  "Don't
be insane, look for a workaround"

As you point out its not only the initial cost of this that is a pain, its
the on-going cost of maintenance with BMRs etc.  I'm not entirely sure how
CEA macros work so that could be a core problem but it certainly extends the
issue outside of just ACP.  You could use As/sets impact of change function
to get a guide to whats affected.  

Honestly I think the cost of this versus the pain of resolving the cause of
the problem with their vendors is very one-sided.

Best of luck

Regards
Graham

> ----------
> From:         George Sagen[SMTP:gsagen@primesourcetech.com]
> Sent:         03 May 2000 19:12
> To:   BPCS-L@midrange. Com
> Subject:      Expanding the A/P Invoice
> 
> Yikes...
>  
> I have yet another client wanting to expand the A/P Invoice # from 10 to
> 15 digits. He has his reasons and is willing to invest, but wants to know
> what it would take. I told him I thought a programmer would want to take a
> week just analyzing the problem before giving a serious quote (client
> want's fixed bid). Has anybody had experience doing this? I'm interested
> in hearing how it went, what you encountered, etc. My client expressed his
> opinion that it seems like it should be easy and shouldn't take long. I
> related the following and want to know if I missed anything:
>  
> Table changes on any table that could store the A/P invoice #. (dozens?)
> Code changes to any program that refers to the A/P invoice # in any
> fashion. (thousands of lines?)
> Screen layout changes for panels that contain the A/P invoice #. (dozens)
> Report layout changes. (dozens)
> Testing. (weeks and weeks if you do it adequately)
> Refitting each time they want to apply a BMR. (?????)
>  
> I'm really discouraging them from doing this, but they have many
> vendors--freight carriers in particular--that use long invoice #'s. They
> don't like the solution of putting in the last 9 digits followed by A, B,
> C,... for each duplicate, then putting all 15 digits in the description
> field. Far be it from me to tell folks how to spend their money, but my
> gut feel is the workaround is better. Any thoughts?
>  
> Geo.
>  
>  
> George Sagen, CPIM, CNE
> gsagen@primesourcetech.com
> http://www.primesourcetech.com
> PrimeSource Technologies, Inc.
> A Metamor Worldwide Company
> (801)360-6360
>  
> 
**********************************************************************
 This email and any attachments are confidential and solely
 for the use of the intended recipient.  They may contain
 material protected by legal professional or other privilege.
 If you are not the intended recipient or the person responsible
 for delivering to the intended recipient, you are not authorised
 to and must not disclose, copy, distribute or retain this email
 or its attachments.  Although this email and its attachments
 are believed to be free of any virus or other defect, it is the
 responsibility of the recipient to ensure that they are virus free
 and no responsibility is accepted by the company for any
 loss or damage arising from receipt or use thereof.

**********************************************************************
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---