Error in O/P Item Journal

[Chris Kelleher]

Has anyone seen the following error message on the opij report?

** Value cannot be displayed using >>>>>>>>9. (74)
The document # is "????????"

We think this may be causing the opij ( O/P Item Journal ) to not reset.

How do we correct this entry and does anyone know how it would have
occurred?

Best Regards,

Marti Carroll
Longchamp USA

ph 609-587-5300
fx 609-587-1818

 

[Chris Kelleher]

The value you are trying to display is larger than the defined display
format. In the simple case trying to display the number 10, in a field with
the format "9" produces the same error. You need to increase the size of the
display format to fix the problem, but I don't think it would case the
journal not to reset.

/* ================================================================= */

Programmers, with their inbuilt sense of order and discipline, should really
be running the world.

William E. Colls Tel 613 591 0079
PROComputer Systems Fax 613 591 3924
67 Willow Glen Dr www.procomsys.com
Kanata Ontario Canada K2M 1T1 PEG Member 1998051404

Specialists in Progress software development since 1985

 

[Chris Kelleher]

Sorry, I forgot to add that the document number is "?" because the
transaction was not completed, thus the inv-jrnl record retained its
original value of "?".

Best Regards,
----------------------------------------------------------------------------
-------------
Fiona Sumpton Voice: (416) 505.9864
MXP / Varnet Consultant Fax: (905) 887.6392
Business Systems Re-engineering Email: fionas@idirect.ca
Unionville, Ont.


Have modem, will travel

 

[Chris Kelleher]

Marti,

Quite often a user will do the dreaded 'ctrl-c' during the invoice
creation. This can result in an incomplete backout of all files. If thats
the case then for the record in question, the inv-jrnl.updated field will
= 'no' as will the inv-jrnl.completed field. If this is true, then you can
remove the offending inv-jrnl record by deleting it from the editor, and
re-running your OP Item Journal with reset = yes.


Best Regards,
----------------------------------------------------------------------------
-------------
Fiona Sumpton Voice: (416) 505.9864
MXP / Varnet Consultant Fax: (905) 887.6392
Business Systems Re-engineering Email: fionas@idirect.ca
Unionville, Ont.


Have modem, will travel

 

[Chris Kelleher]

Hi Marti,

We had a similar problem with one of our journal files in MXP 7.4. I found
that in/uomoutp1 and in/uomoutp there is some code (call #4002) that is
supposed to handle when the value is too big for the mask. It wasn't
working however. The following is the tweak I did but Foresight may have a
fix for this. Be careful since these functions are used through out the
system and require a full system recompile.

<BLOCKQUOTE><font size="1" face="Arial, Verdana">code:</font><HR><pre>
$ diff -bwti in/uomoutp in/uomoutp.o
6d5
< /* #01: WO150832: PJW: 01/03/2000: Fix bug if mask too small (call 4002
bug) *
/
47,48c46,51
< if t-abs-result > uom--max /* #01 */
< then do: /* #01 */
---
> if t-abs-result > uom--max and
> /* check this too because in some cases, even tho the
number
> is larger than uom.max-value, it may still fit in the
> uom--mask with no changes.
> */
> t-abs-result > (exp(10,t-num) - 1) then do:
[/code]

Hope this helps.

Patti Wilson

 

[Chris Kelleher]

To anyone who has been reading this thread......

I've been asked to provide a more complete answer to this from one of my
esteemed colleagues , who shall remain nameless due to his apparent
embarrassment about being confused

So here goes.....

In MXP 8.1d (and 7.4) the invoice.document number is initially set to the
seq-no * -1 (in Direct Billing). In Order Invoicing its set to recid * -1 .
I presume so as to retain an unique status within the invoice file while
processing multiple invoices.

Thus it follows that the inv-jrnl.invoice-no field would retain the same
value until the actual real invoice document number was found at the end of
the invoice commit. Since the value prior to commit is negative, it
follows that it would not fit in the mask of ">>>>>>>9" defined for the
inv-jrnl.invoice-no.

If a user were to ctrl-c at this point, then the transaction would
normally get backed out gracefully. However - in the case of DB and OI
functions, this does not always occur. Some orphan inv-jrnl records have
been known to stick around, creating problems with resetting the OP Item
Journal . The orphan records have a value in the invoice-no field that
does not make sense, until you consider the above.

Hope this has helped you. I would probably block users from using ctrl-c.


Best Regards,
----------------------------------------------------------------------------
-------------
Fiona Sumpton Voice: (416) 505.9864
MXP / Varnet Consultant Fax: (905) 887.6392
Business Systems Re-engineering Email: fionas@idirect.ca
Unionville, Ont.


Have modem, will travel