W650 Hands On: DynaChange Techniques

Transcription

1 W650 Hands On: DynaChange Techniques Pre-requisites: None DynaChange is a tool that allows system administrators to customize the screens that are displayed for end-users. This hands-on session will review the options available and demonstrate the power and benefits of DynaChange. Come see for yourself how you can secure fields and screens, change labels, colors, and more. Rainer Abendroth Software Support Wednesday, 3:45 p.m. 2 Session Objectives Provide a better understanding of the uses for DynaChange Designer Review features of DynaChange Designer Utilization and maintenance Tips and tricks Grid data windows and coordinate variables Explain the efficiencies gained by DynaChange functionality 2007 Activant Solutions Inc. All Rights Reserved

2 3 Return on Investment Opportunity Happier users provide better customer service Focused users are more efficient; less mistakes and quicker By securing users out of specific areas, you avoid security risks that may be costly to your business DynaChange Designer allows you to make your own changes in the system, thus eliminating costly customizations 2007 Activant Solutions Inc. All Rights Reserved 4 Additional Resources Don t forget Web-Based Training and web site solutions DynaChange Designer Professional Services PSS@activant.com Prophet 21 Solution Database 2007 Activant Solutions Inc. All Rights Reserved

3 5 Suggested Action Plan Start creating a Plan or security model If security exists, work backwards to map out the Plan 2007 Activant Solutions Inc. All Rights Reserved 6 Summary Enhancements can improve efficiencies and increase morale as well as securing users from private or privileged information How to group users and set security, how to modify visual appearances, how to set up shortcuts, how to review/edit DynaChange Tips and tricks and what to look out for with Grid DataWindows How DynaChanges can impact the bottom line 2007 Activant Solutions Inc. All Rights Reserved

4 7 Thank You For Attending W650 Hands On: DynaChange Techniques Rainer Abendroth Please submit the Session Feedback Form To receive NASBA credits, please be sure to complete the Session Feedback Form and sign the class roster in the back of the room 2007 Activant Solutions Inc. All Rights Reserved

5 T550 Hands On: DynaChange Techniques Whursday, 1:15 p.m.

6 This manual contains reference information about software products from Activant Solutions Inc. The software described in this manual and the manual itself are furnished under the terms and conditions of a license agreement. The software consists of software options that are separately licensed. It is against the law to copy the software on any medium, or to enable any software options, except as specifically permitted under the license agreement. In addition, no part of this manual may be copied or transmitted in any form or by any means without the prior written permission of Activant Solutions Inc. From time to time, Activant makes changes to its software products. Therefore, information in this manual is subject to change, and the illustrations and screens that appear in the manual may differ somewhat from the version of the software provided to you. Created by: Yardley Educational Services 2007, Activant Solutions Inc. All rights reserved. Activant and the Activant logo are registered trademarks and Activant Prophet 21 is a trademark of Activant Solutions Inc. All other company or product names are the trademarks or registered trademarks of their respective companies. Activant Solutions Inc Southfront Road Livermore, CA Version 13.0 Publication Date:

7 Lesson 1: Initial Decisions/Setup After completing this lesson, you will: Understand the difference between design and security Understand a security action plan Know how to create roles in the application Know how to assign users to roles and assign designer permissions 3

