XtendM3
XtendM3 extensions, from a description.
XtendM3 is where M3 lets you change the business engine itself, and it is the part most teams cannot staff. It means Groovy, the extension framework and a clear head about M3 internals. Loupe Code builds the transaction, the table or the trigger you describe, with your real data in view the whole time.
Transactions, tables and triggers
The three things XtendM3 is for, each built the same way: you say what it should do, Loupe Code checks your environment for what it needs, and you approve the plan before anything is written.
- Custom transactions. API transactions that read and write exactly the fields you choose, shaped around how your data actually looks. The kind of thing an integration has been waiting on for a quarter.
- Custom tables. Design extension tables with keys and fields laid out interactively, with live data beside you instead of a specification written from memory.
- Triggers. Attach logic to standard M3 events. Validate, default or extend behaviour right where it happens, so it holds no matter which screen or integration got there.
- Grouped the way you think about them. Transactions belong to a program, the way they do in M3, so a set of related extensions stays a set instead of a pile of files.
Extension work is data work
Nobody writes a useful extension without first understanding what is in the table. Which fields are actually populated, what the custom fields your business added are really called, whether the key you assumed is unique. That research is most of the job, and it is the part a general purpose AI cannot do for you, because it has never seen your data.
Loupe Code starts there. It queries your environment, shows you what it found, and designs the extension against that. When two candidate transactions could both do what you asked, it stops and asks which one you meant rather than choosing quietly and letting you discover it in test.
What you end up with is Groovy source you can read, review and hand to a developer, in your own git repository if you want it there. Nobody has to take the extension on trust, and nobody has to keep paying us to change it later.
Need a screen for it?
H5 app builder
A new transaction usually wants a screen. Build one from the same place.
Only on one screen?
H5 scripts
If the rule only has to hold where users type it, a script is cheaper.
What do you keep?
What you keep
A standard XtendM3 extension, in your environment, with the source in your git.
Bring the extension on your backlog.
The transaction the integration team has been waiting on, or the trigger that should have existed years ago. We will design it against your data.