In Dynamics Business Central, Bidniss[1] is the first domain. Programming is the second. Bidniss confers Dynamics BC with all its raison d’être. A.L.L.
First came the accountant. Then came the accounting software. Then came the bidniss software. Finally came the Enterprise Resource Planning[2] software: the solution to all known and unknown bidniss problems. Except… not.
The ERP
When the ERP, BC in this case, comes to a boundary and a new bidniss case lies beyond that boundary, bidniss owners call programmers. That’s you. That’s me.
We’re not called to rewrite BC. We’re called to extend it.
This is an overloaded term. When programmers think extension, they envision classes and event handlers and delegates and all manner of OO tricks to add functionality to an object. Programmers enjoy this liberty because the extensible object is, to us, a black box[3].
Our Black Box
To us, though, bidniss processes happening behind the closed, or open doors of the ERP must be known and understood. To us, the functions of a posting process, or an order creation process must be understood. Even if the details and order of the logic are hidden, we must understand them first before we arrogantly move the previously-placed boundaries of that logic!
BC used to license their modules separately. Now they all come as the package. There are:
- General Ledger and Finance
- Banking
- Inventory
- Sales & Receivables
- Purchase & Payables
- Warehousing
- Light Manufacturing
- Resources
- Fixed Assets
- Jobs
- Payroll
- and more!
These formerly-modules represent hundreds of thousands of lines of business process code — supported by possibly a million lines of C code underlying the types and constraints and data access made effortlessly possible within the architecture.
Our Burden
You don’t want to screw that up, do you?
And that’s why we programmers must know the bidniss domain. We must know the bidniss standard first. We must know the bisniss extension next. We must then be able to apply our knowledge of coding to the bisniss problems. We must respect bidniss first. Coding second.
So you’ll have to think through the bidniss problems your customers hand you with deep respect and regard for the integrity of the NAV program in front of you. One question should plague you: How can I do what I’m asked without doing harm to the thousands of transactions that proceeded me?
How?
Programmers rarely come from the accounting worlds into programming. I don’t know why. But that means programmers who come from other origins have a place in the bidniss programming world. (Good for us! I’m a chemist. Where do I fit?)
It also means that we must start from somewhere. I started from nothing. I had to learn Debits Left — Credits Right. Someone had to teach me the theory of double-entry accounting. A very bright programmer taught me that when Bob Cratchit worked in his accounting book with a quill pen, he was in a ledger. (Pen=ledger; pencil=journal). That’s where I started.
You can start there, too. The bidniss people who engage programmers to modify and extend their bidniss automation want you to succeed. You succeed/they succeed. That’s bidniss.
Respect History
When you open a BC object and see some of the code for the first time you’ll want to call Robert B. Martin and tell him he’s right. Clean code is for the programmers who come behind. BC’s General Journal Post Line routine is 5,000 lines of pure disinformation, misdirection, CTRL-C CTRL-V nightmare as you’ll ever see.
And you can’t touch it. Or you shouldn’t. I’ll give you three good reasons:
- Without your interference it will withstand countless audits as it has withstood countless audits in the past.
- You don’t understand it[4].
- When you’re long gone, the owners will have to upgrade to the next version. If you’ve touched any part of that 5,000-line mess, they’ll have to interpret and incorporate your mess into their mess, making a bigger mess.
This mass of gibberish and white-space existed in its earliest form in 1987[5]. It probably predates 95 percent of today’s programmers. It works. If for no other reason you should give deference to this application and don’t try to fix what ain’t broke.
So you’ll have to think through the bidniss problems your customers hand you with deep respect and regard for the integrity of the NAV program in front of you. One question should plague you: How can I do what I’m asked without doing harm to the thousands of transactions that proceeded me?
The newer, online version of Dynamics BC may be better for the future. We can’t get into the innards of BC Online. We may only extend it from the outside. It’s “in the cloud,” and inaccessible.
Start thinking like this now. If you want to program inside BC where you’re allowed to change history, welcome to the club. But think like the future and respect the past now.
I’ll try to show you some ways, but if you’re a good OO programmer already, you know how. Resist the trap to become like the past. You might become part of it.
References:[1] A little Tejas lingo.
[2]See ERP in the Developers Dictionary
[3] Why can’t we decide the color of our box? Are we like the Model-T?
[4] Nobody does.
[5] See Wikipedia Who else?