Is anyone doing this? We are clearly getting having more issues than those picked up by the Incomplete Credit Card Transaction Report, and we're working towards frequent reconciliation with Windcave for card purchases, so I am investigating importing their reports into a local table to do some of the reconciliation automatically. I don't really understand all of the columns, for instance there are several columns that look like they might be a transaction id column, but none are unique, even with just a month's transactions.
Also, is it just me or is the time field mangled, with month encoded as day and vice-versa?
We're building a Tessitura-Windcave reconciliation report right now (we're also using Auth Code as the way to match things up). Windcave sends us auto-reports, so we set up an automated procedure to insert some of that transaction data into a separate database on a daily basis so that the data can be queried by our report procedure.
Kirk McMahon Do you have a method of "americanizing" the dates? I've tried in Excel and SQL, but haven't figured it out yet. I think maybe the dates are actually coming over a mix of formats?
Also, the dates are clearly local somewhere else:
Tessitura: 2021-09-01 21:14:37.070
Windcave: 2021-09-02 00:14:34.000 (Eastern?)
It looks like auth_no is something that gets cycled on a regular basis? Taking one from my Windcave report I get three entries in T_PAYMENT; 2013, 2019 and the recent payment.
I am getting a number of null values both in T_PAYMENT and the Windcave report for auth_no/auth_code, do you see that? Looks like refunds?
In our Full Transactions report from Windcave, the date appears correctly and is able to be inserted into a SQL table. In Windcave's Payline portal, there's a section in the menu on the left called My User where you can set the Date Format and Time Zone. If you can't see that in Payline, you might want to call Windcave support and ask for them to expose that to your user.
That's a good point about the re-use of Auth Codes. So far we've only been reconciling smaller time periods (we reconcile daily) where it's not likely a code will be reused, and so we haven't run into the issue yet of Auth Codes showing up for multiple transactions, but based on what you said, it seems like it'd be possible.
I spot checked some of our Windcave reports and it appears the vast majority of transaction rows that don't have an Auth Code are Declined or Error responses. Most of the refund transactions have an Auth Code, but I do see a handful of refunds that don't have an Auth Code and instead have a value in the Reference column on the Windcave report, which makes me think that those are Refund by Reference transactions put through Tessitura.
Kirk McMahon said: Most of the refund transactions have an Auth Code, but I do see a handful of refunds that don't have an Auth Code and instead have a value in the Reference column on the Windcave report, which makes me think that those are Refund by Reference transactions put through Tessitura.
Virtually all of ours should be Refund by Reference. If that's the case it's a shame it doesn't refer back to the Tessitura transaction. Does the Reference field refer to the reference number, or some other number, on the original payment?