Chapter 1: Planning Next Phases
🡸 Module 3: Vendor On-Boarding App

Chapter 1: Planning Next Phases

Business Case and Scope

For this project, the business case is to add Vendors to JDE, which currently is done manually by a JDE user. In order to scope out the project, we will need to understand the process today and identify the pain points and needs. It will be important to understand what value the portal provides to prioritize features of the portal to provide the maximum value. This will determine the scope of the project’s first phase.

Existing Process in JDE

Below is the existing process to add a new vendor in JDE. The steps are done by a JDE user that already has the information, meaning they must already have been in contact with the Vendor to collect the necessary information.

The existing process must be done by a JDE user, so the bottleneck of this process could be the number of JDE licenses or the time of the customer service reps to enter the information gathered by the Vendor.

For each section, the JDE table name is given which corresponds to the location the record is created. As you follow through the steps, you will see the data at various stages. Another drawback of this manual process is that steps can be forgotten and it would look very similar to a properly setup Vendor.

Creating a portal to automate this process allows you to create your own validation. As we go through this, keep in mind any other improvements in the process that the automated approval application, Vendor On-Boarding, adds.

Address Book Record (F0101)

To start, the JDE user navigates to “Work with Addresses” and clicks the “+” at the top of the page to add a new Address.

The next screen will display a form with fields to be populated.

To create the vendor, tabs “Address Book” and “Mailing” are filled out.

Below is an example of the data populated:

  • Alpha Name: Hammers and Stuff
  • Tax Id: 12345678
  • Search Type: V
  • Business Unit: M30
  • Mailing Name: Hammers and Stuff
  • Address Line 1: 123 Main Street
  • City: New York
  • State: NY
  • Zip: 123456
  • Country: US

When done, the user clicks the check button at the top and the vendor is created and given an address book number.

Who’s Who Record (F0111)

Next, the user will create the Who’s Who record for the Address Book record by selecting the newly created Address Book record from “Work with Addresses” and selecting the “Who’s Who” row exit.

This brings the user to the “Who’s Who” screen where information can be added for the new Who’s Who user.

The JDE user will then fill out the required information. Below is an example of the data populated.

  • Alpha Name: Paul Johnson
  • Mailing Name: Paul Johnson
  • Title: Primary Contact
  • Type Code: Contact Name
  • Function Code: Staff
  • Primary Contact: checked

The user then clicks the check at the top to save the new Who’s Who user.

Who’s Who Email Record (F01151)

The first record in the “Who’s Who” will be the business itself and the 2nd is the one just created.

From the row exit for the user, the “Email/Internet” option will open the “Email/Internet Revisions” screen and allow for the entry of an email address.

Below is an example of the data populated:

  • Electronic Address Type: Email Address
  • Electronic Address: hammers@gmail.com

The JDE user will then click the check at the top when they are done and the email record will be created.

Supplier Master Record (F0401)

Back at the “Work with Addresses” screen, from the “A/P” row exit, the user arrives at the “Supplier Master Revision” screen.

 

The payment terms are selected:

  • Payment Terms - A/P: 001 (1/10 Net  30)

Bank Transit Master Record (F0030)

From the Address Book “Bank Account” row exit, the user is brought to the “Work With Bank Accounts By Address” screen.

Click the “+” at the top which will open a “Set Up Bank Accounts by Address” screen.

Once the fields are filled out, click the check at the top of the screen to add the record.

Media Attachments (F00165)

From the “Work with Accounts” screen and the “Attachments” row exit, the “Media Object View” screen is opened.

Click “File”, then “Select Local File” and drop in the bank confirmation file.

Click “Save” to add it. Back at the “Work with Addresses” screen, the attachment is shown as a paper clip icon for the address book record.

Project Planning

Breakdown of Tasks

The planning phase allows us to outline what the project will look like at the end and how it will be used. This will be documented to outline what the project will accomplish. Then it will be used to determine the breakdown of development tasks that need to be completed to deliver the project.

Application Design

