Automate Business Processes to Gain Efficiency & Profitability 

Identifying opportunities for digital transformation through business automation can significantly streamline operations and reduce pain points. MARTEC360 has decades of successful business automation solution experience with hundreds in the Everest ERP ecosystem. The examples below are intended to show some of the possibilities on eliminating manual processes in your business.

Examples: 

  • Order Import Systems (OIS)
    • The OIS by MARTEC360 can connect to nearly any order management system data source and streamline the customer/order import processes. Examples of various order management systems may be EDI, E-Commerce sites, Marketplaces (via a secondary middleware), CRM platforms or other external order management systems.
  • Customer Statements
    • Auto-generate PDF’s on X day of each month and generate CRM email notifications to accounts receivables customers. The net result is the savings of thousands of hours and expense annually in processing the statements and mailing them out. 
  • Automated Sales Order Invoicing
    • Identify work-flows where sales orders can auto convert from sales order to sales invoices. An example would be this would be Amazon FBA orders which auto-import and need payment applied and to simply be invoiced to clear them out of open orders. Another example would be any time a sales order has shipment tracking numbers on them and is a single shipment order.
  • Automated Purchase Order Generation
    • Based on YoY sales or inventory trends, auto generate stocking purchase orders to back fill inventory. Another scenario which the MARTEC360 team has repeatedly automated in the past relates to drop-ship or JIT PO’s based on sales orders and inventory levels.
  • Automated Sales Order Creation
    • Recurring subscription businesses (wine clubs, magazine subscriptions, or any consumable subscriptions) where a template may be configured for the ‘order template’ may be auto generated each day/week/month/quarter/year based on the template settings.

It is important to note that API/SDK automation solutions may be adversely impacted by improperly configured server / networking environments. We advise accounts go through an audit on their business environment to ensure everything is properly optimized and the appropriate resources are in place. Please see our business support services for more details.

API/SDK FAQ’s

Typically there is a scope of business support hours by either block-time (available in increments of 10, 20 or 40 hours) or a compiled project in order to fully identify and document the business requirements (BRD) of the solution. In many cases where we already have SDK/API applications already pre-built for the desired automation goals, the discovery scope is less time or level-of-effort (LOE).

At the conclusion of the discovery session a BRD will be generated along with a proposal.

Most SDK/API business automation applications which are then integrated all fall into Software-As-a-Services (SaaS) add-on’s and are billed either monthly or annually along with any associated setup fees. Unless the support requests are edge cases, most maintenance and support is built into the SaaS pricing.

The pricing can vary greatly. Is it for a single company or is it multi-company? Does the application need to support multi-company individually or does it need to be multi-tenant? Is it something which is a proven / heavily used application such as the OIS? 

Yes. Through our 20+ years of building solutions, supporting customizations and providing professional services to the Everest community we have found a number of non documented best practices. See below for a brief list of these. If you are interested in exploring performance or stability issues in your own instances, please reach out and schedule a consult and/or business support services. Many of these start by having a properly configured and optimized Everest eco-system – specifically, the right number of application servers and hardware/software requirements.

For simplicity, we will refer to any combination of SDK/API’s, 3rd party connectors or customizations as “application”.

Best practices:

  1. Make sure you have an application server besides the database server for any application. That way if the Everest COM+ application layer goes down in any instance, you’re not left having to perform ugly reboots in the middle of the day.
  2. Ensure all of your Everest users have a separate Everest COM+ application server rather than using the database server as such during the standard login process. This is so that should the COM+ layer have any problems due to user activity, it doesn’t crash the database server COM+ layer and thereby knock out your application automation solution.
  3. Ensure there is a windows user/pass which is set for non-expiry so that the application doesn’t crash/stop working when the password expires.
  4. Ensure that there is a non “SA” SQL user account which the application is setup to use so that in SQL, if one needs to track application/memory leaks, they are more easily identifiable. Our recommendation is to typically have a different SQL user for each type of application.
  5. Ensure the application is properly opening and closing Everest SDK user sessions/tokens. We have seen MANY cases where orphaned sessions are left open. When left open they will consume the seats and eventually cause new SDK/API sessions to fail due to “too many users”. These are not as easy or straight forward to resolve as they must be reset from the database backend rather than any windows GUI.

The simple answer is it depends. How fast do you want the activities to process. There should should be ~8gb of memory or thereabouts (more if running multiple applications throughout the day). The SDK/API application is largely CPU dependent though. Throwing more CPU’s at it in our experience does not move the needle a great deal. The faster the CPU, the faster the applications can get into the code, execute the process, close the connection and then loop through the sequencing.

An example from an account which has used our OIS application for years: They were on a dual core, 1.8Ghz processor server for a long time. They upgraded into our AWS Private Cloud for Everest and r5n.large instance which has a sustained dual core, 3.1Ghz processor. The processing speed for OIS on a typical batch of 500 orders importing was cut in half. Instead of taking 2.25 hours for processing, the imports took just over an hour.