Open ijones-kooky opened 3 months ago
Hi team - is there any update on this please?
Hi @ijones-kooky I'm having a look at this today. Sorry for the delay. I'm using a current example I've found, KAL240039 as the basis for the investigation. Thanks
Hi @ijones-kooky I think this is just a difference between how the analytics schema is built and how you might be expecting it to behave. For current tenancies, the data takes any renewals into account, and with the example I've been looking at (KAL240039), there is a renewal that ends on 04/08/2025, so this is what gets displayed as the tenancy end date. For tenancies with any other status, the end date is taken directly from the tenancy screen that you've shown in your screenshot. With this information does this help with this problem? Displaying the date on the tenancy screen (currently 04/02/2025) would be incorrect based on the renewal data. It's the same reasoning behind the difference on another example, tenancy KAL240222
I've checked in with our lettings team about this to get their view. They are going to come back to me soon with more information, but one thing we did agree on was that the analytics schema should use the tenancy end date from the tenancy screen when "End Confirmed" is checked. The grey area is that customers might want different behaviours when End Confirmed is NOT ticked, so there might need to be a configurable element to this. I'm sensing that you might want to use the tenancy end date from the tenancy screen explicitly, irrespective of any renewals etc. Can you confirm that's the case?
Thanks
Hi Pete – this does help – it just means that we will have to update the end of the renewal screen when we close out then it’ll flow through.
Kind regards,
Ian Jones Head of Finance
T +44 (0) 20 7100 5694 1 Vere Street 4th Floor London W1G 0DF [signature_1194851264]https://www.linkedin.com/company/delph-property-group
[signature_934278327]https://delphgroup.com/ [A picture containing shape Description automatically generated]https://forty8developments.co.uk/ [Shape Description automatically generated]https://mykookyhome.com/ [A picture containing icon Description automatically generated]https://delphliving.com/
DISCLAIMER: This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error, please immediately notify the sender via email or telephone and delete it from your system. We take all reasonable steps to ensure that all emails leaving our offices are tested for software viruses but we do not accept responsibility for any loss or damage which may occur from using this email or any attachment. Whilst this email has been scanned for all viruses by Panda Security Cloud Email Protection, Delph Property Group cannot be held responsible for any failure by the recipient or entity to check for viruses prior to opening the email or any files transmitted. Delph Property Group Limited - Registered Office: 6th Floor 9 Appold Street, London, EC2A 2AP. Registered No: 11121890. Registered in England.
From: Pete Littlewood @.> Sent: Monday, August 19, 2024 12:39 PM To: reapit/foundations @.> Cc: Ian Jones @.>; Mention @.> Subject: Re: [reapit/foundations] REAPIT Tenancy End Date not updating (Issue #11366)
Hi @ijones-kookyhttps://github.com/ijones-kooky I think this is just a difference between how the analytics schema is built and how you might be expecting it to behave. For current tenancies, the data takes any renewals into account, and with the example I've been looking at (KAL240039), there is a renewal that ends on 04/08/2025, so this is what gets displayed as the tenancy end date. For tenancies with any other status, the end date is taken directly from the tenancy screen that you've shown in your screenshot. With this information does this help with this problem? Displaying the date on the tenancy screen (currently 04/02/2025) would be incorrect based on the renewal data. It's the same reasoning behind the difference on another example, tenancy KAL240222
I've checked in with our lettings team about this to get their view. They are going to come back to me soon with more information, but one thing we did agree on was that the analytics schema should use the tenancy end date from the tenancy screen when "End Confirmed" is checked. The grey area is that customers might want different behaviours when End Confirmed is NOT ticked, so there might need to be a configurable element to this. I'm sensing that you might want to use the tenancy end date from the tenancy screen explicitly, irrespective of any renewals etc. Can you confirm that's the case?
Thanks
— Reply to this email directly, view it on GitHubhttps://github.com/reapit/foundations/issues/11366#issuecomment-2296365415, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BKCLRSDTTTIFP2YZ4XOIVTLZSHKMPAVCNFSM6AAAAABMGZGVEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJWGM3DKNBRGU. You are receiving this because you were mentioned.Message ID: @.***>
Thanks Ian - for what it's worth, our lettings team think we should always return the end date from the tenancy screen here anyway so I just need to get some product alignment. As we can't just go-ahead and change that behaviour (as a lot of data will suddenly change for people), it's likely something we'd need to make configurable. Therefore don't go and change your working practice just yet until we've decide if we will make any changes
Hi Pete – sorry – I have just checked back in on the original example and still it shows incorrectly in the tenancy table? I have blanked out the personal data – but if you look on the renewal screen we have adjusted the end date to 28/8/24 a while back but still in the tables being queried it shows the old completion date? @.***
SEE BELOW FOR TABLE EXTRACT @.***
Ian Jones Head of Finance
T +44 (0) 20 7100 5694 1 Vere Street 4th Floor London W1G 0DF [signature_1194851264]https://www.linkedin.com/company/delph-property-group
[signature_934278327]https://delphgroup.com/ [A picture containing shape Description automatically generated]https://forty8developments.co.uk/ [Shape Description automatically generated]https://mykookyhome.com/ [A picture containing icon Description automatically generated]https://delphliving.com/
DISCLAIMER: This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error, please immediately notify the sender via email or telephone and delete it from your system. We take all reasonable steps to ensure that all emails leaving our offices are tested for software viruses but we do not accept responsibility for any loss or damage which may occur from using this email or any attachment. Whilst this email has been scanned for all viruses by Panda Security Cloud Email Protection, Delph Property Group cannot be held responsible for any failure by the recipient or entity to check for viruses prior to opening the email or any files transmitted. Delph Property Group Limited - Registered Office: 6th Floor 9 Appold Street, London, EC2A 2AP. Registered No: 11121890. Registered in England.
From: Pete Littlewood @.> Sent: Monday, August 19, 2024 12:39 PM To: reapit/foundations @.> Cc: Ian Jones @.>; Mention @.> Subject: Re: [reapit/foundations] REAPIT Tenancy End Date not updating (Issue #11366)
Hi @ijones-kookyhttps://github.com/ijones-kooky I think this is just a difference between how the analytics schema is built and how you might be expecting it to behave. For current tenancies, the data takes any renewals into account, and with the example I've been looking at (KAL240039), there is a renewal that ends on 04/08/2025, so this is what gets displayed as the tenancy end date. For tenancies with any other status, the end date is taken directly from the tenancy screen that you've shown in your screenshot. With this information does this help with this problem? Displaying the date on the tenancy screen (currently 04/02/2025) would be incorrect based on the renewal data. It's the same reasoning behind the difference on another example, tenancy KAL240222
I've checked in with our lettings team about this to get their view. They are going to come back to me soon with more information, but one thing we did agree on was that the analytics schema should use the tenancy end date from the tenancy screen when "End Confirmed" is checked. The grey area is that customers might want different behaviours when End Confirmed is NOT ticked, so there might need to be a configurable element to this. I'm sensing that you might want to use the tenancy end date from the tenancy screen explicitly, irrespective of any renewals etc. Can you confirm that's the case?
Thanks
— Reply to this email directly, view it on GitHubhttps://github.com/reapit/foundations/issues/11366#issuecomment-2296365415, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BKCLRSDTTTIFP2YZ4XOIVTLZSHKMPAVCNFSM6AAAAABMGZGVEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJWGM3DKNBRGU. You are receiving this because you were mentioned.Message ID: @.***>
@plittlewood-rpt Hi Pete - wondered if you could help again?
Our end dates aren’t updating in the tenancy table when we change end date. Here you can see it’s set to 7/8/24 and this was updated on the 10/7 but the table below is still showing the original end date
See the Tenancy Table below still showing the end date as 2025?
I have tried to separately go and update the original end date on the "end of tenancy tab" but i was told this wouldnt need to normally be done.
thanks, Ian