• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Slow system or no defence from accidental interruption?

Hello list, we came across the following problem.

When entering receipt (Procurement) of, say, 50 lines, JDE needs about 4-5
minutes in order to perform this operation and update all the files. After
pressing OK button at Enter Receipt - Purchase Order Receipts screen, the
system turns back to Enter Receipt - Work With Purchase Orders to Receive
screen. During these minutes the user just sees the screen, that doesn't
show any sign of life. Thinking that computer is hanging, they press Select
button, enter the Enter Receipt - Purchase Order Receipts screen and perform
receipts again by pressing OK button, while the program performs the first
receipt. So program creates double or triple receipts: for each line in
purchase orders - 2 or 3 receipt lines. Respectively the quantities, costs
e.t.c. are doubled or tripled. Then it is possible to match voucher to the
fiction receipts and to process further.

I presume that there are two possible reasons for the mentioned above
problems. First, the system works ultimately slow. Second, the system
doesn't disable buttons on the user interface in order to defend the program
from being interrupted during the processing.

Does anyone has idea how to improve the situation?
Regards,

Alexei Martkovich
Oracle 8i, HPUX, B733.2, SP13.3
 

Braseejde

Member
--part1_d9.10f1a7dd.27d10171_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

We had that exact problem when receiving several hundred lines. Since we
were importing data, we changed our process and loaded it in another way. Do
you also get the message threaded business function still processing when you
try and log out?

We did speed it up a bit by mapping the receipt function to the server
instead of locally. I know there were several related programs that had to
be mapped as well so you might want to get the info from JDE.

You may have already cleaned this up, but we also doubled our entries to
inventory and the G/L. It took quite a while to get our received not
vouchered integrity and inventory integrity worked out.

Good luck.

--part1_d9.10f1a7dd.27d10171_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><FONT SIZE=2>We had that exact problem when receiving several hundred lines. Since we

were importing data, we changed our process and loaded it in another way. Do

you also get the message threaded business function still processing when you

try and log out?



We did speed it up a bit by mapping the receipt function to the server

instead of locally. I know there were several related programs that had to

be mapped as well so you might want to get the info from JDE.



You may have already cleaned this up, but we also doubled our entries to

inventory and the G/L. It took quite a while to get our received not

vouchered integrity and inventory integrity worked out.



Good luck.</FONT></HTML>

--part1_d9.10f1a7dd.27d10171_boundary--
 
Braseejde,

thanks a lot for your info.

Could you just advise how do you map receipt function to server instead of
locally. Any reference to useful sites also will be highly appreciated.

Thank you inadvance,
Alexei Martkovich
Oracle 8i, HPUX, B733.2, SP13.3
 

sean_gilbert

Well Known Member
I have OVERCOME the very same problem. (if you can live with speed)

In the processing option of the receipt program P4312, turn on the option
to print the Receipt Traveler Document (#7 on the Process Tab)
This forces the system to update all the records BEFORE the user can click
OK to submit the Print Traveler Document.

In other words turning on this option won't allow the user to return to the
inquiry screen until all the update have been completed and the print job
submitted.

If you try to re-receive the same PO Line you'll notice that the lines are
gone.

This in no way increases the speed but it does ensure the inventory
integrity.

Sun Solaris, Unix, Oracle 8.0.6, Xe - Fat, Java, HTML

Sean Gilbert
JDEdwards Consultant
PricewaterhouseCoopers
Montreal

Tel: 514.205.5000 x3619
Fax: 450.655.0163



martkovich
<martkovich@g To: jdelistml@jdelist.com
um.ru> cc:
Subject: Slow system or no defence from accidental interruption?
03/02/2001
03:01 AM
Please
respond to
jdelist







Hello list, we came across the following problem.

When entering receipt (Procurement) of, say, 50 lines, JDE needs about 4-5
minutes in order to perform this operation and update all the files. After
pressing OK button at Enter Receipt - Purchase Order Receipts screen, the
system turns back to Enter Receipt - Work With Purchase Orders to Receive
screen. During these minutes the user just sees the screen, that doesn't
show any sign of life. Thinking that computer is hanging, they press
Select
button, enter the Enter Receipt - Purchase Order Receipts screen and
perform
receipts again by pressing OK button, while the program performs the first
receipt. So program creates double or triple receipts: for each line in
purchase orders - 2 or 3 receipt lines. Respectively the quantities, costs
e.t.c. are doubled or tripled. Then it is possible to match voucher to the
fiction receipts and to process further.

I presume that there are two possible reasons for the mentioned above
problems. First, the system works ultimately slow. Second, the system
doesn't disable buttons on the user interface in order to defend the
program
from being interrupted during the processing.

Does anyone has idea how to improve the situation?
Regards,

Alexei Martkovich
Oracle 8i, HPUX, B733.2, SP13.3




--------------------------
To view this thread, visit the JDEList forum at:
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=6540

*************************************************************
This is the JDEList One World / XE Mailing List.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found at http://www.JDELIST.com
*************************************************************



----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
 
Top