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

["Carel Teijgeler" <coteijgeler@xxxxxxxxx>]

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.