Rev 1.5
From TipperWiki
Misc audit requests and other things Opera and/or Rainmaker asked me for. --Jhannah 15:49, 18 November 2008 (UTC)
Contents |
RT6830
These records were never sent to Rainmaker. Can you take a look to see why these records were not sent? --sromas
2011231463
AUSCTR. Booked on Aug 31, 2008. My SENT archive doesn't go back that far, so I can't confirm or deny that I sent a record on Aug 31. I have no errors in my log for that reservation number. I assume that will be the case for several below... --Jhannah 18:41, 14 November 2008 (UTC)
2011231874 2011232455 2011232456 2011337220 2011337545 2011337547 2011337654 2011345201 2011529145 2011529169
(Haven't looked at those yet.) --Jhannah 18:41, 14 November 2008 (UTC)
2011529296
This exists in Omni CRS, but not in the PMS. I can't explain that at a glance. --Jhannah 18:41, 14 November 2008 (UTC)
2011580942 2011580943
AUSCTR. Both booked today, so I won't send until tomorrow. --Jhannah 18:41, 14 November 2008 (UTC)
13600351203 13600351208 2011301639
These records are showing as CXLD in GRS, ORD and Epitome but we did not send the cancel to Rainmaker. Can you see why?? --sromas
2009711235
Booked in 2007, cancelled Sep 21 2008. I should have sent an X on Sep 22, but didn't. Looks like this was one of the days I sent no reservations at all.
$ grep 'res' RevData.AUSCTR.20080922.xml <reservations> </reservations>
That problem was RT#6618, whose fix was applied to production on Oct. 11. --Jhannah 18:58, 14 November 2008 (UTC)
2009711244
Exact same RevData.AUSCTR.20080922.xml issue as above. --Jhannah 19:04, 14 November 2008 (UTC)
2010406626 2010984542
AUSCTR. Both cancelled on Aug 31. Should have sent on 09/01, but didn't no <res> records were sent on 09/01. Sep 1, 18, and 22 were the three days that RT#6618 struck AUSCTR in September. --Jhannah 19:04, 14 November 2008 (UTC)
2011288378
AUSCTR. Cancelled on Sep 17, so this is RT#6618 again. --Jhannah 19:13, 14 November 2008 (UTC)
2011288410 2011308729
Both AUSCTR. Both exist in Omni CRS and PMS, but not in Opera (now that my lookup tool is Opera centric the load fails... should I fix that?). Sent st="F" on 09/12. Cancelled on Sep 17, so this is bug RT#6618 again. --Jhannah 19:17, 14 November 2008 (UTC)
2011334934
AUSCTR. Cancelled on Sep 21, so this is RT#6618 again. --Jhannah 19:25, 14 November 2008 (UTC)
2011510613
http://cac-dev.omnihotels.com:3000/reservation?property=AUSCTR&id=2011510613
AUSCTR. According to PMS history this was cancelled and then re-instated 10 minutes later. But according to Omni CRS history, the reinstatement never arrived. So CRS was still status="X", so what I sent was correct according to the Omni CRS data. --Jhannah 19:25, 14 November 2008 (UTC)
RevData.AUSCTR.20081029.xml:<res bktime="20081028104903" cas="N" doa="20081118" evt="notevent" exprrev="352.00" gcnt="1" grp="13600106599" gtd="Y" id="2011510613" inlos="2" intime="" los="2" off="notoffer" outtime="" rcnt="1" rt="DELUXE" seg="06" src="AUSCTR-PH" st="X" time="20081028144257" xltime="20081028144101"/> RevData.AUSCTR.20081108.xml:<res bktime="20081028104903" cas="N" doa="20081118" evt="notevent" exprrev="352.00" gcnt="1" grp="13600106599" gtd="Y" id="2011510613" inlos="2" intime="" los="2" off="notoffer" outtime="" rcnt="1" rt="DELUXE" seg="06" src="AUSCTR-PH" st="X" time="20081028144257" xltime="20081028144101"/>
2011530884
Missing from Opera. Reservation was modified 14 times. I did send st="X" to Rainmaker on Nov 6. --Jhannah 19:28, 14 November 2008 (UTC)
RevData.AUSCTR.20081103.xml:<res bktime="20081102115453" cas="N" doa="20081105" evt="notevent" exprrev="119.00" gcnt="1" gtd="Y" id="2011530884" inlos="1" intime="" los="1" off="notoffer" outtime="" rcnt="1" rt="DELUXE" seg="07" src="OMNIREZ-UA" st="F" time="20081102115453" xltime=""/> RevData.AUSCTR.20081105.xml:<res bktime="20081102115453" cas="N" doa="20081105" evt="notevent" exprrev="119.00" gcnt="1" gtd="Y" id="2011530884" inlos="1" intime="" los="1" off="notoffer" outtime="" rcnt="1" rt="DELUXE" seg="07" src="OMNIREZ-UA" st="F" time="20081104103120" xltime=""/> RevData.AUSCTR.20081106.xml:<res bktime="20081102115453" cas="N" doa="20081105" evt="notevent" exprrev="119.00" gcnt="1" gtd="Y" id="2011530884" inlos="1" intime="20081105052755" los="1" off="notoffer" outtime="" rcnt="1" rt="DELUXE" seg="07" src="OMNIREZ-UA" st="X" time="20081105114653" xltime="20081105114512"/>
2011571029
I sent st="X" to Revolution, so I don't see a problem here. --Jhannah 19:28, 14 November 2008 (UTC)
RevData.AUSCTR.20081113.xml:<res bktime="20081112092119" cas="N" doa="20081225" evt="notevent" exprrev="458.00" gcnt="2" gtd="Y" id="2011571029" inlos="2" intime="" los="2" off="notoffer" outtime="" rcnt="1" rt="DELUXE" seg="04" src="DALCOR-PH" st="X" time="20081112095510" xltime="20081112095520"/>
RT6833
From: Talbot, Sophia
281201 has an alternate id so is not a test booking – 10100752308 need to further investigate why you don’t have it. = Shelly or Jay can you take a look as to why these are not in the export? As they seem like really valid bookings.
294249 alternate id of 10100752308
http://cac-dev.omnihotels.com:3000/reservation?property=DALLBJ&id=10100752308&fast=on
Looks like I sent it to Revolution 4 times:
RevData.DALLBJ.20081025.xml:<res bktime="20081024222437" cas="N" doa="20081024" evt="notevent" exprrev="238.00" gcnt="3" gtd="Y" id="10100752308" inlos="2" intime="20081024222213" los="2" off="notoffer" outtime="" rcnt="1" rt="DELUXE" seg="06" src="DALLBJ-PH" st="I" time="20081024222520" xltime=""/> RevData.DALLBJ.20081026.xml:<res bktime="20081024222437" cas="N" doa="20081024" evt="notevent" exprrev="238.00" gcnt="3" gtd="Y" id="10100752308" inlos="2" intime="20081024222213" los="2" off="notoffer" outtime="" rcnt="1" rt="DELUXE" seg="06" src="DALLBJ-PH" st="I" time="20081025094409" xltime=""/> RevData.DALLBJ.20081027.xml:<res actorev1="30.80" actrrev="238.00" bktime="20081024222437" cas="N" doa="20081024" evt="notevent" exprrev="238.00" gcnt="3" gtd="Y" id="10100752308" inlos="2" intime="20081024222213" los="2" off="notoffer" outtime="20081026105340" rcnt="1" rt="DELUXE" seg="06" src="DALLBJ-PH" st="O" time="20081026110042" xltime=""/> RevData.DALLBJ.20081028.xml:<res actorev1="30.80" actrrev="238.00" bktime="20081024222437" cas="N" doa="20081024" evt="notevent" exprrev="238.00" gcnt="3" gtd="Y" id="10100752308" inlos="2" intime="20081024222213" los="2" off="notoffer" outtime="20081026105340" rcnt="1" rt="DELUXE" seg="06" src="DALLBJ-PH" st="O" time="20081026110042" xltime=""/>
370303 alternate id of 2011578356
http://cac-dev.omnihotels.com:3000/reservation?property=DALLBJ&id=2011578356&fast=on
Sent once:
RevData.DALLBJ.20081114.xml:<res bktime="20081113142242" cas="N" doa="20081129" evt="notevent" exprrev="109.00" gcnt="2" gtd="Y" id="2011578356" inlos="1" intime="" los="1" off="notoffer" outtime="" rcnt="1" rt="DELUXE" seg="04" src="OMNIREZ-PH" st="F" time="20081113142242" xltime=""/>
Shares, Multiname
From: Michael Rothwell
Sent: Mon 11/17/2008 4:21 PM
Subject: RE: Topics for Today's Weekly Call at 12:00 Noon EST
Enclosed are the notes Mukund and I took on the call today. If you have any changes/questions
let us know.
...
c) Sharers and Multi name handling
Action : Jay to send scenarios on how the current extract is handling Sharer scenarios
(Sharer records which are separate reservation records with unique confirmation numbers and
Multi-name which is one record with a single confirmation# with multiple names)
...
Multiname
--Jhannah 15:42, 18 November 2008 (UTC)
In Omni CRS and epitome PMS a single payer is always responsible for a single reservation, which has a single confirmation number. "Multiname" refers to the fact that any reservation can have an arbitrary number of additional names attached to the reservation. Those names are used for lookup purposes only, and have no effect on billing. Since Revolution doesn't want guest names, that fact that a reservation may be multiname has no bearing on the Rev 1.5 extracts.
For example, reservation # 2011579989 has 4 guest names attached to it. But in the extract I only send one record:
datamining@omares-etl:/datamining/hrms2/SENT> grep 2011579989 *.ATLCNN.20081118.xml <res bktime="20081113172856" cas="N" doa="20081113" evt="notevent" exprrev="828.80" gcnt="4" gtd="Y" id="2011579989" inlos="4" intime="20081113185000" los="4" off="notoffer" outtime="" rcnt="1" rt="DELUXE" seg="02" src="OMNIREZ-EX" st="X" time="20081113193000" xltime="20081113203002"/>
Programmer notes:
select cro_resno, count(*) from resfile_lookup where cro_resno IN ( select cro_resno from resfile_master where prop = 'ATLCNN' and depart_date = '11/17/2008' ) group by 1 order by 2 desc cro_resno (count(*)) 2011579989 4 2011500947 2 2011481825 2 2011481822 2
Shares
--Jhannah 15:42, 18 November 2008 (UTC)
In Omni CRS and epitome PMS any reservation (single confirmation number) can be a share-with with an arbitrary number of other reservations. This indicates that multiple reservations are all holding the same physical room during dates that overlap on at least one night. Each reservation may or may not be partially responsible for payment for the physical room on any given night.
The Rev 1.5 extracts have a field res.rcnt for sending room count. For sharewith reservations I calculate rcnt for each reservation in the share as a fraction <= 1. The number sent is equal to the number of nights that the specific reservation is for divided by the total number of nights that all reservations in the share are holding the physical room.
The math and proof of concept are here: Room Count for Share-with Reservations
In the vast majority of cases, sharewiths are simply 2 people holding the same room for a one or two nights. In those cases, the extracts look like these from this morning (ATLCNN):
datamining@omares-etl:/datamining/hrms2/SENT> grep -v 'rcnt="1"' RevData.ATLCNN.20081118.xml | grep '<res ' <res actrrev="358.00" bktime="20081114151143" cas="N" doa="20081114" evt="notevent" exprrev="358.00" gcnt="1" gtd="Y" id="10800743945" inlos="2" intime="20081114212036" los="2" off="notoffer" outtime="20081116122927" rcnt="0.5" rt="DELUXE" seg="02" src="ATLCNN-PH" st="O" time="20081116113445" xltime=""/> <res actorev1="30.00" actrrev="161.10" bktime="20081009145434" cas="N" doa="20081111" evt="notevent" exprrev="161.10" gcnt="2" gtd="Y" id="2011431119" inlos="1" intime="20081111173406" los="1" off="notoffer" outtime="20081112091029" rcnt="0.5" rt="DELUXE" seg="02" src="OMNIREZ-PH" st="O" time="20081112081717" xltime=""/> <res bktime="20081117184852" cas="N" doa="20081117" evt="notevent" exprrev="900.00" gcnt="1" grp="10800705571" gtd="Y" id="10800744074" inlos="5" intime="20081117194926" los="5" off="notoffer" outtime="" rcnt="0.5" rt="DELUXE" seg="06" src="ATLCNN-PH" st="I" time="20081117185337" xltime=""/> <res bktime="20080827110120" cas="N" doa="20081117" evt="notevent" exprrev="900.00" gcnt="2" grp="10800705571" gtd="Y" id="2011211585" inlos="5" intime="20081117195039" los="5" off="notoffer" outtime="" rcnt="0.5" rt="DELUXE" seg="06" src="OMNIREZ-PH" st="I" time="20081117185337" xltime=""/> <res actorev1="60.00" actrrev="358.00" bktime="20081030133323" cas="N" doa="20081114" evt="notevent" exprrev="358.00" gcnt="3" gtd="Y" id="2011522512" inlos="2" intime="20081114161219" los="2" off="notoffer" outtime="20081116122927" rcnt="0.5" rt="DELUXE" seg="02" src="OMNIREZ-WB" st="O" time="20081116113445" xltime=""/>
But the rcnt can be any long float when there are several people sharing a single room for any strange number of nights. For example, here's a hypothetical sharewith from the link about and the rcnt values I would send:
Day of week: MTWRFSS
res1 xxxxxxx los 7
res2 x los 1
res3 xxx los 3
res4 xx los 2
res5 x los 1
res6 xx los 2
Occupancy: 3332221
res1 rcnt: 0.4375
res2 rcnt: 0.0625
res3 rcnt: 0.1875
res4 rcnt: 0.125
res5 rcnt: 0.0625
res6 rcnt: 0.125
TOTAL rcnt: 1
