Customização do ERP
Quatro canais oficiais. Extensão TypeScript, IPs no meio do fluxo, eventos depois do commit, tabelas declarativas.
Customizar o M3R não é copiar tela nem abrir SQL. O Core persiste; o ERP pinta; a extensão declara.
Os quatro canais
| Canal | Quando | Pode abortar a operação? |
|---|---|---|
| API HTTP | outro sistema cria/consulta com as regras do ERP | a API recusa o request |
| Eventos | depois do commit | não |
| Pontos de interação | no meio da tela ou do save | sim, se o IP canDeny e estiver wired |
| ctx.ext | tabela, tela, menu, relatório da extensão | não substitui o documento fiscal |
Não misturar com Flow Engine (automação interna do tenant) nem com feature flags (mudam o Core para todos os documentos do tipo).
Onde a extensão vive
| Peça | Onde |
|---|---|
| Manifest + handlers | pacote @m3r/sdk, m3r.json, defineExtension |
| Catálogo tipado | SDK_CATALOG 0.5.0 — catálogo SDK |
| Catálogo do Core | ENTRY_POINT_CATALOG em farmus-api |
| Registro tenant | FADEV04 (inscrição), FADEV05 (auditoria de invocação) |
| UI declarativa | FADEV06–FADEV10, host /apps/extensions/[code] |
| Tabela física | FAX0001–FAX9999 criadas pelo Core |
| Pacote assinado | FADEV11 / FADEV12 — m3r deploy |
| Liga/desliga | FADEV13 — Configurações → Extensões |
Gestão: Gestão no ERP. Ciclo: ciclo de vida.
Wired ≠ catalogado
O m3r validate aceita todo código do catálogo. O host só chama wired: true. Compras, estoque e financeiro têm IP no catálogo e não estão no dispatcher ainda. Confira sempre:
e ctx.capabilities.entryPoints.
O que a extensão não pode
SQL, React no ERP, TypeORM, iframe, coluna JSON livre, inventar código de IP, patchear preço/item/campo fora da allowlist de vendas (observation, customerName, deliveryDate).