When creating a modification to the base system in Microsoft Dynamics 365 for Finance and Operations, it is critical to test those modifications. I have always encouraged users to try to break any modifications they’ve introduced before it ever goes into production. Users laugh when I say this, but I am 100% serious. So, how does a user “break” the system? Let’s go through some ways that users can think about testing these modifications and how they can work toward “breaking” the system.
Consider All Related Processes
Sometimes modifications aren’t straightforward and will impact other processes. If there is a related process that may be affected, it is important to consider this as well when testing. A good example of this may be a modification to the Direct Delivery process. A Direct Delivery is when a Sales order in Dynamics 365 F&O is connected to a Purchase order and is often called a “Drop Ship” order. You can read more about this in my previous post, “Drop Ship, aka Direct Delivery Orders, in Dynamics 365 Finance & Operations.”
So, what other processes may need to be considered when modifying the Direct Delivery process? Here is a short list of potentially affected processes that need to be considered for review when modifying this process:
- Intercompany orders (if being used or potential for future implementation)
- Standard Sales order
- Sales order picking
- Sales order packing
- Sales order invoice
- Pricing (Trade agreements, standard pricing, etc.)
- Standard Purchase order
- Purchase order registration
- Purchase order receipt
- Purchase order invoice
- Quality orders tied to affected orders
- Approved products/vendors
- Discounts
- Royalties
- Rebates
- Commissions
This list is not all-inclusive, but there is potential for any modification to affect these processes if they are being used and the modification is not properly developed. Consider all processes when testing!
Review All Methods Included in the Process
If you have spent any amount of time in D365FO, then you will know that there are numerous ways to complete a process in the system. There are multiple paths and often multiple ways to get to areas in the system. Users will always find the method that makes the most sense to them, and you will see that even if users are doing the exact same thing in the system, they may be doing it entirely differently. That’s the beauty of this system! There are so many ways to get things done. That said, it is important to review all of these processes when thinking through testing. If creating a Sales order, can I get the expected result when I create it from:
- All Sales orders screen
- Sales quotation
- Sales agreement
- All return orders screen
- Customer master
- Project
- Workspaces
Just like above, all of these may not be in play within your organization, and there may be others I have missed. Be sure to think through all of your processes and ensure that they function properly when including a modification.
Test Large Quantities
This may seem like a no-brainer, but too often I see people test one example with one transaction. This is not the most common real-world scenario! Be sure to test transaction amounts that mirror what will actually be happening in your system. This will help you determine if the modification can handle your level of transactions, as well as ensuring that a multitude of scenarios are covered.
For example, if you are testing a Sales order, put multiple lines on the order. Make sure some of the lines do not have inventory. Perhaps a partial shipment with a backorder needs to be tested. Regardless of scenario, make it as “real world” as possible!
Think Like a Bad Guy/Gal
This one is my favorites. We have all seen how treacherous villains can be in books and movies, but sometimes there are people who may have nefarious intentions within your organization. There are tools to help prevent this such as Security, Segregation of duties, and Approval workflows, but sometimes there are people who actively look for ways to find workarounds to processes and backdoor methods to circumvent your company’s procedures.
This method of testing requires a bit of bad guy/gal thinking. When I start down this path, my first thought is always, “What am I losing by adding this modification?” People are motivated to keep things status quo, and if you are adding any complexity to their lives or taking something away from them, they may look for ways to override this functionality.
For example, if a modification is date-driven, you may want to review a user’s ability to modify the system date when entering transactions so they are unable to backdate transactions.
My next thought is to consider how to use the system for financial gain. Hopefully, when implementing an accounting system, there is some strategic thought behind approval processes and who has access to sensitive information. However, it is always beneficial to try to access sensitive information and push financial transactions through that should never be approved.
Finally, look for loopholes and ways to circumvent the processes your company wishes to uphold. If a user with limited security can find a workaround, they will. It is up to you to find those and shut them down before anyone else can find them.
Conclusion
It is important to test your modifications, and testing often requires some extra “out of the box” thinking. Ensure proper testing of all modifications and you can avoid painful issues later on.
The post Testing Your Modifications in Dynamics 365 Finance and Operations appeared first on Dynamics Communities.