Jump to content
  • 1
Mark Sollis

Old News But Still PAINFULL!



The Renewals Process


Add-ons at Renewal


At renewal you can add new add-ons and/or renew existing add-ons.

On a live policy which has an add-ons frame and a current renewal transaction, you will be able to renew the add-ons by setting the policy Add-Ons field to "Yes" (even though it is already set to “Yes") and selecting the 'Renewal' option. This will be considered renewal processing in Core Back-Office, since the live policy is expected to have been created by a quote engine saving directly to the Core Back-Office rather than creating a prospect policy first.


I know this process years old now - but it still rankles that what was a 1 step process has become a non-intuitive multi-step hassle



      ...... by setting the policy Add-Ons field to "Yes" (even though it is already set to “Yes")


Really?  Set it to "Yes" even though it's set to "Yes" already - wow - that was thought out really well.


Then not forgetting this is AFTER you have created the Renewal transaction ... In old money 


  1. Create transaction and associated charges and add-on (LE)


Now it's


  1. Create the transaction and any charge 
  2. Say "No" to Le if you have it switched in still even though you do want legal ....
  3. Go back and then Update Policy record (if you remember)
  4. Set the "Yes" to a "Yes"
  5. Select the Add-Ons wanted and then abandon them ...  (Exit)
  6. Then Say "Yes" to save


And don't get me started on the AE/AD/AF frame combos and all the additional document / frame / coding that needs to go with it

which-is--really-easy-in-Word-and-Ifs-and-also-Tables-work-well-across-Ifs-dont-they -




Ok - I know it's more complex than that but the main point is - why not just pop the Add-On processing from the transaction create screen?


User Experience not good on this one is it - how on earth do you guys cope?! 


Sign of a poor UX is sign of a rushed job imho - #agileisnotisolation


Rant over - for now

Share this post

Link to post
Share on other sites

0 answers to this question

Recommended Posts

There have been no answers to this question yet

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Posts

    • Thanks @John Tasker   Bet that took some narrowing down   So - is that to do with the rendering process in OPM do you think - re order / time taken to render? Either way - good spot - and you may want to pass to OGI for a few $$££€€     (Hope you are well!)
    • I have solved this myself so I'll update this forum in case anybody else has the same issue and is looking for a fix.   On our print server, selected printer properties for the printer in question. Advanced >  Un-ticked the "print spooled documents first" and changed the spool settings to "start printing after last page is spooled".  
    • I doubt it - and I doubt anyone ever will - until someone comes a-hunting - or an-auditing  
    • Hi @Val interesting question    The bottom line is that in the OGI accounts system it is 99% impossible to have an incorrect entry - unless the system crashes in the middle of and accounts process - or there is a genuine system fault introduced (rare). Even then - it resets itself at Month End - with a Ledger Discrepancy. So. Unless youi have had a Month End discrepancy somewhere in the process the "correct" changes have been made to the journals / ledgers - although the result means an incorrect balance on the client in question. Just go and use that entry to offset against your clients record   The real reason why this is sometimes difficult to fix however, is that on OGI, you can delete transactions - and not leave an on screen trace that they were ever there. So. The balancing adjustment may have been against a transaction that is no longer on screen / on the ledger. This is why Batch Calcs may not work in this case - because it wont be there - let alone I suspect you wont have that software and as above, can be tricky to code up.   If you are not happy with just writing this off to fees (by creating a charge / negative charge) to balance the client account (which is what I would do), then you only have one other option - you need to find the original items - which will be a pain.   Either  Check the setting in Premium Finance which uses a "dummy" client account for offsetting errors Check the settings file and have a look at those records first If no joy, go through every cashbook since raising the original transaction and find ALL entries relating to the original record and / or dummy record It will be there - you just have to find it If you have and can use InfoCentre - that makes life easier - otherwise its a manual traaaaaaaaaaaaaaaaaaaaaawl.   Overall a bit disappointed - but not surprised - that OGI wont help. It's their Finance software after all - and they know how it would write off balances - and where / which ledger account it goes to and how to quickly fix - if they could be bothered. Poor show really ....   Anyway - Good luck and hope this helps   M    
    • Thanks Pete. The guys go into OPM where there is an ODC print queue for each day of the month. They select the date in question, then right click on the branch, Print and then Print. The default printer has already been set in the Open printer Selector so nothing to change or set in there.  They do each branch in turn. Attached refers.
  • Create New...