Custom Sales Project management in Acumatica

Hi, I’m Sviat Magerovsky, product manager on the project described below. Writing articles is not something I usually do but I’ll do my best to share project details and our experience on developing Acumatica custom solutions. We were requested to develop a custom Acumatica ERP solution for a client in the summer of 2018. It’s been awhile since we’ve started so let me describe you this project in more details. The main goal of our client was to automate their sales process and project management in a pretty large company. Users on client’s side were using multiple software solutions to manage their Sales Projects and those software solutions were different from location to location. Their existing processes included a lot of manual steps that would result in a lot of mistakes. A huge amount of document tracking was done within excel and other documents that provided extended flexibility but ruined any chance to keep track of everything. Our client wanted to have a unified ERP solution to cover all aspects of their Sales Project process so their entire business process from begging to end would be tracked inside of one system. One of the main goals was also splitting functionality in the system so that each department can access and manipulate only processes and documents that are under their responsibility. 

Implementation & customization of ERP

Our client was already looking in Acumatica’s direction, and Acumatica appeared to be pretty attractive system that potentially was covering a lot of client’s requests out of the box. But taking into account complexity of the business processes that our client follows, there was need for flexible custom Acumatica solution to cover all aspects of their business. The hardest thing at the beginning was to ensure our client that we can follow Acumatica certified development processes and will be able to upgrade, support and extend the product according to their needs. Another challenge that came up after some user acceptance testing on client side was that most users were used to their current processes and solution that they were “not excited” to move to a new platform. We had some hard times developing some odd features to get users really excited and get real feedback from them. Some of those features were changed a lot with time to get more reliable and straightforward functionality. Some of user’s request sounded like “I want to have excel inside of ERP” – we had to be creative and balance between making the system flexible while maintaining all core system rules and restrictions. To give a peace of mind to our client we initiated an approach with a lot of communication, demos, and feature tracking where our client also took part and was always able to influence priorities and development direction.

Development team and resources

From a technologies perspective on this project we were using Acumatica Framework (.NET C#) for features development. Acumatica provides a very good knowledge base and even allows to pass Acumatica Product certification. Our client decided not to apply for Acumatica certification process as there was need for extended flexibility in development of features (there are some really strict rules to get certified) and saving time. Nevertheless, everything we’ve developed fully follows Acumatica rules and will remain to be easily supported on any new version of Acumatica. For our internal process purposes we’ve set Azure Dev Ops tools for project management and CI (Automated Build). What is more, we’ve used Behavior Driven Development approach on project, so we included Spec Flow into our solution. We’ve decided to follow agile development methodology with iterations approach that allows us to deliver new features to client every two weeks.  All the processes and technologies are working good but here are what requirements we are trying to cover with it. Our client requested development of Project Sales module with huge amount of features. According to our development flow we found that some feature requests are changing as the client sees them a bit different as soon as features are ready for acceptance testing. We’ve done our best in estimating time for whole project, but after few feature change requests from the client both sides agreed that continuous delivery will be much more beneficial. The client managed to designate requested functionality so we could focus on developing features for one department first and then extending it for other client’s departments. With this approach the first release allowed our client to go live with one module and part of their team. According to this our team always contained a Product/Project Manager, Team Lead/Architect, QA Analyst and 2 Developers. These numbers were always adjustable but for this project the go live process on multiple branches did not allow time to gather sufficient amount of requirements from sprint to sprint to get enough tasks for extending team with more developers.

Behavior Drive Development

Talking of development team, we at FiduciaSoft are completely ready to provide any client with extensive expertise in ERP field, provide enough qualified resources and take on full project management responsibility on our side. With our experience in ERP we were able to process customers’ requirements and transform them with easy to use, straightforward functionality. As I mentioned previously, we have Behavior Drive Development (BDD) process in place. That really gave us the ability to have unified documentation that can be used by: 

  • Developers to develop right things 
  • QAs to test that everything is developed right 
  • Management team to manage and control requirements and changes on any stage of process
  • Client – who always able to see development documentation before development process started. Client is always able to review and make sure that our team is moving in right direction. 

The BDD process in many occasions saved client’s time as all miscommunications or corner cases were almost always discovered after features are documented and before development is started. The client would correct those features and we were always developing right things. Having BDD in place we’ve managed to use the same documentation to automate testing of some complicated calculations and algorithms to ensure that we do things right and it doesn’t change with time.  Our documentation and BDD process is making development process transparent like never before. We didn’t have to fit our software with another software yet but having our process in place we are not afraid of it. Our client is now discussing possibility of integration with multiple APIs of their Customer’s and Vendor’s systems. That would speed up business processes even more and minimize human mistakes and as a result, save time and money. In addition to development, Quality Assurance is an important part of making a reliable solution. Having our documentation in place, the QA process is really easy and straightforward. Our approach is built to focus on testing Business features first and then concentrate on development details and corner cases. To avoid most risks, we managed to deliver a new version to Client’s test system each sprint (once every 2 weeks), deliver release candidates to client’s train system (client was able to start user training some time before functionality is fully tested and deployed to production) and deliver to live system in planned and agreed upon timeframes and feature amounts. Continuous communication and continuous delivery process helped us to be more flexible – we are squeezing in last minute features sometimes into existing timeframes or took more time than planned to optimize and stabilize system when it needed. Everyone on our team is always aware and ready for this. Having such process in place we’ve reached pretty high client happiness of our development time framing and product quality. 

The client became a friend

After more than a year of development we’ve incorporated some positive changes into our process – a strong and trustful relationship was reached where all client’s needs and expectations are always clear, and customer can trust our expertise, timeframes and product quality. Currently the project is still ongoing, and all participants are really happy to be a part of it. We’ve got real friends with our customers and continue making their system better and better yet in a calm, friendly atmosphere. 


If you read to this point – You are greate 😉 At this moment we preparing the next part of this case. Follow us on the Linkedin, Facebook or Twitter so as not to miss the next part. Also, you can read other articles about ERP in our blog. For any questions about this case or ERP, feel free to contact us.