Re: What are the dangers of changing the return type of a subprocedure?

Mike,
.
The problem is not the return value.

Your problem would be the value of "dInvoice"

Invoice numbers should be sequential without gaps. yo are changing the
format and lay out of the value thus breaking the rules. Do not think the
financial department, auditors and other financial control agencies would
like that.

Regards,
Carel Teijgeler

*********** REPLY SEPARATOR ***********

On 10-2-2012 at 9:54 Mike Wills wrote:

I don't know what I was thinking when I wrote it (I'm sure I thought I was

cleaver) but I wrote a subprocedure that pulled the next invoice number.

That in itself is good, but then in the calling code, I had to do this:

dInvoice = %subst(%char(%date():*iso):1:7) + '-' +

%subst(%editc(GetNextInvoiceNumber():'X'):2:7);

WHAT THE?!? Ideally it should be:

dInvoice = GetNextInvoiceNumber();

Normally I wouldn't re-factor things like this, but now other software

will soon be creating invoices and needs to get invoice numbers. What
dangers

are there in changing the subprocedure from a decimal return field to a

character? I have tracked down all of the programs that call this function

(that I know of). Or should I create a new subprocedure and leave the old

one just in case I missed something? For course if we change the format of

the number, we will quickly have problems that way.