Anyone using Sanctions check in anger?
Had an issue which I couldn't fully resolve or pinpoint where the list is often short of name data. On closer inspection the names are blank when the Forename is not completed (often the case on non-writer products) - and the report seems to "assume" that if there is no forename, then the BCM.Name is irrelevant / not used / not printed. I'm probably completely wrong -
I suggested they raise with OGI - just wondered if this is a known factor across the user base?
Correct - but as @JamesStill says - there are issues if refresh/insert is not run at least weekly which is what he is having to do. The whole point of ICP was this is not a requirement
So - I'm with you - that this is a "fault" if problems occur with replication of data - and should be reported to get fixed. Otherwise, its not doing what it's supposed to be doing . Meanwhile - James still need's a solution.
Speak to the Account Manager - on both counts and shelve the £xx,000 estimates
@Mark Sollis I'm assuming these lead times should resolve once ICP is running as intended and without the repeated full updates?
If the system is "up to date", which it should be, in real time, then the return of info should be relatively quick, especially if restricted to a shorter date span?
Or have I got my wired crossed again?
I guess my take-away from this is;
Solution is to go back to OGI, either Support or personally, I would go to my Account Manager and ask them to look into possible problems with ICP data feed. Maybe even ask for an Engineer to take a look in case there's something wrong with the setup causing the data return issue.
If they confirm it's not ICP, then perhaps look into other solutions, but for me, the bespoke solution is normally very expensive and won't necessarily leave you happy!
Agree - It should be noted however, that the ICP upgrade was promoted (sold?) on the basis the new features meant it wouldn't need a refresh when new tables / frames / insurers / execs were added - so would question any need in those circumstances tbf.
Yes - once in a blue Monday moon to make sure all is in synch - but low level hiccups should be managed by the app and it's processes to "catch up" any missing changes
As far as the views go, you are correct to maximise performance on SQL tables of a size - but this won't solve the transfer times described by @JamesStill
Just needs a bit of lateral thinking to get the right solution at the right cost. Just seems a knee-jerk "Ch***zillion" estimate for a solution that probably could be done better and at lower cost if the issue was better investigated and scoped
In respect of the Purging, this is an Open GI User issue for everyone and so will be raised for discussion at the next Committee meeting. Would you agree @Mark Sollis?
Purging was designed in the day when people wanted it as an option but rarely used it. So it allowed you to pick and choose how much you cleared, which might still need to be on offer.
However, personally, I would like to see a packaged "Purge" where based on a set of criteria (including the option to exclude certain policy types or frames and dates), then out of date policies will go if a live one remains on the client file but the client file remains in place but if not, the whole client file is purged.
Needs discussion and some open debate within the Membership but it's certainly worth investigation!