The pattern
Some data changes on a rhythm and has to be reflected in your system.
A daily metal or commodity price. An exchange rate. A supplier price list. A published dataset your business depends on.
Somebody currently checks it and types it in, or forgets to, and works from yesterday’s number.
A scheduled workflow fetches it, applies your rules, and updates Odoo.
Simple in shape. The interesting part is what happens between fetching and writing.
The rules are the point
Almost nobody wants the raw value written straight into their system.
Real examples of what sits in between:
A margin. You do not sell at the market rate. You sell at the rate plus a margin, which may differ by product or customer tier.
Rounding. To a sensible unit for your business.
A threshold. Only update if the change exceeds some percentage. A movement of 0.1% is noise; updating everything for it churns your records for nothing.
Limits. If the new value is more than a defined amount away from the last one, do not apply it — flag it. A source error should not reprice your catalogue.
Time windows. Some businesses fix a rate at a particular time of day and hold it.
That last two matter most. A bad value from the source, applied automatically across your products, is a genuinely expensive incident.
FIGURE 1: WHAT SITS BETWEEN FETCH AND WRITE
A sanity limit
- If the new value moves too far, flag it rather than applying it.
Your margin or markup
- You do not sell at the raw rate.
A change threshold
- Do not churn records for movements that are noise.
Rounding
- To a unit that makes sense for your business.
Fetching
Three ways the data arrives.
An API. Best case. Call it on a schedule, parse the response.
A published file. A CSV or spreadsheet published somewhere. Fetch and read it.
A page you have to navigate. Login, click, download. This is the only case that justifies screen automation, and it should do nothing beyond retrieving the file.
Whichever it is, handle the source being unavailable. Websites go down, APIs rate-limit, files are published late.
Validate before you use it
The source will send you something wrong eventually.
Check:
It parsed. You got a number, not an error page.
It is in a plausible range. A gold price of 3 or 300,000 is not a price, it is a problem.
It is fresh. Is this today’s value, or did the source fail to update and serve yesterday’s?
It moved sensibly. Compare against the last value. A 40% jump overnight is either extraordinary news or a bad feed.
When validation fails: do not update. Alert somebody.
Keeping yesterday’s value is almost always better than applying a wrong one.
Writing to Odoo
Decide what “update” means.
Overwrite a field? Simple, and you lose the history.
Create a new record? A price session, a rate record with a date. Keeps history, which matters for anything that affects pricing or accounting.
The second is usually right where money is involved. You want to be able to answer “what rate did we use on the 14th” — and a field that was overwritten cannot tell you.
Also decide:
What updates. Just the reference value, or does it recalculate product prices too?
When it takes effect. Immediately, or from a defined time?
What about open orders? A quotation created this morning at yesterday’s rate — does it change? Usually not, and that should be deliberate rather than accidental.
FIGURE 2: THE SEQUENCE
Fetch
- On a schedule, from the source
Validate
- Parsed, plausible, fresh, moved sensibly
Apply your rules
- Margin, rounding, thresholds, limits
Write with history
- A dated record, not an overwrite
Failure handling
Scheduled jobs fail silently. That is their defining risk.
Four things:
Alert when the source is unavailable. Not on the first failure — after retries.
Alert when validation rejects a value. Somebody should look at why.
Alert when the job did not run at all. This is the one people miss — a job that never started produces no error. Monitor for the absence, not just for errors.
Log every run. What was fetched, what was applied, what was skipped.
The silent failure to guard against: the job stops running, nobody notices, and the business works from a stale value for three weeks.
Running out of hours
Most of these run overnight or early morning.
Which means nobody is watching.
Two consequences:
Alerts must reach somebody who will see them in the morning at the latest. A log entry is not an alert.
A failure must not leave things half-done. If it updated 200 of 400 products and then failed, that is worse than not running — half your catalogue is on a new rate and half is not.
Prefer: validate everything, then write. Rather than writing as you go.
FIGURE 3: A SCHEDULED JOB THAT IS SAFE
Safe
- Validates before applying anything
- A sanity limit that flags rather than applies
- Writes with history, not overwrites
- Alerts when it does not run at all
Risky
- Applies whatever the source returned
- No limit — a bad feed reprices everything
- Overwrites, so history is gone
- Silent for weeks when it stops
Testing
Test the failure cases, not the happy path.
- The source is unavailable
- The source returns an error page instead of data
- The value is wildly out of range
- The value has not changed since yesterday
- The job runs twice by accident
- Odoo is unavailable when it tries to write
The “value out of range” test is the important one. Confirm it flags rather than applies. If it applies, the workflow is not ready.
The short version
A scheduled update is fetch, validate, apply rules, write.
The rules are the point — margin, rounding, thresholds, and a sanity limit that flags rather than applies.
Validate before writing. Yesterday’s value beats a wrong one.
Write with history where money is involved, so you can answer what rate applied on a given day.
And alert when the job does not run at all. That silence is the failure you will not otherwise notice.
Reference data being checked and typed in by hand?
Get in touch. We build scheduled updates with your business rules and a sanity limit — so a bad source value gets flagged instead of applied.