Now that we understand the process this portal will replace, we need to decide what this portal’s process will look like. To start, lets review the information that we know about the portal:

  • The main users will be internal users.
  • They will submit a request for a new Vendor.
  • It will then email the new Vendor with an invitation to begin using the portal and fill in all their information.
  • That request might need to be reviewed by someone else before it's allowed to go to the Vendor.
  • The vendor should only be able to see their own information. They should not see the information from other vendors on the portal.
  • There are other internal users that will need to approve the Vendor request based on the information provided by the Vendor.
  • Procurement reviews the answers by the Vendor and sets the payment terms for the new Vendor.
  • Finance might need to make edits to bank information entered by the Vendor. Sometimes, in today’s process, we reach out to Finance for help, so they need the ability to do that here too.
  • The process needs to be able to handle the case where the Vendor has put the wrong or incorrect information. The reviewer should be able to give notes to the Vendor to tell them what needs changing.
  • The information should only be sent to JDE once everyone agrees it is correct and should be created.
  • The Vendor and the Requestor should be emailed when the information reaches JDE
  • It's possible 2 different requests are accidentally made for the same vendor. There should be an ability to cancel the request at every stage.
  • The Vendor and the Requestor should be emailed if the request is canceled.

Basic User Flow

Using the above information we can begin to draw out the user flow of the application.

  1. A requestor composes a new Vendor request
  2. Another internal user reviews the request and approves it
  3. The vendor receives an invitation to use the portal and enter their information
  4. The vendor fills in the form and submits it
  5. The form goes to a Procurement user for approval
  6. Procurement reviews, fills in the payment terms, and submits it
  7. The form goes to a Finance user for approval
  8. Finance edits the bank account information and submits it
  9. The new Vendor is created in JDE

This allows us to more clearly see the types of users that will login:

  • Requestor
  • Request Reviewer
  • Vendor
  • Procurement
  • Finance

These are the roles that will be defined in EASYProcess. This is because a potential user could look like the super user below. For this reason, we would not want to name the authorizations after the specific responsibilities or we would not be able to combine them to create super users.

Possible UserId

Possible User Authorization

User Roles

Admin_Paul

Internal_IT

Requestor

Procurement

Finance

User Flow Diagram

Now that we have defined the steps and all the actors in the flow, we can put together a more official diagram describing the user flow of the application. This diagram has swim lanes for each different role in the flow, notes when emails are sent, what actions are taken by each role.

Notice that at this stage, we take into account:

  • When emails are sent to notify the next role
  • When it is possible to cancel the request (this can only be initiated by the internal users)
  • That not all requests will need a request approver, so it has been marked as optional. Going forward it will not be included in the design.

This highlighted that one of the steps is not necessary and it is an example of how the scope refinement process shapes the deliverable

Workflow

Now that we have a defined user flow, we can start to define the EASYProcess workflow. This is very similar to the user flow, but it is designed from the perspective of the request.

Mapping Workflow to User Flow

To define the workflow, we can look at each step of the user flow and think about what will happen with the new vendor request.

User Flow Step

Workflow Status

Requestor composes new Vendor request

Request Created

Vendor fills out form

Vendor enters information, saved to database

Procurement reviews and fills in Payment Terms

Review by Procurement, more information entered, saved to database

Finance edits the bank account information

Review by Finance, more information entered, saved to database

The new Vendor is created in JDE

Vendor Created in JDE via BSFNs from the information in application database

Defining Workflow Statuses

This allows us to create an outline of what the workflow will look like. The above descriptions of the statuses can be used to give each a name. Just thinking about the request, it will move through these statuses:

Adding Workflow Swimlanes

Next, we will want to add back the user roles as swim lanes. This will tell us which of the defined roles will be able to act on the request.

Adding Error Handling

When we created the User Flow Diagram, there were paths for requesting clarification from the Vendor and canceling the request. These are added error handling which assume they are other paths that may need to be accounted for.

Next, we will add those back to the workflow diagram.

This was created by addressing each Workflow Status and asking “what are the possible outcomes from this step?”. The first two statuses don’t have any options, so they can only move in one direction.