8 Purpose of DynaChange DynaChange has two main purposes. It can be used to visually enhance the application and it can be used as a security module. The feature was created to make it easier for the end user to interact with the application. The other option before DynaChange was created was to use Padlock. The Padlock application is very old and antiquated, and very hard to use and support. Where the Padlock application may offer some additional security features, DynaChange offers so much more. DynaChange can be used to allow individuals to modify screens and menus on their own. That has the effect of maximizing efficiency but it can also make the user happier. Making users happier with the application could have an increase in their morale and even customer service. DynaChange can also be used to secure individual users or a group from areas of the application. This has the effect of decreasing mistakes, since users will not be in unfamiliar areas, and improves efficiencies by allowing users to focus on their specialties. Also, using DynaChange alleviates the issues of needing to re-invent changes between upgrades. It is also easier to support as changes can be easily reviewed, tested, and understood. Design vs. Security In many small companies, security is not really an issue. If you have five main office people using the application, you may not be concerned with blocking access to modules, tabs, and fields. If this is true, the application allows you to grant permissions to the user to be able to make his own changes. On the other hand, with a larger company, you may be looking to use DynaChange as your security model. If that is true, you will most likely restrict the individual-users access to make their own changes. We will discuss the options more in this lesson but you should be aware that different companies have different needs and concerns. Note! If DynaChange is going to be your security model, you really need to start outside the application with a plan. One suggestion is to use an Excel Spreadsheet. The first tab could be all your employees and the roles they are assigned. A second tab could contain the main module list and who should have access where, followed by individual tabs for the modules to show or explain what module specific changes are happing for the users and roles. Of course there are other ways to start the plan but without a plan we have found that users are spending a large amount of time getting started only to find out they need to delete all and start completely over. 4

9 Step 1: Create Roles Roles were introduced in version 8.5. Before this point, any change that needed to be made required you to recreate that change for each user individually, creating a mass of work for an administrator. Now you can group users into roles and then make changes on the role level. Role-level changes apply to all the users assigned to that role. When this was first introduced, assigning a user a role was a mandatory part of user setup. Part of the upgrade process created a default role, which we labeled ALL, and assign every user to that role. Note! ALL <> ALL. Part of the initial process in getting started with DynaChange is assigning each user their specific role. Some example groups would be: Admin, Actng, Takers, etc. Effectively, you change the role they belong to from ALL to whatever role you created. Since they are no longer in the role ALL any current changes set up on the role would no longer apply to these users. Any future changes to impact ALL would not apply to these users. The recommendation is that you assign users to there actual roles and then delete the role called ALL. We created the first role with the name ALL so that is could be assigned to all users. For companies that were not using distinct roles this would be the only role ever needed. If you do need more than one role you should make sure to add the new role to every user and edit the role ALL to X or something with no significance. For today class we are going to create a role based on your initials. The role name should start with your initials and then end with _Group. Here is what I did to create the Rainer Abendroth Group. System Administration > Maintenance > Role Maintenance Leave the role_id blank and enter the role name: RA_Group Enter or Tab off the field and hit SAVE (the role_id is auto-assigned) 5

10 Step 2: Assigning Roles to Users Once the roles have been created your next step is to assign each user to a specific role. When you logged in, you used a specific user_id. Ex: Student_1. Please follow the next step using that user ID; I will use ADMIN in the example: System Setup > System > User Maintenance Enter the User ID (ex: ADMIN) Assign the role you just created to the user Take note of: Default Application After assigning the role to the user you need to decide how much designer rights to allow the user. This is where the security questions come into play. User level changes override the role level changes. If you re concerned about security, then allowing user level changes by the user may circumvent the security you are implementing. When concerned about security, it s best to assign NONE and then make user changes individually upon request. Note! Review each user s default application to make sure the user will not be set to default to a screen you intend to secure. 6

11 Decisions regarding what designer rights each user will have Designer Rights None User Role Both Definition / Description The user will not have access to DynaChange. Best suited for most employees if security is an issue. Changes will impact the specific user only. If security is not an issue, allowing users to make changes that effect only their applications allows you to personalize their experiences with the application. Changes impact the members of the role but userlevel changes cannot be made. This allows a group leader to make the required changes for his group without allowing that person to be singled out by the change. Changes can be made to the role assigned to the user and further changes can be made for the specific user. This would allow a manager to control the group but also allows that person to override the group settings if less restrictive access is needed for the manager. Note! When getting started, it is suggested that you create your needed roles, assign the users to those roles, and then use the role ALL for testing. You can even rename the role if needed. Also, create a test user ID. It is much easier to see how changes impact a test user assigned to a test role as opposed to pushing an undesired change onto a real user. In a later lesson we will discuss how to copy a tested version to another user or role. 7

