Your ERP version decides which fields exist

You find an example online of how to pull a certain field out of your ERP. Someone has written it up neatly, it looks logical, you copy it over.

And it does not work.

Not because you made a mistake. Because that field no longer exists in your version.

What happens at a version jump

ERP vendors running in the cloud release new versions regularly. Fields disappear in the process, fields get added, and the meaning of existing fields changes.

If you use the application, you barely notice. The screens keep working, something gets added, something falls away.

If you pull data out of it, it is drastic. Your script asks for a field with a particular name. If that no longer exists, you get an error message if you are lucky, and silent nonsense if you are not.

I ran into this concretely on a recent cloud version: a field that sat on the accounts table in older versions to mark an account as no longer in use does not exist there anymore. Every example written before that version that uses that field fails.

The habit that fixes it

Ask the system itself which fields exist, before you request anything.

Every decent API has something for this. You send a question to the model you are interested in and you get back the list of fields, with their types. That costs you one query and it is the difference between guessing and knowing.

Do it at the start of every project, and do it again after every version jump of your source. Store that list somewhere, so that when a problem comes up you can compare with how it was.

The harder case: same field, different meaning

A field that disappears is something you notice. That is annoying but honest.

The dangerous case is a field that stays in place but gets filled differently. Then everything keeps running, your report shows numbers, and nobody knows something has shifted. You only discover it when someone recognizes a total that is off, and that can take months.

There is only one defense against that: a check that runs along every single time. Count the number of rows you pull in and compare it with last time. Add up your revenue and compare it with a total from the source itself. If it deviates by more than a threshold, you want a signal, even when nothing looks wrong.

That is ten minutes of work when setting things up and it catches the one kind of error you would otherwise not see.

Why this will happen more often

Cloud versions of business software refresh faster than the versions companies used to leave in place for years. That is good news in itself, because you get improvements without a migration project.

But it also means the agreement between your connection and your source no longer stands still. What you build today runs on a source that will be different next year. So build as though that is going to happen, instead of hoping it will not.

In practice: put your extraction logic in one place instead of spread across reports, so a change is one intervention. Log which version your source is running on every execution, so that afterwards you can see when something tipped over.

The claim

A connection is not an installation but an agreement with a source that keeps moving. Budget for it as one-off work and you get the bill later, at the moment when the numbers have already been wrong for a while.