What's this-- another product update in the same week? Yeah, we're awesome like that.
Hey everybody, I'm back with another 15-update release to go through. What actually happened is that I was late writing about the last release, so the spacing got messed up. But whatever, let's get to it!
- Enhancements & Tweaks
- Bug Fixes
We occasionally look for new things to add to statement views based on common PM feedback. This past week, we added a new set of "Night" columns.
There are both "Nights" and "Nights (In Period)" columns that you can select. As the names imply, one is the full number of nights of the stay, and the other is the number of nights within the statement period. This allows you to show the number of nights that go along with the pro-rated amount you are remitting to the owner.
Remember the warnings we issued about Old Stripe being turned off and SMS messaging requiring a brand? That deadline has now arrived.
If you had an old Stripe payment method, it has now been disabled. If that was your only method for collecting credit cards, your OwnerRez account no longer has any active way to collect credit card payments.
If you used SMS Messaging but didn't have an SMS Brand on file, your SMS messaging has now been disabled.
If you were affected by either of these issues, look back at previous blog posts or the email messages that were sent directly to you with instructions on how to fix these issues.
Have you been annoyed by any door lock stuff recently? Well, we have! We've been building a list of stuff to tweak, and this past week we knocked out a bunch of it.
First, we noticed a situation where you couldn't set a manual code on a block because the door lock associated with that property is set as "bookings only". But hey, if you want to manually set a code, the system should let you set a manual code, right? It now does.
While we were there, we updated manual door codes to accept the pound sign ("#") as a valid character so that you can include that directly in the code. A lot of users need to specify "#" as one of the buttons to press because the lock requires that for starting or ending a numeric sequence. Now, you can use "#" wherever you want in the code.
Then, we changed how door codes work when moving bookings to different properties. Previously, if a door code was generated on a booking, and then the booking was moved to a different property, the same door code stayed on the booking, even though the lock was mapped to a different property. This was intentional because we didn't know if the user intended to change the code or keep it the same. After all, the guest might have already been notified about the code for their booking. However, it continued causing support issues, so we changed this so that if a booking is moved to a different property that doesn't have a door lock configured, the door code is removed from the booking. If the door lock on the new property is manual, the manual door code remains in place.
Finally, for properties that have two or more different door lock types, we are generating different codes for each account. We don't reuse the same code across multiple accounts. If you happen to use "last 4 of phone", the codes will end up the same. If your generation strategy is random or by lock, it made sense to get a different code per door lock, so we switched to that.
Rotate images even without a file extension. Did you know that OwnerRez automatically performs several cleanup steps on every image that is uploaded to our system? One of those cleanup steps is rotating smartphone-generated photos to the correct native layout instead of keeping the original layout because smartphones use tags (known as "EXIF data") to denote which way - portrait or landscape - the image should be displayed. Lazy smartphones! We know from experience that other downstream partners (like Vrbo or Airbnb) do not always respect those tags so the image may end up rotated the wrong way on the channel listing. Recently, we noticed that some images are uploaded without a file extension (like "my-cabin" instead of "my-cabin.jpg"). When that happens, our image cleanup steps weren't being followed. We now check if it's an image and, if it is, do the cleanup steps regardless of whether the file has an extension or not.
Update booking stats after all charges have been changed. When canceling a booking, you can adjust the charges at the same time to account for any refund sent back to the guest. When charges are adjusted, the booking's stats - things like total paid, total owed, etc - are updated as well. We noticed that when adjusting the charges during the cancel process, the stats were updated every time each line item was changed. If 10 charges were adjusted, the stats would update 10 times. In addition to being inefficient, this can lead to errors because the intermediate total can go negative temporarily. We fixed this to delay the stats from updating until all the charge line items were finished.
Expense category cleanup. In the last release, we added a big category update to Expenses so that you can cleanly categorize things like supplies, lawn care, and cleaning into proper categories for downstream reporting and automation. We noticed a few things to clean up, so we jumped on those right away. We also saw a bunch of historical expenses, and expense settings on surcharges, that we could create some mappings for, so we put those in place. This will put some categories in place on your existing surcharges and expenses.
Blog menu conflicts when creating the first post. A few updates back, we updated the blog in our hosted websites builder to automatically create a blog menu whenever the first blog post is written. This helps the user instantly see where the menu appears so that they can style or move the menu around without realizing that they first need to create one. This was a great little update, but we ran into an error where some users already had blog menus in place and a conflict occurred. We now detect that situation and steer around it.
Now gaps for bookings ending today. A while back, we fixed "now gaps" to consider whether the gap included today. The fix made it so that a gap changed in size relative to today instead of when the last booking departed. Recently, we noticed a related issue where if a booking departs yesterday, it can cause gap rules to apply to today, causing today to be unbookable because the gap is in the past. We expanded the "now gap" fix to detect if the start of the gap is today or yesterday before evaluating gap rules, and if it is, we no longer apply the arrival gap.
QB customer match with empty guest names. We recently fixed how guest names match up to customer records in QuickBooks. We completely rewrote our matching code to smartly detect and use existing customer records instead of always adding new ones. The feedback has been great on this, but we noticed an issue where the name matching would crash if the guest's first name was empty in OwnerRez. This has now been fixed.
Error message with bad HTML. You won't know this bug existed - in fact, no one will - but we're happy to say it's been fixed anyway. For a few months now, our engineering team has been monitoring and tracking a very rare bug where error messages show a Yellow Screen of Death instead of the normal nicely-formatted message you're used to seeing. We thought we had fixed it a few times, but it kept coming back. We're finally happy to say we believe it is now fully fixed. Yeah okay, no one ever saw it, but it's the little things in life. 😊