Hello, Dmytro is here. Quick intro – I am a COO of FiduciaSoft and we are a full service provider, meaning we offer consulting, development, QA, deployment, and support for our ERP Customers. Today I’d like to share with you one of the projects for Acumatica ERP, why we’ve developed it and what we’ve learned on the project. It is often the case that out of the box ERP is customized to better match the customer’s needs. Even when the functionality is already there, it is often not perfectly adequate to satisfy specific processes of every business. Sometimes the processes can be changed to fit the ERP and sometimes it is exactly the opposite- ERP must change to accomodate the needs. When the latter is the case, customer seeks the development firm that specializes in the aforementioned ERP to adjust or develop a new functionality within the ERP. This article is specifically about this case. In the example that I want to cover in this post, our client is a growing service company with 50+ employees. They are successfully utilizing Acumatica ERP as internal system of record and in time adjusted and automated majority of business processes. In time, though, as the number of clients and employees grows, it becomes more difficult to manage projects and employee time records within Acumatica. Maybe not even “difficult” per say, but rather cumbersome and more time consuming. Yes, “time consuming” is the correct epitet here. As time goes by, and more and more time goes towards tracking time, rates, billing, and payroll, HR department decides to undertake an optimization project to improve the experience. The final goal- adjusting the ERP to save time of employees on entering time cards, optimize invoicing process, save time on payroll preparation, and give customers a portal for accessing their projected billing statement. All of that while keeping track of overtime, vacations, sick leaves for internal resources.
Of course, all of this has to work cohesively with other parts of the system. Let’s take an example of a new project being onboarded. Manager starts building his team. He or she can see who is on vacation, who is on another project, and who has availability. Team is assemble and project begins. Employees have the new project appear in their timecard, and they can now enter time against the specific tasks of the project. Sick days, vacations, and overtime is tracked. On the weekly basis timesheets are submitted for approval. As manager approves the timesheet for his team, all of the data becomes the basis for the Billing statement as well as for the payroll. At the end of the invoicing cycle customers are billed based on the specific billing rates. At the end of the payroll cycle pay is calculated based on the pay rates. In addition, reporting is done to see overtime, vacations, and sick leave utilizations for a specific individual, team, or within the entire organization. Vacations are scheduled and tracked based on predefined rules setup by HR. At any point in time customers can be provided a detailed breakdown of their invoices. And all of this is done in a secure manner, ensuring that each team member sees only what he or she is allowed to see.
Difficulties are always there but they are solvable
Acumatica already has time card functionality out of the box, thus achieving these goals was much simplified. We needed to add functionality of quickly entering time sheets for single project full time by giving employee’s ability to copy information from the last time card and auto fill day-offs, sick-leaves for this timecard. Because of how easy Acumatica handles data objects, adding the ability to handle overtime, sick days, vacations was relatively straight forward. Where we did run into a few small issues was with adjustment of visibility of certain functions and screens based on security roles within a system. We also experienced a hiccup with base functionality when upgrading to a newer version of Acumatica ERP. Nevertheless well thought out workflows and excellent object structures of Acumatica allowed us to comfortably overcome these difficulties.
Under the hood
Development started in Acumatica’s version 2018R1, even though it was not the newest version of Acumatica at the time. During the project there was a need to migrate to Acumatica 2019R2. Acumatica’s support was able to handle the issues of migration to the target version. And of course, customization was done through Acumatica Framework, C# .NET. In addition Slack integration was present, though this is for another Article. This project was developed by Product Owner, Technical Lead, 2 Acumatica Developers, and 2 QA Engineers. Kanban board was utilized as with majority of our projects. Main part of the functionality was delivered in 3 months. Many smaller features were delivered at a later time as per client’s timeline.
Development, Testing, and Delivery
First thing first, we needed to decide on the specifics of the architecture based on the desires of the client. Then, after the design documentation was finalized, we began development of the required functionality. Development and testing was done on internal server resources where specific version of Acumatica was deployed. The moment developer considers specific piece of functionality complete, the code is updated to a specific branch in TFS and the build is made. The kanban card is moved to a “ Dev Complete” column. Now QA Engineer can start working on the task. Slack notification comes to the entire team directly as the build is done. QA deploys the new build of the customization into the QA’s Acumatica Server, and now testing begins. Main goal is to verify that functionality matches the documentation and works as designed by the architect and product owner. All bugs are documented on the kanban board, and discussed on daily meetings or immediately in a team chat. Once bugs are corrected within a story, this specific functionality is considered done and ready to use.
We utilized this approach of development while preparing the entirety of functionality for Beta testing. In parallel, we kept updating Configuration Guide and User Guide. For beta-testing we deployed AWS Virtual server with the target version of Acumatica and deployed our plugin into that server. Access to the client’s resources was given, so that beta testing could begin. From that moment on, beta testers were able to not only report any issues, but submit any CO requests for improvements. Now, each sprint was first tested by internal QA Engineer, deployed to the beta server, and beta testers were notified that the new build is ready and deployed. This was the mode of operation until the project was designated as production-ready. Client created Azure server with the copy of their Acumatica environment. We deployed our plugin there, and demonstrated new functionality there. After final approval, the plugin was installed on the customer’s main Acumatica server. One of the requirements for this project was development of the specific reports for the client’s customers. Small issue came up with ID’s of those reports. As I mentioned before, development, testing ,and beta-testing was done on the separate servers. As reports were created and recreated, the Report IDs kept changing causing issues and costing time. To solve this, our tester synchronized IDs across all servers solving that specific hitch.
This story is still ongoing
This project is not over yet, with functionality changes and adjustments. We’re also working on polishing it up on the newest release of Acumatica. By the way, if you are utilizing Acumatica in your business or developing on this platform – watch out for our next big upcoming article on Acumatica ERP versioning. In the meantime, check out our post on the case of Developing extension to integrate Acumatica with DHL Delivery Service. See you soon!