Experience the difference of "Elite".

Bug Fixes only for the January 31st Product Update

  • Posted on
  • By

Hey everybody!  I hope 2022 has started out strong for your vacation rental business.  The biggest surge in vacation rental business always happens in the first quarter of every year, so hopefully, you're riding that wave! 🏄‍♀️🌊

This past week, we've continued doing a lot of low-level work on our infrastructure.  OwnerRez continues to experience a lot of growth, so we've taken some time in this first quarter to work on our technology and back-end systems.

Of course, no matter what else we're working on, we always monitor errors and user reports, so we released 8 updates (all bug fixes) last week that might have affected you.  Take a look!

Bug Fixes

Report export drop-down.  Have you tried exporting report data recently?  If so, you may have noticed that the export drop-down was getting cut off like this:

Not cool, right?  All good now.

Occupancy % report Y-axis.  Some of our reports show percentages (%) based on the type of report and the type of value you are summarizing.  For instance, here's a report that shows your Occupancy Percentage for last year (2021) with the previous year (2020) next to so that you can see them side by side.  We noticed, that sometimes the vertical axis would show really long percentage values because of a decimal that never ended (eg. 23.6666666666666666667%).  We now detect and round these types of decimals to two places.

Contact Us page 404ing when not logged in.  We created a new Contact Us page a few months back, and it's been working great! ...only it wasn't under the covers.  While tickets were being sent in, we discovered that the page was silently responding with a 404 code (ie. "not available") if the visitor was logged out.  The page would actually look the same, but the 404 was causing problems with crawlers and other things under the covers.  You probably didn't notice this, but it was irritating us so we fixed it.

Smarter property matching when parsing inquiries.  OwnerRez receives many thousands of inquiry emails per day that our system parses and turns into inquiry records.  This works well, only we noticed some nuances with how certain inquiries are matched up to OwnerRez properties.  What if your property listing numbers on the channel that sent the inquiry are 12" and "120" for two different properties?  If we attempt to match those property listing numbers, which number is matched first?  Suppose we look for a property similar to "12" and end up matching to both (because "120" also matches) or if there's another "12" somewhere in the email, like the number of guests.  To fix this, we now look for longer listing numbers first and we check for other property indicators other than the raw identifier.  This should help inquiry parsing be a bit more accurate!

Time zones in reports.  Back in the summer of 2021, over the course of several weeks, we corrected a bunch of features to show dates and times in the correct time zone.  If you live in California, you should see times (eg. the time a payment was collected) in US/Pacific time along with everything else you do.  The actual date and time are stored in UTC (London) time but the time zone on your account dictates how it is displayed when you log in.  We recently noticed that three reports - Booking Detail, Line Item Pivot, and Tax Detail - were showing dates in UTC (London) time instead of the user's preferred time zone, so we updated those reports to work correctly.

Extra days when filtering expenses.  Because of the way the filtering was done, the global Expenses list was including things at midnight the next day (which any manual expense will be because it has no time).  This was resulting in filtered Expenses including too many items in the results.  We fixed this to not include the extra day.

Airbnb beach access + beachfront. Airbnb recently switched their "beachfront" amenity to a "beach_access" amenity with "is_beachfront" amenity (under the covers) set to yes. This is a technical detail, but it was creating the wrong outcome, so we fixed it to match.

Inefficient country lookup.  We noticed a small edge case where the way we were comparing country codes (eg. US, GB, CA) could lead to a slowdown when many addresses or records were being checked in fast succession.  For example, think about bulk updates or imports where thousands of records are checked in just a few seconds.  It is very unlikely that you would ever notice this type of inefficiency.  It's the type of thing only an engineer would see when reviewing logs. 👨‍🔬 Nonetheless, it was noticed, and now it's fixed!