12 Lesson Summary In this lesson, you learned about the differences between design and security. Then you learned how to create and assign roles to a user. Finally, you learned about assigning designer rights to a user. 8

13 Lesson 2: Module and Menu Security After completing this lesson, you will: Know the difference between module and menu security Learn how to set up module security Understand how to make changes to menu option Learn about version names and comments/description 9

14 Module Security vs. Menu Security Creating roles, assigning those roles to users, and assigning user rights should be completed before beginning with any DynaChanges. Once complete there are three major change types to consider: Menu Designer, Tab Designer, and Screen Designer. Menu Designer can be further divided into two parts. You have changes that affect what users see in the Module menu, and you have changes in each module s menus. The basic utilization of the Menu Designer feature is the same for changes that affect the Module menu and menu options in individual modules, but there is one large concern that makes it necessary to discuss each of these individually. That concern is in regards to how the application creates the Module menu, or maybe more like where. Module Security Consideration When you are in the Order Processing module, you can click on the Module menu to see a list of available modules. This list of modules was coded to appear in the Order Processing module. When you elect to go to the inventory module you may once again review the Module menu to see the same list of available modules, but once again, this list was hard coded to the Inventory module. In fact, every module has the same list of options but every module actually has the list hard coded to that specific module. What that means is that any changes to the Module menu only appear in the specific module where those changes were created. In effect, you need to recreate the same change in every module on the list, or at least where the user has access. Just like with the creation of roles, we saw a need from the user base to be able to make changes to the Module menu once and have those changes applied to every Modules menu in the application. In version 10.0 we released a feature that would do just that and this new feature is what now separates changes on the Module menu from other menu changes within a module. The feature is known as Apply to all modules and has adverse effects if used on regular menu changes or if menu changes are combined with module changes. Getting Started with Module Security Since changes to the Module menu only need to be made once, the recommendation here is to create all of these changes in the same area. Before you begin, let s assume five users use the role of administrator. Next we assume that each of these users may not be granted the same 10

15 permissions throughout the system. What you need to do first is find a module where full access is always available to the members in that role. We used to recommend that all these module changes be made from the Role Maintenance window in the System Administration module, but there could be adverse effects if a user in the administrator role needs a specific menu change in the System Administration module, like being denied from running SQL32 under the System menu. Historically, administrators usually have access to the Management Summary module, and once granted access there are usually no other menu changes needed on the user level in this area. Another option would be Credit Card Setup or Pricing Service. In order to create any DynaChange, whether menu, tab, or screen changes, you need to have a transaction window open. Menu Designer allows you to rename and/or disable the menu options. Let s start by going to: Management Summary > Inquire > Accounting view RMB > DynaChange Designer > Menu Designer New Expand Module folder Select a menu option. Ex: Contact Management (De)Select the Enable checkbox Change the menu name if desired. Ex: Contact Rolodex Depending on the role, repeat for all needed module changes SAVE If you hadn t noticed, the Save window appears slightly different for the ADMIN user than any other user. This window is one of the places where you will notice a few differences. The ADMIN user is hard coded to have extra permissions that no other user is granted. Even if you logged in as ADMINISTRATOR, SA, or even Hillary_Clinton, you would not have these additional features. 11

16 The following screens illustrate the differences: Admin User Regular User Notice the ADMIN user has the option Apply to All Modules (this reads Apply to All in versions below 11.0). The other difference is the Add Users checkbox. Having already discussed the theory behind Apply to All Modules, this is where you can elect to push a module change to every module so the change does not need to be recreated in every module. Be careful not to check this box when making other menu changes that should only affect the specific menu options in a particular module. The Add Users feature allows the administrator to see every user ID in the system when selected. Regardless of whether the box is enabled or not, the ADMIN user will always be able to see all roles. A regular user, with DynaChange rights set to Both will just see his user ID and assigned role. Let s continue: Add version = lesson2 and comment = contact change Select the roles available (xx_group) OK > OK > close window Note! DynaChange data is cached when a user logs in. In order to see changes made in a session, you need to log off and log back in to refresh the cache. Log off then log in with effected role/user ID to review change Notice that the change only exists if you go to the module where the change was created. Accessing any other module would show you that 12

