FACTS 7.7.2 Order Entry

Having an issue with order entry in FACTS 7.7.2 on a Linux platform. The line entry process is not responding quick enough for quick order entry. We have customers that have large orders, and order entry clerks that enter these orders very quickly. All of their item numbers are numeric, so they are only using the 10 key to put the lines in. The issue is that the item number is entered, enter is pressed, then the quantity, however after the enter on the item, focus has not yet moved to the quantity field, and the quantity entery is lost. This is holding up the go live for a couple of our customers. I am looking for ideas on how I may be able to solve this. The hardware is way above the recommended requirements. I also tested this on a Windows environment with the same results. Has anyone been able to overcome this?

Find more posts tagged with

Comments

Legacy Contributor

Mic,
You may want to try this feature and see if it works better for you.

From the FACTS help text – and available in v7.5
Quick line item entry (Order Management Suite)
This feature is available in SO Order Entry, Order Confirmation, Direct Invoice Entry, Counter Sale Entry, Credit Memo Entry and SR Service Order Entry.
Use it to reduce keystrokes and speed up line-item entry.
To use Quick Line Item Entry:
Enter the item number, the ordered quantity and then press the down arrow key (ê). The program inserts the default information in the rest of the line-item entry fields and returns to the Item Number field.
To quit Quick Line Item Entry:
Press F4 at the Item Number field or choose the Cancel button at the right of the screen.

If it does not meet your needs, contact me directly.
Gary

sandra-kingsland

We are having the same problem with two of our 7.7.2 customers. The only solution so far is to tell them to slow down. Related to the same issue is getting null item lines in "SORSOL" and "PORPOL". Both customers have gotten this and I managed to reproduce just once. It is related to focus and type ahead issues. Customers loose patience waiting and are pressing and clicking everything in sight. I wish Tim would put something in his driver to stop the writing of null item records.

Legacy Contributor

Thanks for the replies. The real issue is the delay from entering the item and getting to the order qty field, and the delay to enter the next item. I had already set up line entry using the enter key to behave like the down arrow, as they are entering items via the 10 key.

[Updated on 9/24/2010 2:18 PM]

Legacy Contributor

Any further updates on this issue?

0904080939293831.xls

Legacy Contributor

It appears that I was able to increase the speed a little bit by removing a number of fields from the line entry screen via the SO Entry Options F/M and mainting the SMPRMT fields for prompts that are not in the F/M. It is easy for this customer due to the fact that they do not back order anything, so no need for the backorder or commit fields. On the header in line entry, only have customer, ship to, order date and request date. Everything else has been removed. It does help a little bit, but still sluggish.

slonschek

I did some testing when you first posted this issue. The delay is in validating the item number and refreshing the screen. I was able to get past the issue by changing the driver to switch the order quantity field before the item number is validated. It didn't seem to cause any problems, but my testing was very limited. I think with a little testing you could get it to work by putting a 'multi_line goto CTL_VALUE' early on in item validation or the 3 level entry driver. I was able to capture all the input using this method. It also requires a change to the 3 level entry driver to prevent it from writing to the field once the user has entered input. Basically once the item is validated it refreshes the screen, during that process it writes variable contents back to the fields. I had to prevent this to keep the driver from overwriting the data that was just typed in.

Legacy Contributor

Has anyone created an incident for this issue? I tried looking in the KB but no matter how I try to narrow the results, I only get 20 unrelated articles. We're in a go-live situation and it's causing users grief, since there's nothing they can do themselves to delete the order lines with blank item#'s.

irma-zamot

What we found today is when I have the "add" highlighted in the body of the order, if I hit enter 3 times fast it creates a null line item in SORSOL. If I hit enter twice fast when "add" is highlighted, the item is left blank and the focus is on the order qty field. Causing users grief when the message comes up to 'enter item " " at another terminal. Only way out seems to be CTRL C and then call us to remove the null lines from SORSOL. Anyone have a fix?

Legacy Contributor

hello,

Received this from InFor. Installed and it did help.

Event Note:
Cain,

This has been reported and the following fix will be included in the 7.7.3 incremental update. Being it's SME997, I believe this would affect most if not all entry programs in FACTS. Please make the change and let me know if it takes care of the problems.

PROGRAM LINE DATE
SME997 10027 09/07/10 old line:
new line: print 'CI',

Thanks,
Steve
DUL12201

Legacy Contributor

I can confirm that here. 3 quick taps on the enter key creates a null item line. Duplicated on a standalone Windows demo and also on a Windx session connected to a Unix server.

[Updated on 10/29/2010 7:13 AM]

NEVERMIND. I see a fix came through while I was goofing off.

Legacy Contributor

Yes everyone, the good news it is fixed. The Dev team has been working harder than ever and the 7.7.3 inc that comes out next Friday will be pack with goodies. Everyone should try to get their customers to that release. Way to Go Dev Team. Now Jim Morton get back to work

Here is the fix again for those who missed it

PROGRAM LINE DATE
SME997 10027 09/07/10 old line:
new line: print 'CI',

DUL12201

Legacy Contributor

Adding the 'CI' to SME997 has fixed the issue for our client as well.

Copyright © 2025 Infor. All rights reserved.