Starter template for new SAP Business One add-ons

Problem

After some twenty implementations, starting a new add-on stopped being creative work and became copying properly. And copying from a previous project drags along whatever that client needed, plus decisions that were a workaround at the time.

Solution

The template is the canonical skeleton extracted into a starter project. That is what scaffolding means here: not a code generator, but the minimum structure every add-on is going to need anyway, already assembled and following the right conventions.

It covers the menu, configuration, metadata, event handlers, server tasks and the data access layer. Those are the six pieces that always show up, always in the same place, whatever the client happened to ask for.

The practical effect is that a new client starts with an add-on that already runs and that looks like the others. Client-specific work is added on top of a base nobody has to review.

Architecture

Why it is built this way

I extracted the skeleton from what is already deployed instead of designing it from scratch. Good conventions are the ones that have survived several clients.

It is a complete, runnable project rather than snippets to assemble. What compiles on day one does not get argued about in the first meeting.

The same six pieces always in the same place. Moving between different clients' add-ons should not mean relearning where everything lives.

Metadata creation comes built in. It is the step that gets forgotten and the one that breaks the install, always at the client site.

Result

A starter project in use for new add-ons, with structure and conventions already settled.