Jump to content

Mark Sollis

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Mark Sollis

  1. Not 24 hrs before your post! A despairing mini-rant criticising the very response you received. Feel free to add a real life instance on there - Typical Standard Response Warning
  2. Sorry - the above was a more generic prompt for ALL brokers - particularly those who need to review their risk appetite - not aimed at you guys per-se Ditto for this - and to make sure everyone is aware they can't blame or claim from, their supplier for their own inadequate security analysis and prevention I feel your pain with the horses - but at least you found the water - that's half the battle
  3. Tbf - I’d be interested in comparing how the competition / alternative OGI solution aka Virtual Cabinet, manages the same situation. That’s the real benchmark / leverage. If cyber is a concern - or a requirement of your BI - I’d suggest taking a serious look at those security functions in both. Then make your choice. #whosheadisontheblock
  4. Sounds like the usual "Let's wait until it happens and then we will do something about it" kind of approach That approach went well with the NHS too ...
  5. There will be issues whichever way - so you need to pick the right way for you at get it right first time. In short - and from experience on both sides - I'd say transfer now to your server, as separate branches. This may involve some logistics for connectivity (I don't know your set-up) but on the face of it - is better than running multiple servers and multiple business processes. You'll thank yourself in the long run Moving / migrating / transferring / consolidating to one branch - on the same server - is far, far easier to manage once the data is on one platform. Trust me on this.
  6. Sorry Sandra - Are you planning to merge the branches on THEIR system - or merge and migrate to your server? The first is as everyone has said above - the latter is potentially a whole new world of complexity - x 10!
  7. Hi Sandra Big question - and lots to consider. You haven't said, but I presume this is to do with an OGI to OGI transfer, with branches already on the same server? If so - and to help kick this off, top 5 tips below from me: Specification - Make sure you have a spec of what will - and what wont - be transferred Settings - Check that all your settings are the same. Many are branch independent and you really need to check all of these for future use. This includes source codes, exec codes, Database Reports, User Access authorities, Broker Record / Prospect record settings, Regulation Module options, Document / letter templates to name a few from a long long list Prospects - Do you use APM / Prospects - and what will happen with these records Accounts and EDI - If it's OGI>OGI then EDI should be OK, but you do need to have a plan for the accounts. For both, will the old branches be in run-off or transferred en-bloc / big-bang? If Run-off - how are you maintaining both sets of data? Why? - Revisit why are you doing this anyway - quite often it's not the only solution - and I'd be interested more in what you are trying to achieve and why you think branch consolidation is the answer I'm sure Open GI will have already asked all the above questions - and more - to get to the right solution for your business. But always worth taking advice on a big change Hopefully others will have input as well Good luck and let us know how you get on!
  8. EXTENDED OFFER Even though "lock-down" has almost been confined to the history books, there's still lots of uncertainty across the UK Restrictions and limitations are impacting businesses every day and worse still, the uncertainty looks continue for a while yet Whether you need more knowledge or just better insight, at OneFiftyPercent we want to help as many Open GI brokers as we can If you want to re-boot your business or take away current system pains there is no better time than the "now" For help with any aspect of your OGI systems or associated applications, just get in touch with us and book your FREE call Guaranteed 150% - No strings. No Fees. No catch. Leave your preferred contact details at the link here and we'll be in touch #karma #network #freehelp #OFP #resultsdontlie
  9. Hi Mar - and welcome to the Forum! I think the issue is that the error message will be best investigated by OGI. I've never seen that one - but maybe some other live users may be able to assist. Other than checking the document filename / length of filename for the template and / or the trigger document - it would be best to log with OGI Sorry I cant help - but sometimes its just a program error! - Oh - do check you are on the latest Vs of OpenSuite products - and especially ALL client software (each PC) is also upto date - that often causes random issues like this (and OGI will say to check / upgrade as a first step anyway) Let us know the outcome!
  10. Public Service Announcement As an independent Consultant, I have over the last few weeks had calls from a number of brokers asking how they can operate best during the lock-down & how they can service customers more easily We all need to get through this together & one of the things I wanted to do in some way, was to help people across my networks - no strings attached So I'm launching an offer of a FREE phone call with REMOTE HELP covering any aspect of your OpenGI system and / or broker business functions. This also includes business related products such as Microsoft applications, as well as helping you look at long term income generating options with better marketing and use of social media There's never been a better time to set the foundations of your future business - right here right now This is a limited availability offer and a number of daily call slots are allocated FCFS basis over the next few weeks. If I can't help directly then I'll be happy to advise best routes to get your pain sorted. If you could use some system help, process advice - or just need a quick answer to an urgent issue, then get in touch. If you are a valued User Group Member we have agreed to offer twice the allocated time to assist. No strings. No Fees. No catch. Leave your details at the link here and I'll be in touch by return #karma #network #freehelp #OFP #resultsdontlie
  11. Great news - glad to hear some sense has been applied 🙂 I'll drop you a PM here as well - #thoughts
  12. Hi James - any updates on this - really interested to see what the outcome was And FYI for anyone in the same position - I've actually defined the solution that actually works 🙂 - happy days! 😷
  13. Adding new fields does not (should not!) require a bulk insert. If it's the case that anyone needs to, then a fix is required from Open GI imho. The whole premise for th£ upgrad£ to IC "PLUS" was to solv£ the n££d for bulk ins£rts when - tables (frames) were added, fields were changed or, new VT entries made (insurers etc) We all have to demand the best solution and get OGI / help OGI to fix what is broken - otherwise it will never change and we will all be running bulk inserts everyday for the rest our lives - which is what we did before ICPlus was launched. #petpeeves
  14. Wellllllllllllll I'm not sure #OpenGI "support" keyword changes - I suspect it's an oversight but can be useful for sure. Strange that the ICP table is OK but the view is failing - why does 'SELECT * FROM' need to know the column names Yep - sounds like a fault feature that needs to be resolved 🙂
  15. Hi all 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? #askingforafriend
  16. 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
  17. 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
  18. Thanks @JamesStill - all makes sense Thennnnnnnnnn thats a fault then isn't it?! If the current ICP solution provides a real time transactional reporting database - then it should operate and be performant. The whole campaign around (and upgrade cost of) ICP was so that bulk insert wasn't required and a data refresh was the exception not the rule. It's what everyone paid for on the upgrade. We need to help OGI get this right and get it fixed to do what it's supposed to do - no help to you right now though ... Your SQL code example in the OP takes up 5 lines of code. BCPL won't be much different IMHO - but I shouldn't question the detail. But yep - 14 days all in @ £x thousands per day + VAT is a lot of dosh for the equivalent 5 lines in BCPL. If I was asking a builder to quote for an extension - I'd like to see the basis of the quote - so I could understand the complexities. Obviously to arrive at a figure there must be some finger in the air guestimate of the work involved. So what is the Schedule Of Works expected upon which their figure is based. No different to a code build - what are the steps and what are the associated estimate for each. Its a fair question if someone is about to spend that sort of money. For a discussion with a developer on other options What if the extract of the BAH was done offline - from the backup file set - and then used to populate / overwrite the SQL BAH table separately? OR How easy is it to have a new (VSAM) table that is a subset of the BAH and holds data based on a Broker Amendment parameter of n Yrs. I wouldn't be surprised if this was 5 days effort all in ... The whole purge issue is one that needs looking at and I believe some of this work is being considered - worth persuing to establish the scope of change in plan / being planned to make sure it is fit for today's integrated environments i.e. IC/ICP wasnt really around when purging was such a hot topic 😐 Whatever the position I'd explore this route first - and if OGI haven't done so or explained why that file is taking so long, then they should. If a dedicated SDD fixes this - then that will be a 3 figure solution, not a multiple of 5 (I'm being optimistic I know, but the principle holds true) If all else fails, one option could be to split the extract file processing. The default initialises the DB but "maybe" it's possible to only initialise a table (in the pre-sql script) and then extract just the BAH table weekly. I'm sure those options have been considered by OGI as lower cost alternative solution .... and maybe they have and dismissed it for good reason. Another fair question though... Overall - a very tech product / area and in reality, only OGI can provide the right solution regardless of my ramblings which are nothing more than conjecture. So there has to be some reliance on and trust given to, the tech provider. Nothing comes for free and you just have to be happy you are getting a fair deal. If it was my business though, I'd still be asking for all the options, alternatives and a best guess breakdown of all costs - and my "supplier" would need to justify their numbers Hope the above helps and let us know how you get on and what route / solution you end up taking
  19. Hi James - hope you are well!! Great question and I'd be glad to offer some options / advice if I can ... First off - 1 - Why are you doing a data refresh? 2 - What is the "custom solution" (i.e. what is the proposed development that will be completed) and what is the cost? 3 - In any event, if you purged the associated Client Policy files prior to 2015 on the server - presume the log would be pruned too - obvs? #interestingtopic PS - nothing, Nothing, NOTHING, NOTHING in our world should take 12 hours to process a single file. Your full back-up OF EVERYTHING doesn't take that long - I presume the bottlenecks were investigated before the "custom solution" was proposed? @Tom Davies @karl @maskelleto
  20. Well that seems strange!!! whats the point of having an agreement between parties if those parties are not entitled to know what the agreement is 🧐 I’ll make sure we clarify at the April meeting. Meanwhile, it would be good to know “what” information will be acceptable to the auditors. They are the ones asking the questions - so what are the questions they want answered? Then we can put those to OGI for their response. #lefthandrighthand
  21. Hi Clare Sorry if your original message went unanswered - I'll try and track down what happened to that! Meanwhile FYI - OGI confirmed that they had responded to Diarmuid and provided detail on the Escrow and how it would be activated. As the Escrow document is held by OGI until such an event occurs, then anyone requiring further info should enquire via their Account Manager in the same way. I am aware that the User Group will be publishing some headline info for reference only - but ultimately the source will be Open GI for the full and best answers on this Hope this helps
  22. Hi Vanessa Couldn't possibly comment on specific contracts or potential tactics - and certainly not in a Pubic Forum!! However .... All businesses driven by sales are prepared to negotiate. Particularly when it's for software they "own" and without any significant "support" overhead. All businesses have to make money - that's why they exist - but how much is too much What's the comparison of cost to these extra licences Vs the existing ones? All businesses have sales cycles - so when is the Month End and will the discount go up the closer to Month End you get? All businesses have a Year End - so will the discount go up the closer to Year End you get? All businesses will negotiate for a bundle - is there anything else you can get thrown in for nearly "free" to make the overall cost worthwhile? I'm sure others have been in a similar position and maybe they can offer some nuggets. Unfortunately it's sometimes down to what the price is "on the day" - as you have already found. Not ideal - but it can depend on what sway you have - and the contract you already have in place. Pricing flex (to extreme) is not unknown in the OGI sales kit-bag - whether that continues to be the case in the future no one knows. Drop me a message if I can help further M
  • Create New...