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