17 change did not affect that module because as a regular user you do not have Apply to All Modules functionality. If you did log in as ADMIN but forgot to check the box, you would see the same result. This is also a good reason why you may want to first set up your changes on a test user with a test role. Also, I d like to point out once again that changes that affect the user override changes that affect the role. Menu Changes in a Specific Module Regular menu changes would be those changes that do not affect the Module menu. Once you are in a module, the other menu options are specific to that module. You would therefore need to interact with that specific list by going to that module and opening a transaction window in that module. For example, if I wanted to affect the RMA Receipt option under the Transaction menu of the Order Processing module, I would open the Order Entry window to get started. Aside from having a window open in the specific module, the regular menu changes work just like the module change we just discussed. Since the regular changes only affect the module you are in, we do not and should not use Apply to All Module functionality for these changes. Using Apply to All Module functionality with these changes would have adverse effects in other unrelated modules. Version and Comments When saving a DynaChange you will be asked to add a version name and a comment or description. The Version Name is what you will see when you review a list of existing changes. It is not until you elect to review the version that you will see the comments associated to the version. For that reason you should use a version name that is short and to the point. Your goal is to be able to quickly identify the DynaChange that needs to be reviewed in a list of changes. All changes are considered a version. Having the names Change1, Change2, Change3, etc. would not benefit you later when you need to review or edit the change. You also do not want long names, as they get harder to manage in list format. Using one or two words without spaces would be your best bet. When reviewing the DynaChange Version Manager later in this course, you ll understand the version and comment names more clearly. The comments should fully describe everything the version was designed to do. This is how you identify what you were trying to do, should you need to review/edit a change at a later date. Comments should be very descriptive, but use shorthand when possible because you are limited to 255 characters. 13

18 Lesson Summary In this lesson, you learned about menu changes and why module changes are treated separately. You learned how to make module and menu changes with consideration of the Apply to All Modules functionality. You should also have an understanding of useful version names and comments. 14

19 Workshop 0) With your current log in, set security in the Purchasing module to block the role you created from having access to the Inventory Returns option in the Transaction menu. 1) Log off and then log in as ADMIN. Set security to block access to all the accounting modules for just the role you created. 2) Log off and then log in with your student ID to review the changes. 15

20 Lesson 3: Tab and Screen Designer After completing this lesson, you will: Understand Tab Designer Understand Screen Designer 16

21 Tab Designer When you are in a particular transaction window you may find it necessary to block access to some of the available tabs. You may also want to hide a tab completely. In some cases, you may want to change the name of a tab to fit better with your industries nomenclature. This can all be accomplished with Tab Designer. Getting Started To affect a particular set of tabs, you will first need to access that transaction window. For example, to affect the Sales History tab in the footer of Order Entry, you would need to open an Order Entry window. Furthermore, since the tab is on the lower pane and you can t access the lower pane without existing header data, you will need to have some transaction information entered before you can continue. Here s a tip: Whenever you need to set up a DynaChange on a particular transaction window you should pull up a historical transaction. Having data that affects the tabs and screens makes it easier to make and review changes. Open the Order Entry window and pull up any existing order RMB on the header > DynaChange Designer > Tab Designer New Using the Tools Select Front Counter tab -- In the TEXT field, change the value from Front Counter to Printing Select Order Notes tab -- Deselect the Enable checkbox Select Totals tab -- Deselect both the Enable and Visible checkboxes Select Document Links tab -- Left/Regular click on the red box in the lower color pallet tool. SAVE Add version and comment and select the role you created earlier 17