There is still one more error handling case that needs to be added. Whenever there is an integration point, we should assume that it can fail and add extra error handling for it. In the case that creating the Vendor in JDE fails due to connection issues or JDE being offline, there should be another status to handle it. This means the request will move to that status and be considered “failed”. This will allow us to filter in our queries to say “show me all the failed requests” to act on them by emailing someone or showing them on an error queue page.

For our feature, it will go to an error status and the Procurement role will be able to review the information, decide if anything in the form looks incorrect (in case that is causing the error), then resubmit the request.

With this added, the workflow diagram is complete.

The EASYProcess workflow will look very similar to this diagram.

Views (Web Pages and Widgets)

Next, we will think about the different views we will need to create. To start, we will list all the pages that exist as part of the user flow.

  1. Login Page
  2. Forgot Password Page
  3. Set Password Page for the Vendor to set their password for the first time when they are invited to the portal
  4. Home Page for users that changes based on their roles
  5. Inquiry Page for internal users to show existing requests. Could be named: ViewRequests
  6. Page to request a new vendor. Could be named: RequestVendor
  7. From to be filled out by the Vendor, reviewed by Procurement and Finance. Based on the user’s role fields will be editable or read-only. When it is viewed earlier in the workflow, fields that become relevant later on will be hidden (based on Roles).

Some of the pages, 1 - 3, are included in the application template and were created with the application, so those should be good to use as starting points. As we get further into the project, we will be able to see if they require edits and should be included in the changes for this project.

We also should consider the emails everyone will receive. If we wanted, each one could be a widget and be nicely styled. Otherwise, it could be a simple email that just tells the user what to do next and is styled with the html in the SendEmail service. For the training, we will just use the SendEmail service and wont add any views that need to be built for the emails.

So, the pages we will need to create are:

  • HomePage
  • ViewRequests
  • RequestVendor
  • VendorForm

Database Changes

We briefly mentioned in the workflow steps that we will need to save information to the database. This will have to be saved to the application database because we will not want to send it to JDE until it has been approved and all the data has been entered. So, we know we will need a database table to store the vendor form information before it is sent to JDE.

For database table naming conventions, it is a good idea to use a prefix so that all your tables are shown together in a list. For this application, we may only add one table, but if more are added, we want them to be grouped together, so we will add a prefix of “VOB” for Vendor On-Boarding.

Table Name: VOB_Vendors

In considering the columns that the table will need, we should write down everything we know about what will need to be saved.

  • VendorUniqueId: This will be a next number value and will be used as the primary key. This is needed because the vendor names might not be unique
  • Name: Name of the vendor. This will be the readable name to identify the record
  • JDEAddressNumber: The AN8 of the record created/edited in JDE
  • Status: A status of the record. Maybe it would have New, Pending, InJDE/Complete. We will decide the statuses later, but we see the statuses will be pretty short.
  • [a column for every bit of data saved to be sent to JDE] - this works as long as we don't have arrays which would need a separate table.
  • Address Line 1
  • Address Line 2
  • Address Line 3
  • Address Line 4
  • City
  • State
  • Zip
  • Country
  • Company Email
  • Contact Name
  • Contact Email
  • Phone Number
  • Phone Prefix
  • Bank Account Number
  • Bank Account Type
  • Bank Country
  • Bank Routing Number
  • Beneficiary Bank
  • Currency
  • Tax Id
  • Payment Terms

Methods

Next, we will think about which methods we will need to create. These will be all the actions in the user flow that work with the database. The logic will be placed in methods in case the View changes in the future, the methods can be dragged and dropped from any canvas to accomplish the same goal without having to copy and paste specific services.

Building logic modularly in methods increases the reusability of your logic and helps to reduce development time in the future.

Again, let’s review the user flow and note the methods we should create to perform the required actions.

User Flow Step

Methods

Requestor composes new Vendor request

  • Create Vendor Request in Application Database
  • Notify Vendor
  • Create Vendor User

Vendor fills out form

  • Update Vendor Request with Vendor Info
  • Notify Procurement

Procurement reviews and fills in Payment Terms

  • Update Vendor Request with Procurement Info
  • Notify Finance

Finance edits the bank account information

  • Update Vendor Request with Finance Info

The new Vendor is created in JDE

  • Create Vendor In JDE
  • Upload Attachments To JDE
  • Notify Vendor and Requestor

