The goal of the SDK is to let solution providers write accounting modules just like Sage writes Sage 300 ERP accounting modules like Accounts Receivable or Order Entry. In fact our own developers of these products use the same SDK that we make available. When you create your application with the SDK you get all the functionality of a full Sage 300 ERP application with very little extra work. For instance your application will:

• Fully support VBA — you are as customizable as any other Sage 300 ERP application
• Your Business Logic will be available through all the external APIs
• Will use the standard Sage 300 ERP Import/Export
• Your UIs will look, feel and behave like any other Sage 300 ERP screen — you will use the same controls like Finders, grids and navigation controls
• Runs from the Sage 300 ERP desktop, and the Sage 300 ERP Web-desktop
• Will participate in data activation, database dump/load and all other Sage 300 ERP database operations like database transactions

We develop Add-ins in the same manner as full SDK modules. However their goal isn't to be a standalone application. Their goal is to add to or change the functionality of existing Sage 300 ERP modules. They can alter the behaviour of the business logic, as well as add their own business logic, UIs and reports.

The key feature add-ins are using is that the Sage 300 ERP business logic can be “subclassed”. That means you can create a new business logic object that sits in front of the Sage 300 ERP one and process all the calls first. These subclasses are chained, so there could be several add-ins all sub classing the same Sage 300 ERP business logic object. This is a very powerful form of customization, in that it customizes the behaviour for everything that uses the business logic including import/export, macros, external programs as well as UIs. Whereas UI customization only affects the customized UI.