22 Upon your next login you should notice when you access the Order Entry window, after you call up or enter data, the changes from above will be applied. Accent important tabs Was Front Counter Invisible Totals Disabled Notes It is important to note that you can disable a tab with required fields. If your defaults do not populate the needed data in those fields, and the user cannot access the tab, he will never be able to complete the transaction. The system basically allows you to shoot yourself in the foot, so to speak. On the other hand, you will not be able to block system controlled tabs. As an example, the Order tab is opened by the application when you open the Order Entry window. The system will not allow you to block access to this tab. It s important when making changes that you test those changes with a test user or role to verify the results are desired. Screen Designer The main goal behind Screen Designer is to change appearances. You can also incorporate security changes. This is very similar to functionality of Tab Designer. In a particular transaction window you may find it necessary to block access to some of the available fields, hide fields completely, and/or change the name of a field to fit better with your industry s nomenclature. This can all be accomplished with Screen Designer. Getting Started Like tab designer, you first need to access the particular transaction window upon which the fields exist. For example, to affect the Order Cost field in the lower pane of Order Entry, you would need to open an Order Entry window. Furthermore, you would need to access the Cost tab since 18

23 that is where the field resides. Like Tab Designer, since the field is on the lower pane and you can t access the lower pane without existing header data, you will need enter some transaction information before you can continue. Remember: Whenever you need to set up a DynaChange on a particular transaction window, pull up some historical transaction. Open the Order Entry window and pull up any existing order RMB on the header > DynaChange Designer > Screen Designer New Using the Tools Select the Quote field -- Click and drag this next to Order Number -- Left/Regular click the blue box in the lower color pallet tool. Select Customer Name (not Customer ID) -- Deselect the Visible checkbox Select Sales Location -- Right click the yellow box in the lower color pallet tool. Select Ship to ID -- Left click on green and right click on red Select the actual word = Taker -- In the text box change this to Desk Rep Select the value field for Taker -- Left click on pink and select the Bold and Italic font buttons SAVE Add version and comment and select the role you created earlier Upon your next login you should notice when you access the Order Entry screen, after you call up or enter data, the changes from above will be applied. Note that to affect the font color in a field we used a regular left 19

24 click on the color bar but changing the background color required a right click. Some things to note: First, like tab designer, you can disable a required field. If your defaults do not populate the needed data in those fields you will never be able to complete the transaction. Also, you cannot block fields required by the application. The other note here is in regards to shared fields. Notice that Validation Status and Credit Card Hold share a field. The code will use the correct field and value depending on the transaction status but will never need both fields at the same time. The screen capture shows I moved Credit Card Status down a bit to illustrate that fact. Shared fields appear like a mish-mosh in DynaChange 20

25 Lesson Summary In this lesson, you learned about Tab Designer and Screen Designer. You learned that you need to set these up in a specific transaction window or tab. We discussed how to make tabs and fields invisible, change their names or add protection. You also were shown how changes could enhance the interaction with the application. 21

26 Workshop You may have noticed a few additional screen changes in the previous screen capture. Go back and edit your DynaChange screen change to include these changes. 1) Set the job name = emp# 2) Reduce the size of the data field associated with emp# and center it over the PO: field 3) Set the background color for the PO: data field to Yellow and make the font color Red 22

27 Lesson 4: DynaChange Designer Version Manager After completing this lesson, you will: Know where to find DynaChange Designer Version Manager and locate existing versions by user and by role. Learn how to read the version names and how to review the details of a specific version to see what it was designed to do. Understand how to manage your versions via the RMB options. 23

28 DynaChange Designer Version Manager DynaChange Designer Version Manager was created to give you an overview of existing versions and allow you to review, edit, copy, and delete versions from a centralized location. The functionality was rolled out in the 10.5 release. Getting Started System Administration > Maintenance > DynaChange Designer Version Manager Once you are in the transaction window you have the option to review existing versions grouped by users or by roles. Expanding these folders lists all the users or all the roles that exist in the system. Further expanding a particular user or role folder displays the existing versions that apply. Under the specific role you see only the versions that apply to that role. However, under the specific user you see both the user-specific versions and any role versions based on the role that is assigned to the user. As previously stated, user-level changes override role-level changes, so from the user folder you can make a comparison to see these overriding versions. Every change is considered a version. Versions are created for either the role or the user. If you are applying a version to a role, there is no need to apply the same change to a specific user if that user already belongs to the role. When reviewing the versions in the list tree you will notice some standards in how they are named. To start, the version will show either an S, M, or T. This designates if the change was a screen, menu, or tab change, respectively. Following the type indicator is the version name. Then finally, you will see either a role name or a user ID. We had discussed previously that version names should be short and to the point. You can now see why. In the list tree, longer names with many spaces can be harder to quickly identify should review be needed. 24