Notice there are several “Notify [next status]” methods. Those will probably be very similar logic and we could make it dynamic so it checks what status the workflow is at currently, checks what the next status is, then queries to find the users for that next status to notify them. We can replace all those methods with a consolidated one. Actually, there is a built-in method for all new applications that handles this logic: WorkflowNotification. We will note that it may need some changes, but we will use it for the project.

There is another notify method at the end of the user flow that always notifies specific roles: Vendor and Requester. As we noted earlier, we would want to notify these same roles when the request is canceled too. We also want to give the ability for either requestor to cancel the request. This makes three instances where a method could be used that notifies the Vendor and Requestor. We could name this method NotifyVendorAndRequestor.

There are also several steps to update the Vendor Request with information that the user has saved to the form. These could be consolidated to its own method: UpdateVendorRequest. It could even be merged with the existing CreateVendorRequest to make just one method that accepts a flag of either Add/Edit. If we merge them, it would probably have a name like “VendorRequest” or “AddUpdateVendorRequest”.

At the last step, when we submit to JDE, we should also consider the error handling we added for the possibility that JDE is offline. We can also add a step before attempting where we ping JDE to see if it is online and don’t attempt the creation unless it responds. This could be its own method: Is JDE Online.

Thinking about error handling, there should probably be some path in case anything goes wrong. It should always call the same method that accepts inputs such as what went wrong and where it occurred. This will make it easy when developing the error handling to divert to a path that calls the method and ends. This way each time there is an error, the same group of admins are notified. This method would be something like SendErrorEmail.

If we edit the previous table with the new methods we have discussed, we get the below:

User Flow Step

Distinct Methods

Requestor composes new Vendor request

  • VendorRequest
  • WorkflowNotification
  • CreateVendorUser

Vendor fills out form

Procurement reviews and fills in Payment Terms

Finance edits the bank account information

The new Vendor is created in JDE

  • IsJDEOnline
  • CreateVendorInJDE
  • UploadAttachmentsToJDE
  • SendErrorEmail
  • NotifyVendorAndRequestor

This gives us the full list of methods we will create for this design.

Identify Relationship of Tasks

Now that all the tasks have been identified, we can view them all together to get a full picture of the project:

App

  • VOB

Roles

  • Requestor
  • Vendor
  • Procurement
  • Finance

Workflow

  • New Vendor

Views

  • New:
  • HomePage
  • ViewRequests
  • RequestVendor
  • VendorForm
  • Edit:
  • SetPassword
  • Login
  • ForgotPassword

Database Changes

  • New Table: VOB_Vendors

Methods

  • New:
  • VendorRequest
  • CreateVendorUser
  • IsJDEOnline
  • CreateVendorInJDE
  • UploadAttachmentsToJDE
  • SendErrorEmail
  • Edit:
  • WorkflowNotification

Order to Complete Work

The order we complete the work is not very important in simple applications, but it can help identify if some of the design should be attempted in multiple phases. We already removed the optional role of the Request Reviewer, but if we had kept it in the design, we could separate it out into a phase 2 at this point in the project plan.

If we review the dependencies of the sources, we know that:

  • The app needs to be created first since all of this will be in the new app
  • The workflow and pages will have the logic to update the records and send the emails, so the methods should be created before those.
  • The ViewRequests page will query the new database table, so that should be created first
  • The Home Page will change based on Roles, so the roles should be defined first
  • Roles require the setup of object lists which we need to define.
  • Once we define the relationship between Roles and Object Lists, when we are setting it up, the Views will need to exist for us to create that relationship. We can create the roles early, but setting up the relationship will have to be done after the Roles and Pages are already created.
  • The Vendor Request Page will start the workflow request, but since it is at the start, it can be developed before the workflow as long as we know what we will name the workflow.

We should complete the work in the below order:

  1. VOB App
  2. Database Table
  3. Inquiry Page to display the new db table records
  4. Vendor Request Page which will create the workflow request
  5. Methods to be used by the workflow and other pages
  6. Workflow
  7. Roles
  8. Home Page which depends on Roles
  9. Vendor Form Page which depends on Roles
  10. Edits to Existing pages to work with the full user flow

