Hey everyone, we're back with another belated product update. This update covers our July 1st release with 17 juicy updates, including a couple of new features and enhancements. Give this a quick read before you head off to your weekend! ☕️
New Features
Vendor Name on Expenses
Our PM module has a powerful Expenses feature that lets you record all the expenses that you need to charge your owners for. Whether they are small booking-level expenses, like credit card fees or host fees, or larger property-level expenses, like monthly lawnmowing, our expenses feature allows you to enter and record them all and then include them on statements so that your owners pay you back from their earnings.
One thing we noticed, a while back, was that there was no Customer or Vendor name on expenses. There is a description field, so you can enter something like "Paper products from Walmart," but no way to record "Walmart" as the Vendor, which is then searchable and sortable in the expenses list. So if you want to find all Walmart expenses, you have to search the description field and hope that it's included (and spelled the same) everywhere. Also, as we look to the future, we know that accounting systems like QuickBooks require vendor information, so if our expenses synced to QuickBooks, we would need to support that down the road.
We have added a new "Vendor Name" field to expenses. Head on over to the main Expenses list (under the PM area) and you'll see a new "Vendor" column.
Right off, you'll notice that some of your expenses already have a vendor name in place - ones like Airbnb, Vrbo, Booking.com, Stripe, and so on. This happens when our system sees an automatic expense from a known vendor name. We automatically put that name in place for you. However, the other expenses that you've entered manually will show "none" under the vendor name because nothing was ever entered. It's time to get those updated!
You can update the empty ones in bulk, so let's go ahead and do that! Use the filter to search for some common vendors by using the Description filter. When the results appear, select the ones you want to update, click Batch, and then click the Set Vendor button. In this example, I am searching for "Walmart" expenses.
This will open a small window where you can type in "Walmart" and put that in place on the selected expenses.
While you're there, you may want to set the expense "Category" as well. You can do that from the same batch operation, using the "Categorize" button. For these Walmart ones, I would probably select "Supplies" as the category.
Now that we've cleaned up the old ones, let's look at the Record Expense page where you go to record a new expense. As you might expect, there is now a new Vendor field on that screen.
The same thing appears when changing an existing expense. Vendor is not required, so if you don't want to use it, leave it empty.
Once your vendor names are set, you can search for expenses with that name using the list filters because "Vendor" is now a new filter option. Perhaps you want to search for a description or amount but also by the vendor name to narrow down the list. You can now do that.
You can also run reports that show the Vendor in both detail as a grouping level. For instance, here's the Expense Summary report with "Group By" set to "Vendor." Notice the results at the bottom.
Any expenses not in a group (i.e. without a vendor name) are shown in the top "None" row so that you can see those amounts as well.
Vendor Name should help you manage your expense records, and, over time, will be expanded into other parts of the PM system like custom statement views and year-end reporting.
Set Tags/Fields via API
If you use our API, you'll be excited to know that we've added Tags and Fields to our API. To be clear, that's the OwnerRez API that we host for our many partners who build integrations and apps for OwnerRez, not the channel APIs we connect to for our channel management feature.
If you're a developer and haven't seen our API in a while, head on over and take a look. You'll notice the new API documentation area, and you'll see that we have the 1.0, 1.1, and 2.0 APIs broken out clearly, along with their status. The 2.0 API is where we are focusing most of our effort on new improvements and enhancements, though the 1.0 and 1.1 versions will stay up for a long time as we transition things over.
In the 2.0 docs, you'll notice the new Tags, TagDefinitions, Fields, and FieldDefinitions sections. If you're a developer, you can drill in and figure out how those work on your own.
The cool thing I wanted to point out is how tags and fields are mixed into bookings directly. Check out the booking endpoints, and you'll see what I mean. Now, when you return booking data, you might see tags and fields directly on the booking like so:
{
"id": 12345
"firstName": "Joe",
"firstName": "Blow",
"tags":
[
"name-one"
"name-two",
"name-three"
...
],
"fields":
[
{ "code": "BXCLEANER", "value": "Sam" },
{ "code": "BXGENDER", "value": "him" }
...
]
}
You instantly see the tags and custom fields without needing to make an additional call. Pretty sweet, right!
One of the high-level goals of the 2.0 API is to reduce chatter and provide a more-functional interface for developers. In other words, we want you to do more stuff with fewer calls. This approach of mixing in tags and fields achieves that because, as a partner, you can request booking data and see the tags and fields for that booking at the same time without making additional calls against the Tags and Fields endpoints. Over time, as the 2.0 API expands, this pattern will include guests, quotes, properties, and other entities, and we'll allow you to set tags and fields using the same structure.
Enhancements & Tweaks
New Status Column on Owner Statement Bookings
A while back, some users pointed out that there is no way to show owners the status of their booking when the owner is looking at their statement. If the arrival and departure dates are on there, it should be obvious whether the booking has arrived, is mid-stay, or has departed, but some owners gloss over when they see the dates. Also, what about cancellations? Some owners wonder why bookings show up with small amounts or refunds and don't realize that the booking is a cancellation that still had revenue remitted through to them.
So we added a "Status" column to owner statements. It isn't on the default views, but you can go into your custom statement views and add or change the columns list to include it.
The new "Status" column is special to owner statements and will display one of four values depending on the booking:
- Pre-Arrival
- Mid-Stay
- Post-Departure
- Canceled
These statuses should be self-explanatory as they depend on the dates of the booking and are all mutually exclusive. As with any other column, you can move around the order of the column and change the header title to call it whatever you want. Hopefully, this helps your owners clearly see what they're looking at as their eyes skim over the statement.
Bug Fixes
Underscores showing in WordPress amenities. Our WordPress Plugin creates a dynamic bridge between your WordPress website and OwnerRez. Any time your OwnerRez data changes (property headlines, photos, amenities, rates) your WordPress site will update in real-time to match. However, we noticed that some of the amenities were being transformed to include underscore ("_") characters in place of some special characters, which was caused by the underlying API between WordPress and OwnerRez. This has been fixed!
Multiple values not working in API operations. If you use our API (the same one I talked about with the new Tags and Field stuff above) you may have noticed that you could not assign multiple values to things like "day of the week". For instance, if you assigned a Monday and Tuesday value at the same time, via a bitwise operation, the API request would fail. This is because our API was parsing values based on straight numbers and not considering bitwise combinations. This is now fixed. (And I'm super psyched that I got to say "bitwise" twice in a product update post).
Percentage labels on portal area owner charts. Our portal area shows a Dashboard with revenue and occupancy charts for any owners that have been granted access to the portal area. However, the Occupancy chart was using a 0 - 1% range instead of a 0 - 100% range as you might expect. This has now been fixed. While we were there, we noticed that some decimal amounts were producing long unreadable numbers, so we chopped all decimals to 2 digits.
Location edit messaging. When you change a property address in OwnerRez, we ask if you'd like the system to automatically change the latitude and longitude as well. However, the system was over-asking about this. If you only change the lat and long, there's no reason to ask again. And if you change the lat and long manually, even if the address is changed, there's no reason to ask then either. So we updated our messaging to detect those things and stop bugging the user.
Check field code send-ability in messages. If an email template has a field code for one of the email headers (e.g. the "TO" or "FROM" address), we assume that there's an email address in it. It doesn't cause an error during sending because our email sending engine will skip the message if the email headers don't have valid email addresses. This makes it tough to understand why an email message wasn't sent. To fix this, we changed our message pages to check for field codes that have bad or missing email addresses, and we show that before letting you save the template. We also show this in trigger statuses so that you can see if the trigger message won't be sent for that reason.
Honor required gap rules for quote holds. Because we implement quote hold as blocked-off time, quote holds weren't factored into "required gap" rules. The rule would be checked when creating the quote, but until the quote was accepted and turned into a booking, somebody else could book right next to the held quote. This has now been fixed. We now treat a quote hold the same as a booking when it comes to required gaps.
Honor user weekend setting when checking min nights by arrival for weekend min less than default min
Testing on payment methods. Recently, we accidentally broke the payment method "test" process for card-based tests. This is the test that the system runs when you add a payment method and then click the Test button to see if the credentials work. The test is conducted by actually trying to authorize a test credit card and seeing what error message is returned. This is now fixed.
Owner Statement Expense Remittance includes too many expenses. Recently, we noticed that the Owner Statement Expense Remittance report (wow, that's a lot of words!) included owner-level expenses even when individual properties were selected in the report filter area. Fixed!
QuickBooks trial subscription ending. No longer using QuickBooks? No problem, it happens! We now detect that your QuickBooks subscription has ended and turn off your QuickBooks sync settings in OwnerRez automatically. Before, our system would send you error messages about your bookings not being able to sync, but we've made it smarter!
Changing a quote that's been booked. When we implemented the change/move screen for quotes, we lost the block that keeps you from changing quotes after they've been booked, so it has been possible to change or move a quote even after it is booked. No longer! We put that validation back in place. Like the good ole days, you can no longer change or move a quote after it has been booked.
Add blank item to header editor action menu. Our Hosted Website has a flexible editor for changing how your menu, contact inks, and other parts of your header appear. However, in the "action" list of the header editor, we didn't have an empty item, so it was easy to add a link to the wrong page if you were not paying attention. We fixed this. We now show a top "[select page]" option so that you understand that one of your web pages needs to be selected for that link to work.
Disabled security deposit messaging. Have you disabled security deposits for your property, or maybe disabled them just for a single quote or booking? No problem, that's normal. But you may have noticed that the security deposit stuff still worked.... sort of. The guest form, request form, preview windows, etc. would all appear like normal even though you had security deposits disabled. This was confusing. When actually using them, the system would throw error messages because it would see that security deposits were disabled when actually trying to process them if the guest entered their credit card. To head this off, we now show messaging earlier in the process that reminds you (and the guest) that the security deposit is disabled. The guest sees a friendly "A security deposit is not required" message, and you see something similar on the app side.