29 Here is an example: This version was created to control the menu options in the accounting areas. It was specifically set up for the accounting group. Dave Getty is not part of the account group but since this change needed to apply to him as well I added him specifically when saving the change. If Dave was part of the accounting group then I would have seen both the version that applied to the role and the version that applied to the user under his user folder. That would have indicated to me that there was a change specifically to Dave that will override the group settings. Another example: Here you can see that William Colflesh has existing versions that apply to the role Sales. If you review the Sales role folder you can see the same versions. Bill also has a user specific screen change that overrides the role specific screen change because he is the manager of that group and needs access to secured areas. You can also take a look at the version under the Accounting role. Here a menu change was created that effects Vadim Goldman, as he is a member of that role. A specialized screen change was also created for Vadim based on a personal request. 25

30 Reviewing Versions After you review the list tree you will most likely find a version that you wish to review further. Clicking on a version will allow you to do just that. Notice that on the right side of the screen, version information is displayed in regards to the selected version from the left side. The version information screen displays different data depending on the type of version that was selected. Here is an example of a screen change: Since we selected a screen change from the left side, the bottom right shows a preview of those screen changes. If we selected a tab or menu change, the lower right half of the screen would have shown the corresponding preview of the tabs or menu. Notice also that the screen change preview does not contain any data. We used an existing transaction when creating the change but that data is not stored with the version. The changes however, are still in the code. The upper right portion is where you can get additional details about the version. It is in this area where you will also be able to manage the existing versions. Looking first at the information that is presented, you can see the version, but more importantly, you can see the description. I have already mentioned how it was important to have a good, detailed description. By now it should be evident that the description will hold key information that the preview may not. Like: taker pink font, italic, bold. The Object Name shows where the version was created. In this example Order Entry and specifically Order Header. The rest of the fields are selfexplanatory. Now let look at management tools. 26

31 Managing Your Versions Now that you have reviewed an existing version, you may find it necessary to edit, copy, and/or delete an existing version. Or maybe you just want to see all the users that the version applies to. This is all done via the rightmouse-button (RMB). RMB on an existing version to see the available options: Edit, Copy, and Delete options will always be available for the ADMIN user. If you log in with any other ID, your options will be limited based on your designer rights and if you are associated with the version being reviewed. Selecting Edit opens the version for editing in the appropriate designer window. Selecting Save after the change updates the existing version. If you select Save as, you will be given the option to use a different version name and comment and then apply the change to any user or role not already associated with the version being edited. For example: Say you are logged in as USER_1 and you are editing a version for your role, which is ROLE_1. When using Save as the list of available users/roles only shows your user ID, as there is already a version associated with the role. Even as ADMIN you would see every available user but the list of roles would not include ROLE_1. Selecting Copy only gives you the option to use a different version name and comment and then apply the change to any user or role not already associated with the version being copied (same example as above). Selecting Delete removes the version entirely. When you edit and use Save as or Copy, you only see the Apply to all modules checkbox if you are on a menu version and you are logged in as ADMIN. The Add Users checkbox on any change is also only available to ADMIN. View Role Members is used on role versions to see a list of users to which that version applies. 27

32 Lesson Summary In this lesson, you learned where to find DynaChange Designer Version Manager and locate existing versions by user and by role. You learned how to read the version names and how to review the details of a specific version to see what it was designed to do. You should understand how to manage your versions via the RMB options. 28

33 Workshop 1) Edit your Order Header screen change to make the Contact field background color light blue. Apply this change to the existing version. 2) Copy the tab change from your role to your User ID (or log in). 3) Delete the tab version that was applied to the role. 29