Authorizations/Roles/Object Lists

The relationship between these three will be used for the security of the app to grant or restrict access to pages. Roles map to Object Lists which contain the specific pages the Role can access. However, this will only be used if the Views are set with the property “EnableRoleSecurity” to “True”.

Without Role Security enabled, the pages will display as soon as they are added to the user’s menu. If we wanted to avoid using the role security, we could achieve the same goal of restricting the Vendor from seeing the inquiry page by creating 2 menus: internal and external and giving the external menu to the Vendor. However, if the Vendor got ahold of the url for the request inquiry page, it would load and not be restricted.

For the training, we will be using Role Security.

Authorizations to Roles Mapping

For an actual implementation, where different departments or user groups might need certain roles, the authorizations can be set up to match the grouping.

This might look like the below.

Possible Authorizations

Role

Vendor

Vendor

Manager

Procurement

Finance

IT

Requestor

Vendor

Procurement

Finance

Admin_FullAccess

Requestor

Vendor

Procurement

Finance

For our simple application, we will set up the authorizations to exactly match the Roles.

Authorizations

Role

Requestor

Requestor

Vendor

Vendor

Procurement

Procurement

Finance

Finance

We can change this later if needed by easily creating a new authorization and assigning the new Role mapping. This is why assigning Roles correctly in the setup of the app is important to increase the reusability of your code.

Roles to Object List Mapping

The roles need to be assigned to see certain pages or do things. This is done by assigning Roles to Object Lists. Object Lists should be the things that different roles can do.

Object Lists:

  • RequestInquiry
  • This means it will give access to everything needed to use the ViewRequests inquiry page. If that page has links to open other widgets, then the page and all its widgets would be the Objects for the RequestInquiry object list.
  • This also includes the ability to start a new vendor request. Anyone who has access to the inquiry page can do this. If this weren’t the case, we would break this out to its own Object List and define which roles have that ability.
  • Type: WebPage
  • Objects:
  • ViewRequests
  • VendorRequest
  • Any Widgets Needed to Support the ViewRequests Page
  • VendorForm
  • This Object List refers only to the visibility of the page itself and widgets needed to view the page. The Vendor Form will be viewed by the Vendor, reviewed by Procurement, then again by Finance. All these Roles will need access to the page VendorForm, but the individual fields on the form will need another rule to decide when to show/hide.
  • Type: WebPage
  • Objects:
  • VendorForm
  • Any Widgets Needed to Support the VendorForm Page
  • VendorFormBankEditAccess
  • This is the rule that will allow access to the bank information. This will be used by Procurement, but if it were needed to assign another Role the ability to edit bank information, that Role would be given this object list.
  • This is named EditAccess because anyone who can view the vendor form can view the bank information, but only those with this role (Procurement) will be able to edit it.
  • Since this is more of a rule, it won’t be used to record Pages underneath it. Instead, we will build out some logic that checks the current user’s Role/ObjectLists and performs some hide/unhide action based on the result.
  • Type: User Defined
  • VendorFormPaymentTermsAccess
  • This is the rule that will allow view/edit access to the Payment Terms. This will be used by Finance.
  • It is named only with “Access” because those who can view the form still will be unable to see this section unless they specifically have access to it. If they have access to it, they can also edit it.
  • This is similar to the above access object list. It will also have no objects.
  • Type: User Defined
  • VendorFormAddCommentAccess
  • This is a rule that will allow Procurement and Finance (approvers) to add comments to the request.
  • It is named “AddCommentAccess” because the comments will be visible in other situations when the vendor must see them to provide
  • This is similar to the above access object list. It will also have no objects.
  • Type: User Defined

Notice that the HomePage is the only view not in any Object List. It will have the View Property “EnforceRoleSecurity” set to “False”. That means it will be available for anyone to view as long as they are logged in. Most pages need some restriction logic and not restricting them poses some risk, but the Home page will have its own type of security. The page itself will have logic in the model to show and hide sections and links based on the user’s role.

The rest of the roles will be associated with the below object lists.

Role

Object Lists

