• 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!

Sales Order Document Types

KathleenC

Member
Hello Everyone

Would anyone know of a way to secure the document type in the order entry
programs.

We have users that should only be able to enter/change certain types of
orders.
Setting a default order type in the processing option is not enough.

Thanks in advance.

Kathleen Cripps
Project Leader JDE AS/400
Footmaxx Inc
Toronto
 

scott_parker

Reputable Poster
If you have any in house programmers have them turn on the indicator that
would "Protect" that field. In JDE 8.1 cume 2 it would be *IN31.

It is of course not as simple as it sounds but it does work. You just need
to find the right spot to put the code change.


Scott Parker
Grote Industries, LLC
mailto:scott.parker@grote.com





Scott Parker
Grote Industries, LLC.
WorldSoftware Version 8.1.2 AS/400 V4R5
 

prumschlag

Active Member
We had the same problem and ended making a program change to prevent modifying
this field on the screen.

Phil







KathleenC <KathleenC@footmaxx.com> on 04/05/2001 03:14:57 PM

Please respond to jdeworld@jdelist.com








To: jdeworldml@jdelist.com

cc: (bcc: Phil Rumschlag/PHD)



Subject: Sales Order Document Types








Hello Everyone

Would anyone know of a way to secure the document type in the order entry
programs.

We have users that should only be able to enter/change certain types of
orders.
Setting a default order type in the processing option is not enough.

Thanks in advance.

Kathleen Cripps
Project Leader JDE AS/400
Footmaxx Inc
Toronto




--------------------------
 
We also made a program change to protect the order type field in order
entry. But beware of clever operators. Ours would go into customer
service inquiry and inquire on the order type they should not be changing.
They would then use a 1 to go to order entry, press enter to "finish" the
current order and then have an open order entry screen to enter the order
type they should have been secured from. You can use the option security
to block order entry option 1.



scott parker
<scott.parker@grot To: jdeworldml@jdelist.com
e.com> cc:
Sent by: Subject: RE: Sales Order
owner-jdeworldml@j Document Types
delist.com


04/05/01 03:42 PM
Please respond to
jdeworld






If you have any in house programmers have them turn on the indicator that
would "Protect" that field. In JDE 8.1 cume 2 it would be *IN31.

It is of course not as simple as it sounds but it does work. You just
need
to find the right spot to put the code change.


Scott Parker
Grote Industries, LLC
mailto:scott.parker@grote.com





Scott Parker
Grote Industries, LLC.
WorldSoftware Version 8.1.2 AS/400 V4R5
--------------------------
 

kobuss

Member
We have a similar situation where operators change purchase order detail
such as discount percentage (accidentally) .....how can we protect one
field on the purchase order ?

Thank you
Kobus Snyman
kobuss@sabn.co.za

SA Bank Note Co.



KathleenC
<KathleenC@footmax To: jdeworldml@jdelist.com
x.com> cc:
Sent by: Subject: Sales Order
owner-jdeworldml@j Document Types
delist.com


04/05/01 10:14 PM
Please respond to
jdeworld






Hello Everyone

Would anyone know of a way to secure the document type in the order entry
programs.

We have users that should only be able to enter/change certain types of
orders.
Setting a default order type in the processing option is not enough.

Thanks in advance.

Kathleen Cripps
Project Leader JDE AS/400
Footmaxx Inc
Toronto




--------------------------
 

DBelcher

Active Member
Kobus,

The only way I know to protect either field is through a program change. I
just recently had a request from a user to not allow blank Order Type and
that is controlled through the UDC 00/DT and blank is a valid entry. Since
I could not remove the blank entry I had to change the program to not allow
blanks. So, if you don't want users changing a field accidentally and can
do the programming, I would think you could protect the field based on an F
key and use it as a toggle with it defaulting to being protected. If the
user then needs to change the field, use the F key to toggle the protection
off. If you never want them to change the field then just protect it.

Hope that helps.

Doug Belcher
KV Pharmaceutical
St Louis MO
Opinions expressed are not necessarily those of my employer


ard=W&Number=8685


Doug Belcher
St Louis MO
Opinions expressed are not necessarily those of my employer
 

dale_draper

Well Known Member
How does the video design aid tool work?
Go to SVR, Inquire on V4210 (the video for SO entry) If you type a "10" next
to it, you actually can do some design changes on the video I think.
 

DBelcher

Active Member
Dale,

The problem with removing a field from a video is what happens if there is a
legitimate reason to change the contents? If the need is just to protect
against accidental changes, then it might be better to use either an F key
to toggle on/off the protection or a confirm message if the contents are
different from the expected. Many times I've had users swear up and down
that a certain field will NEVER change, just to turn around a short time
later and say we HAVE to be able to change it for JUST THIS ORDER, AND RIGHT
NOW!

Doug Belcher
KV Pharmaceutical
St Louis MO
Opinions expressed are not necessarily those of my employer





Doug Belcher
St Louis MO
Opinions expressed are not necessarily those of my employer
 

dale_draper

Well Known Member
Gotta love it, the perpetual user problem, wants to do everything, be
responsible for nothing.

I had a user who insisted on having commaned line access with no knowledge
of OS400, nuttin, been using a green screen for about 3 weeks. The user just
would not allow that this could ever be a problem. Turns out they *needed*
it in able to run the fastpath "WS" ( wrksplf ). I made a CL and added it
(under a different command) as both a Fastpath and HS.

My VP that I report to thought I was being a control freak "taking away"
command line access from the user.

Fun stuff.
 

SLewis

Member
Some people will never learn until a user like that types in the wrong
command and all $$^&*( breaks loose. Problem is the blame for it never lands
on the user that did it, but rather IS because we gave the user the ability
to do it.

Stephen R. Lewis
Application Systems Administrator
CCL Custom Manufacturing
Rexdale Plant
11 Bethridge Road
Etobicoke, ON Canada
M9W 1M6
Phone: (416) 740-7400 ext155
Fax: (416) 743-5439
email: slewis@rex.cclcustom.com




Steve Lewis
CCL Custom Manufacturing
11 Bethridge Rd.
Toronto, ON Canada
M9W 1M6

A73 cum 8, 720 V4R4
 
Top