34 Lesson 5: Related Topics and Additional Information After completing this lesson, you will: Know how to use My Menu and how this is affected by security changes. Learn about Grid DataWindows and Coordinate Variables and the need to be aware of the issues and workarounds for changes in these areas. Understand some tips & tricks when using DynaChange Designer 30

35 My Menu The My Menu feature allows users to add particular transaction windows into a separate dropdown menu. This creates a shortcut to the transaction windows that they use most heavily. The feature is user-specific, so different users can have different lists of shortcuts. To use this feature, open any transaction window, RMB on the header, find the My Menu selection on the pop-up and select the option. That adds that transaction window to your list. You can see this by clicking on the My Menu option on the upper menu bar. Follow the same steps a second time to remove the option from your list. You should notice, after you RMB on the transaction window, that the My Menu option either includes a checkmark or not. The checkmark indicates that the window is already added. The feature can be toggled on or off on any transaction window. You may be wondering why we discuss My Menu with DynaChange. The reason simply comes down to security. The system removes the My Menu entries automatically if you block a user from a certain module or menu option. Note though that a savvy user that knows you are making changes and has not yet logged off can go to the available window, deselect My Menu, and re-select it to override the security you were trying to impose. To avoid issues it is recommended that you make security changes with everyone off the system. Grid DataWindows and Coordinate Variables Throughout the system you will encounter what are known as Grid DataWindows. These are basically screens that hold data that is usually stored on a separate table and only retrieved upon request. The most popular example is the PORG (Purchase Order Requirement/Generation) Items tab. Other examples are the Fast Edit screens, Query-by-Example, and Drill Downs. Some more obscure grid windows are the list of salesreps on the Salesrep tab in Order Entry, and the releases on the Release Schedule tab in Order Entry. Usually, the order of columns in which the data is displayed is not an issue, but if you did wish to change the display of a Grid DataWindow, there could be some limiting factors or unique requirements to making such a change. Let s look at the easiest one first, PORG. The Items tab in PORG may display column information in a sequence that may not fit your needs. Where you could just click and drag the columns where you want, and also resize columns as you see fit, these changes will not be 31

36 permanent. The change will only exist for that session. If you wish to make a permanent change you can do so with DynaChange Screen Designer. Here is an example of some changes I made on the items tab in PORG: In the above illustration, if you were familiar with how data normally appears, you can see that I reduced the length of the Item ID column. I also changed a column header from Recommend Qty to Order to Recmnd Q 2 Ord, and having the shorter name allowed be to decrease the length of the column. I used the same techniques on the column Quantity to Purchase. Finally, I moved the column Purchase Item closer to the front of the list of columns. The changes in PORG were very easy to make. All I had to do was run any criteria to display results and then use Screen Designer to make modification. From within Screen Designer I could select any data field and easily edit the text of the column header. I could also click on a column and drag that column to a new location. Finally I was able to click between two columns to change the length of the column on the left of where I clicked. Changes to Customer Fast Edit and Ship-to Fast Edit are just as easy as changes in PORG, only with Ship-to Fast Edit you first need to retrieve some data before starting your DynaChange. Changes to other Grid DataWindows are not always so easy. Where AR Drill Down by Customer works just like PORG, changes to PO Drill Down by Supplier can be challenging. For PO Drill Down by Supplier you can change column headings and resize columns, but moving columns to a new location cannot be accomplished with a click and drag. Here is where the X factor comes into play. 32