Vendor

  • VendorForm
  • VendorFormBankAccess

Requestor

  • RequestInquiry
  • VendorForm

Procurement

  • RequestInquiry
  • VendorForm
  • VendorFormPaymentTermsAccess
  • VendorFormAddCommentAccess

Finance

  • RequestInquiry
  • VendorForm
  • VendorFormBankEditAccess
  • VendorFormAddCommentAccess

Project Estimation

Even if you are not familiar enough to provide an accurate project estimate, before development is started, it is a good idea to estimate out all the tasks to be done. At the end of the project, you can then compare with the amount of time spent to get better at estimating future projects.

The project estimation will help with project planning to know the timeline and when it could potentially be released for use.

Task

Estimate (in hours)

Notes

Create VOB App

.5

Creating the app is pretty fast. It takes a few minutes for it to be created, so that accounts for most of the time.

Create New Vendor Workflow

12

This workflow contains 6 workflow statuses. Let’s assume it takes 2 hours to drag the status onto the workflow canvas, and set up the logic within it. That would take 12 hours to build the workflow.

This is a good estimate based on the information we know. During the development, we might find that some statuses are a very quick setup while others are more involved, but for this simple estimate, we assume it will even out.

Create new Views:

  • HomePage
  • ViewRequests
  • RequestVendor
  • VendorForm

24

The ViewRequests page is an inquiry page. This is a grid with filters and a search button.

The RequestVendor page will be a very simple form which ends by creating the workflow request.

Both of these pages don’t have logic based on Roles, so it should be faster to develop. VendorForm and HomePage both have Role based logic and may take longer.

Let’s assume the easier pages will take 4 hours and the harder pages will take 8 hours.

Edit Existing Views:

  • SetPassword
  • Login
  • ForgotPassword

2

We are noting that these may require some changes, but they should mostly be usable in their current state. We will set aside two hours in case some changes are needed.

Create new Database Table VOB_Vendors

2

This is a pretty quick task, but it may require some changes if we first add only some columns, then need to add more once we start developing.

Create new Methods:

  • VendorRequest
  • CreateVendorUser
  • IsJDEOnline
  • CreateVendorInJDE
  • UploadAttachmentsToJDE
  • SendErrorEmail

24

There are 6 methods. Methods are pretty self-contained, so the development will be easier because it can be tested without first needing to build out another source that could have its own bugs. Let’s assume each one will take 4 hours.

Edit existing Method WorkflowNotification

2

We are assuming this one will take half the time of a new method because it is already built and should just need edits.

Create Authorizations, Roles, and Object Lists

Authorizations

  • Requestor
  • Vendor
  • Procurement
  • Finance

Roles

  • Requestor
  • Vendor
  • Procurement
  • Finance

Object Lists

  • RequestInquiry
  • ViewRequests
  • Any Widgets Needed to Support the ViewRequests Page
  • VendorForm
  • VendorForm
  • Any Widgets Needed to Support the VendorForm Page
  • VendorFormBankAccess
  • VendorFormPaymentTermsAccess

2

These are easy to set up and we did most of the work of outlining what needs to be done. This should just be the time it takes to click the buttons and type the chosen names.

Internal Unit and Integration Testing

8

This will be the testing by the developer before UAT. This includes unit testing of each individual source (as much as possible, until all sources are built) as well as the testing of all sources used together.

User Acceptance Testing (UAT)

8

This testing is performed by the developer. This estimate is only for the time of the developer to fix bugs found in UAT and make any changes that were decided during this step. It will be easier to only account for the developer time, but when doing this step, consider who will do th UAT testing and how much time they should set aside for the task.

To complete UAT, use cases can be created to outline all the ways users interact with the portal. This would be used by the UAT testers to make sure they complete all necessary tests.

Meetings and Release

4

After the project is developed, we need to consider how it will move to PD. Sometimes there are more steps involved that also need to be planned.

For example, there might be an automated email sent inviting users to the portal. If the portal was not built to send it, that will need to be coordinated.

There may also be training time needed for the first end users.

Total:

88.5

This estimate helped us to find that this is at least a two week project. If we wanted to coordinate with others for testing, we could begin scheduling.