37 When I speak of the X factor, what I really am talking about are coordinate variables. In PO Drill Down by Supplier, if you were using screen designer and wanted to move the column RFQ Control Number next to the column Location ID, here is how you would proceed. First, locate the column that is in you way, in this case Location Name. Click on the column and record the X variable value, in this case 352. Next, select the column you wish to move and set the X factor on that column to 1 less than the value you recorded (351). The column will shift in front of the column that was in your way. It s a little tricky, but it can be done. It used to be, on version 10.5 and below, that you could not make the Ext d Cost value invisible on the Cost tab in Order Entry. What you would need to do is set the X variable to 0 to move the column to the far left, set the Y variable to 0 to move the column to the top, then set the W and H values to 0 to make the box disappear. All this is no longer needed for that field in version 11.0 and above but I reference this just in case you come across another column you wish to make invisible and it did not appear possible. Some other screens that appear like Grid DataWindows are the Salesrep tab and Release Schedule tab in Order Entry. These are actually not Grid DataWindows. Changes to these windows require you move the column headings to the desired locations and then go back and move the data cells to match where you moved the column headings. What s the Point? The point is you should be aware when attempting to make screen changes that these Grid DataWindows exist and that the code behind each one may introduce a challenge as to how to make changes to that window. You may even find that some windows cannot be changed at all. Being aware of the coordinate variable (X, Y, W & H) may help you to resolve some of these issues. Tips And Tricks If your intent is to use DynaChange Designer as your security module, make sure you start with a plan. It is very important to have a clear plan of action to avoid having to scrap everything and start over. Be aware of a user s default module when adding security to the module list. If the user is set to default to a module where you elected to block access, that user will have access to that module upon every log in. You should also take careful note of your own role when setting security. If you lock yourself out of the System Setup module, or User Maintenance, 33

38 you will not be able to change the role you are assigned. If you lock yourself out of the System Administration module, you will not be able to get to DynaChange Designer Version Manager to be able to make edits or delete the version. When you are setting up security, it is best to have users logged off. Even better would be to physically reboot the server after the changes are complete so you are sure each user has a fresh log in. When you are creating a test version, start the version name with a lower case t. That way, when you copy the version you can use the real version name with the t excluded. This also helps you identify the test versions in DynaChange Version Manager. If you view an existing version directly from the transaction window, or if you choose to edit a version in DynaChange Version Manager, use Save as to duplicate the version. You can also use Save as to add users or roles. Once a version exists for a role, there is no need to add the specific user from that role to the same version. DynaChange does not work with RMB Options or the popup menus, like Item Browse, etc. The system will allow you to attempt to make changes to popups, but it is not recommended. Each popup is reused in different areas in slightly different ways, so where you may get desired results in one area; you may have completely lost some functionality in another. 34

39 Lesson Summary In this lesson, you learned how to use My Menu and how this is affected by security changes. You learned about Grid DataWindows and Coordinate Variables. We discussed the need to be aware of the issues and workarounds for changes in these areas. Finally, we reviewed a list of tips & tricks when using DynaChange Designer. 35

40 Workshop 1. Add Order Entry and Item Maintenance to your My Menu. Then see if you can get to these transaction windows from Purchase Order Entry. 2. Change PORG Items tab so the Purchase Item column is next to Item ID and reduce Item Description by half the size. 3. Attempt to move some columns around in PO Drill Down by Supplier. 36

41 Session Feedback Form Summit 2007 Las Vegas, NV Please take a moment to evaluate this session and offer feedback. Activant uses your input to understand your needs and to determine future Summit sessions. Session Name: Session Number: Presenter s Name: How important is this topic to your job/company? Not Important Important Please rate the educational value you received from this session Low Value High Value 1. What software are you currently using? 2. How long have you personally used this software? 3. Describe the effectiveness of your instructor. 4. What is your overall evaluation of this session? 5. What could have been done to improve this session? 6. What sessions would you like to see presented at future conferences? 7. What issues will be critical to your business in the next months? Check here if you would like CPE credits. To receive credits, be sure to sign your name at the bottom of this form and sign the roster in the session room. Answering the following questions is OPTIONAL (but required for CPE Credits). Yes No Did this session meet your expectations, based on the description/objectives in the registration materials? Were the pre-requisite requirements stated in the course description appropriate? Did the session materials contribute to achieving the learning objectives? Did the equipment (screen, microphone, projector, etc.) in the room enhance the instruction? Was the time allotted for the session appropriate for the topic? Name: Company: