Administrators ProAvia Posted January 25, 2017 Author Administrators Report Share Posted January 25, 2017 One thing I just noticed in the DB is that a submitted but not accepted PIREP shows a negative balance in revenue which looks to account for fuel cost and pilot pay (based on flighttime). This is before doing any of your edits. Hopefully your edits adjust this for flighttime_stamp when the PIREP is initially entered into the DB by kACARS. Quote Link to comment Share on other sites More sharing options...
web541 Posted January 25, 2017 Report Share Posted January 25, 2017 (edited) uh, there shouldn't be any difference with the flighttime and the flighttime_stamp calculations (as seen previously with the paychecker script and hitting go), but yes it is basically this gross = price (field) * load (field) # this may equal 0 if they're both empty meaning it may already go into the negative revenue = gross (above) - pirep expenses (if you've added any) - fuel price (field) - pilot pay (calculated) So the subtraction of the fuel price and the pilot pay may be why it's going into a negative, but is it consistently in the negative? Edit: oh before the edits, yeah try them and see if they change anything Edited January 25, 2017 by web541 Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted January 25, 2017 Author Administrators Report Share Posted January 25, 2017 (edited) Only differences between live site and test site is I'm using your admin skin on the test site - default on live site. The test DB is an exact copy of the live DB. After edit - no new PIREP View PIREP in original example - no change, as expected Edit PIREP in Admin Panel - didn't change anything, but submitted again. Revenue changed from 22,400.20 (pre-edit) to 22530.40 (post-edit). This seems to have added the 130.20 from pilotpay(flighttime) back in - but not subtracted pilotpay(flighttimestamp). After edit - process existing new (pre-edit) PIREP (via kACARS) Before processing (in admin and viewreport) - revenue of -19,164.50, fuel cost (26504#) of 18923.90 (which doesn't equal my 0.68/# fuel cost) After processing (in admin) - revenue of 16,777.28, fuel cost (26504#) of 18,022.72 (equals my 0.68/# fuel cost), gross of 34,800.00 (174 pax @ $200 each) After processing (in viewreport) - revenue of 16,777.30, others same as #2 above Subtracting gross - fuelcost = revenue. Nothing left for pilot pay After edit - process new submitted (post-edit) PIREP (manual - submitted with exact same PIREP info as pre-edit above) Before processing (in admin) - revenue of -18,923.90, fuel cost of 18,923.90 (which doesn't equal my 0.68/# fuel cost) (in viewreport) - revenue of -18,923.90, fuel cost of 18,022.72 (which equals my 0.68/# fuel cost) After processing (in admin) (DETAILS tab) - revenue of 16,777.30, (fuel used 26504#), gross of 34,800.00 (174 pax @ $200 each) (EDIT tab) - revenue of 16,777.30, fuel cost of 18,022.70 (26504#), gross of 16,777.30 (174 pax @ $200 each) After processing (in viewreport) - revenue 16,777.30, fuel cost of 18,022.70 (26504#), gross of 34,800.00 (174 pax @ $200 each) Subtracting gross - fuelcost = revenue in #3. Nothing left for pilot pay. Don't know what's going on with gross between #2 and #3 The differences in the admin DETAILS versus EDIT could be the admin skin - but maybe not. Anyway, I'm stopping for the evening. The wife wants my attention now. Tomorrow I'll replace the admin skin with the default and see what that does (if anything). Edited January 25, 2017 by ProAvia Quote Link to comment Share on other sites More sharing options...
web541 Posted January 25, 2017 Report Share Posted January 25, 2017 I don't think my admin skin will have any difference as I've just installed it, connected it to the same DB and it seems to output the same results each time (both in the details tab and on the edit page) and if I do remember, I only copied the information from the default templates and skinned them, so there shouldn't be any difference. Also, did you run my "Recalculate Revenue" script on the test site by ay chance? I'll just post what I think is going on, but I'll need you to confirm these as there seems to be a lot of odd things happening recently. After you made the edit, it changed an old PIREP's revenue, this seems odd (unless the function is being called, though I believe it is stored in the DB, could be wrong though) but it still added the wrong amount (as stated in your above posts, 130.2) to the revenue. After edit - process existing new (pre-edit) PIREP (via kACARS) This one has corrected the revenue, but it doesn't subtract the pilot pay (or it goes into a negative?) After edit - process new submitted (post-edit) PIREP (manual - submitted with exact same PIREP info as pre-edit above) The one has corrected the revenue, but for some reason the fuel cost is a bit off in the admin panel (edit page or details tab), but it's right in the main site's view report? <= Before Processing After Processing though, the fuel price has fixed itself, but the gross has suddenly dropped just under half for that PIREP and only in the edit section? Can I get you to check the following In the PIREPS table in your DB, can you find the two PIREP's which you've submitted and post the following values for each load fuel used fuelunitcost fuelprice price gross expenses revenue That should verify which data is correct. Also, I've pushed some changes to the PayChecker to allow you to view the correct revenue for each PIREP, or at least from the values in the DB. I've also noticed that if your gross and expenses are both 0, the revenue will be a negative, even when subtracting the pay (for obvious reasons, starting at 0). Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted January 26, 2017 Author Administrators Report Share Posted January 26, 2017 (edited) On 1/25/2017 at 3:51 PM, web541 said: I don't think my admin skin will have any difference as I've just installed it, connected it to the same DB and it seems to output the same results each time (both in the details tab and on the edit page) and if I do remember, I only copied the information from the default templates and skinned them, so there shouldn't be any difference. Also, did you run my "Recalculate Revenue" script on the test site by ay chance? Found it.... Look in admin/templates/pirep_edit.php, line 151. It's calling revenue instead of gross - so that explains the DETAILS vs. EDIT in Admin Panel. BTW - love the admin skin!! No, I haven't run "Recalculate Revenue" yet. I stopped after doing the initial edit and saw the pilotpay not being deducted from revenue. Thought it best to not confuse myself further by adding the script to the mix. On 1/25/2017 at 3:51 PM, web541 said: After you made the edit, it changed an old PIREP's revenue, this seems odd (unless the function is being called, though I believe it is stored in the DB, could be wrong though) but it still added the wrong amount (as stated in your above posts, 130.2) to the revenue. No - I viewed an old accepted PIREP to see if anything changed. Then clicked EDIT, didn't change anything, then SUBMIT. I think it ran it through the recalculate section and added back the 130.20 pilotpay(flighttime). On 1/25/2017 at 3:51 PM, web541 said: After edit - process existing new (pre-edit) PIREP (via kACARS) This one has corrected the revenue, but it doesn't subtract the pilot pay (or it goes into a negative?) This was a PIREP that was submitted before the edit, but processed/accepted after the edit. Before accepting pirep admin & viewreport - revenue = -19164.50 / fuel = 18923.90 --- diff of -240.60, which is pilotpay(flighttime) --- 4.01 * 60 After accepting pirep admin DETAILS - revenue = 16777.30 / fuel = 26504# used / gross = 34800.00 admin EDIT - revenue = 16777.30 / fuel = 18022.70 / gross = 16777.30 --- see note about admin skin above viewreport - revenue = 16777.30 / fuel = 18022.70 / gross = 34800.00 gross - fuel = revenue --- doesn't subtract pilotpay at all in ledger table - amount = 241.00 --- this is pilotpay(flighttime_stamp) On 1/25/2017 at 3:51 PM, web541 said: After edit - process new submitted (post-edit) PIREP (manual - submitted with exact same PIREP info as pre-edit above) The one has corrected the revenue, but for some reason the fuel cost is a bit off in the admin panel (edit page or details tab), but it's right in the main site's view report? <= Before Processing After Processing though, the fuel price has fixed itself, but the gross has suddenly dropped just under half for that PIREP and only in the edit section? This was a new manual PIREP - submitted and processed/accepted after the edit using same data as PIREP above (flight time, load, fuelused, fuelprice, price, pilotpay/hr) Before accepting pirep admin - revenue = -18923.90 / fuel = 18923.90 --- fuel equals revenue, no pilotpay at all (but fuel price is incorrect for 0.68/# * 26504#) viewreport - revenue = -18923.90 / fuel = 18022.70 --- fuel price is correct, no idea where the 901.20 diff comes from After accepting pirep admin DETAILS - revenue = 16777.30 / fuel = 26504# used / gross = 34800.00 admin EDIT - revenue = 16777.30 / fuel = 18022.70 / gross = 16777.30 --- fuel correct --- see note about admin skin above viewreport - revenue = 16777.30 / fuel = 18022.70 / gross = 34800.00 --- fuel correct gross - fuel = revenue --- doesn't subtract pilotpay at all (difference in #2 and #3 gross is admin skin) in ledger table - amount = 241.00 --- this is pilotpay(flighttime_stamp) On 1/25/2017 at 3:51 PM, web541 said: Can I get you to check the following In the PIREPS table in your DB, can you find the two PIREP's which you've submitted and post the following values for each load fuel used fuelunitcost fuelprice price gross expenses revenue That should verify which data is correct. Also, I've pushed some changes to the PayChecker to allow you to view the correct revenue for each PIREP, or at least from the values in the DB. 174 - 174 26504 - 26504 0.68 - 0.68 18022.7 - 18022.7 200 - 200 34800 - 34800 0 - 0 16777.3 - 16777.3 So both pireps show the same - whether submitted before or after the edit. Both were processed/accepted after the edit. Does the single decimal place have to do with table Structure being 'float' and that item having a trailing zero? And why the differences in revenue & fuelprice in various areas? My mind is a blur after trying not to screw up these numbers and this post. Taking a dinner break. Back in a while. Edited January 27, 2017 by ProAvia spelling Quote Link to comment Share on other sites More sharing options...
web541 Posted January 26, 2017 Report Share Posted January 26, 2017 (edited) 1 hour ago, ProAvia said: Found it.... Look in admin/templates/pirep_eidt.php, line 151. It's calling revenue instead of gross Ah ok, yeah I saw that, but I guess it's another phpVMS encounter when they call it "Gross Revenue" 1 hour ago, ProAvia said: No - I viewed an old accepted PIREP to see if anything changed. Then clicked EDIT, didn't change anything, then SUBMIT. I think it ran it through the recalculate section and added back the 130.20 pilotpay(flighttime). Yeah, I think that it only recalculates the revenue for PIREPS that are filed after the change as there isn't a recalculation once accepted, but my "Recalculate Revenue" script should hopefully fix the revenue on the PIREPS which were filed before this change. 1 hour ago, ProAvia said: gross - fuel = revenue --- doesn't subtract pilotpay at all in ledger table - amount = 241.00 --- this is pilotpay(flighttime_stamp) As stated above, your fix will only apply to the PIREPS submitted after the edit has been made. 1 hour ago, ProAvia said: viewreport - revenue = -18923.90 / fuel = 18022.70 --- fuel price is correct, no idea where the 901.20 diff comes from I believe this is calculating the Gross Revenue using the algorithm below (in the admin panel fix section of this post) <tr> <td align="right">Gross Revenue: <br /> (<?php echo $pirep->load;?> load / <?php echo FinanceData::FormatMoney($pirep->price);?> per unit <br /> <td align="right" valign="top"><?php echo FinanceData::FormatMoney($pirep->load * $pirep->price);?></td> </tr> As for the admin skin issue with the gross, etc., it appears you've found yet another phpVMS bug, and I've patched it on my admin skin. I'll prove it, the algorithm is this $gross = $data['price'] * $data['load']; And on the page, it clearly states Change the load and price variables above to adjust this value. So basically yeah, just change $pirep->revenue to $pirep->gross and it should display the correct value this time. This issue is default within phpVMS as well. It's not the total revenue either as that is displayed in another field below. +1 to you. 1 hour ago, ProAvia said: So both pireps show the same - whether submitted before or after the edit. Both were processed/accepted after the edit. Does the single decimal place have to do with table Structure being 'float' and that item having a trailing zero? And why the differences in revenue & fuelprice in various areas? Not sure which 'single decimal place' or 'trailing zero' you are talking about (please confirm), but it shouldn't have anything to do with the structure being 'float' as 'float' allows the database to hold x amount of integers between a range, and they are able to be a negative number. The differences between the revenue values were hopefully explained above, but the fuelprice intrigues me as it should only be pulling the one value out of the DB. And for the revenue not subtracting the pilot pay, I'll have a look for you, but it seems to work fine on my end. EDIT: PilotPay issue should be fixed if you run the 'Recalculate Revenue' function in my PayChecker script above, I just tried it with various calculations and it seemed to deduct the pay properly. $gross = 100 * 157 = 15700 $pay = (18 / 60) [0.3] * 63 = 18.90 $revenue = 15700 - 0 - 29088.4 - 18.90 = -13,407.3 Total Revenue = -$13, 407.30 And that's what I got Edited January 26, 2017 by web541 Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted January 26, 2017 Author Administrators Report Share Posted January 26, 2017 (edited) On 1/25/2017 at 7:34 PM, web541 said: Ah ok, yeah I saw that, but I guess it's another phpVMS encounter when they call it "Gross Revenue" Nothing like trying to confuse me more. Gross Revenue = gross --- Net Revenue = revenue On 1/25/2017 at 7:34 PM, web541 said: Yeah, I think that it only recalculates the revenue for PIREPS that are filed after the change as there isn't a recalculation once accepted, but my "Recalculate Revenue" script should hopefully fix the revenue on the PIREPS which were filed before this change. I think it will recalculate IF you choose to edit a specific pirep. On 1/25/2017 at 7:34 PM, web541 said: As stated above, your fix will only apply to the PIREPS submitted after the edit has been made. But as it is now, it's not calculating and/or subtracting pilotpay at all. Shouldn't the edit account for pilotpay - hopefully pilotpay(flighttime_stamp) ?? On 1/25/2017 at 7:34 PM, web541 said: I believe this is calculating the Gross Revenue using the algorithm below (in the admin panel fix section of this post) load * price = gross --- how many pax times the amount per pax On 1/25/2017 at 7:34 PM, web541 said: And on the page, it clearly states Change the load and price variables above to adjust this value. I think that means if you want a higher gross, then change the load and/or price to a higher number. On 1/25/2017 at 7:34 PM, web541 said: On 1/25/2017 at 6:30 PM, ProAvia said: So both pireps show the same - whether submitted before or after the edit. Both were processed/accepted after the edit. Does the single decimal place have to do with table Structure being 'float' and that item having a trailing zero? And why the differences in revenue & fuelprice in various areas? Not sure which 'single decimal place' or 'trailing zero' you are talking about (please confirm), but it shouldn't have anything to do with the structure being 'float' as 'float' allows the database to hold x amount of integers between a range, and they are able to be a negative number. The differences between the revenue values were hopefully explained above, but the fuelprice intrigues me as it should only be pulling the one value out of the DB. And for the revenue not subtracting the pilot pay, I'll have a look for you, but it seems to work fine on my end. I'm referring to a number such as 50.40 being displayed as 50.4 - it's dropping the zero after the .4 - like Excel does in a cell if you don't have it set to use two decimal places. I guess 'float' might drop trailing zeros. The fuelprice is an odd one. And while the ledger 'amount' for pilotpay is correct, the pireps table and/or the calculations isn't taking it into account. It's all as clear as mud!! LOL So, what do you want me to try next? Edited January 27, 2017 by ProAvia Quote Link to comment Share on other sites More sharing options...
web541 Posted January 26, 2017 Report Share Posted January 26, 2017 (edited) 44 minutes ago, ProAvia said: I'm referring to a number such as 50.40 being displayed as 50.4 - it's dropping the zero after the .4 - like Excel does in a cell if you don't have it set to use two decimal places. I guess 'float' might drop trailing zeros. I just tested it and you were right, entered a 5.10 value into phpmyadmin and it rejected the 0, but I'm not sure it's because it's a float value. 44 minutes ago, ProAvia said: The fuelprice is an odd one. And while the ledger 'amount' for pilotpay is, the pireps table and/or the calculations isn't taking it into account. It's all as clear as mud!! LOL Where exactly is the fuel price different (on which page(s))? As far as what to do next, well I think that the revenue is basically finished calculating now, except that for what you're telling me, it's not subtracting the pilot pay from the revenue. Are you able to install my PayChecker module on your test site (just updated it to include more info) and then go to "View PIREPS for pilot..." and check the values of the Revenue Column. That will calculate it internally (real) but also calculate it again (PIREP) using values from the DB and see if it's missing anything. Edited January 26, 2017 by web541 Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted January 26, 2017 Author Administrators Report Share Posted January 26, 2017 2 hours ago, ProAvia said: This was a new manual PIREP - submitted and processed/accepted after the edit using same data at PIREP above (flight time, load, fuelused, fuelprice, price, pilotpay/hr) Before accepting pirep admin - revenue = -18923.90 / fuel = 18923.90 --- fuel equals revenue, no pilotpay at all (but fuel price is incorrect for 0.68/# * 26504#) viewreport - revenue = -18923.90 / fuel = 18022.70 --- fuel price is correct, no idea where the 901.20 diff comes from After accepting pirep admin DETAILS - revenue = 16777.30 / fuel = 26504# used / gross = 34800.00 admin EDIT - revenue = 16777.30 / fuel = 18022.70 / gross = 16777.30 --- fuel correct --- see note about admin skin above viewreport - revenue = 16777.30 / fuel = 18022.70 / gross = 34800.00 --- fuel correct gross - fuel = revenue --- doesn't subtract pilotpay at all (difference in #2 and #3 gross is admin skin) in ledger table - amount = 241.00 --- this is pilotpay(flighttime_stamp) In 1.1 above - admin - the fuelprice shows as 18923.90, it should be 18022.70 based on fuelused and fuelunitcost. I figured out why it's showing a different fuelprice. It uses the FUEL_DEFAULT_PRICE times FUEL_SURCHARGE. FUEL_DEFAULT_PRICE (set in local.config) = fuelunitcost --- I think this is fuel price at a hub airport maybe FUEL_SURCHARGE (set in local.config) = percent surcharge added to FUEL_DEFAULT_PRICE Proof - my prices/percentage --- fuelunitprice = 0.68 / surcharge = 5% --- makes fuel price 0.741 ---- 0.741 * 26504# = 18923.856 --- rounded to 18923.9 After the pirep is edited and/or accepted, it uses the 0.68 fuelunitcost. This particular flight was from a hub airport - I need time to check what happens from a non-hub airport. Yeah - it's not subtracting the pilotpay. And I'd like it to subtract pilotpay(flighttime_stamp) instead of the original pilotpay(flighttime). I'll install the updated PayChecker and report back shortly. Quote Link to comment Share on other sites More sharing options...
web541 Posted January 26, 2017 Report Share Posted January 26, 2017 11 minutes ago, ProAvia said: Yeah - it's not subtracting the pilotpay. And I'd like it to subtract pilotpay(flighttime_stamp) instead of the original pilotpay(flighttime). Really, it should give the same results (if the conversion is done right as I have shown before in the original PayChecker), but if you're looking to do it anyway, then go back into the edit you did in the PIREPData.class.php and find this $flighttime = explode('.', $data['flighttime']); # split the flighttime into two parts And replace it with this $flighttime = explode(':', $data['flighttime_stamp']); # split the flighttime_stamp into two parts and the rest should work out fine, either way it is just splitting the value into a few pieces flighttime = 02.17 flighttime_stamp = 02:17:00 Then it will become flighttime = 0217 flighttime_stamp = 021700 <= the last 2 (sec) 00 cancel out because phpVMS doesn't report in seconds, so it ends up being like this 0217 like the above flighttime, the rest is just a matter of converting it properly. Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted January 26, 2017 Author Administrators Report Share Posted January 26, 2017 (edited) PayChecker Pilot Side PIREPData => CalculatePIREPPayment 241 PilotData => resetPilotPay 11254.50 Current Pilot's Payrate (per hour) 60 New Algorithm Using Decimal Form 241 New Algorithm Using Flight Stamp Form 241 What you are getting now (I think) 240.6 Revenue For This PIREP 16536.3 PayChecker Admin Side PIREPData => CalculatePIREPPayment 241 PilotData => resetPilotPay 11254.50 Current Pilot's Payrate (per hour) 60 New Algorithm Using Decimal Form 241 New Algorithm Using Flight Stamp Form 241 What you are getting now (I think) 240.6 Revenue For This PIREP 16536.3 1 hour ago, web541 said: then go to "View PIREPS for pilot..." and check the values of the Revenue Column. That will calculate it internally (real) but also calculate it again (PIREP) using values from the DB and see if it's missing anything. In admin, and view that particular pilot's pireps??? (.../admin/index.php/pilotadmin/viewpilots?action=viewoptions&pilotid=22) --- there is no revenue column. If I choose edit, it shows 'Total Revenue for flight' of 16777.30 . Adding 'Total Revenue for fligh't and 'Total fuel cost', it equals 'Gross Revenue'. 16777.30+18022.70=34800.00 While the pilotpay is showing in the ledger table (as amount), it's not being subtracted from revenue. This is after the pirep has been accepted. I even clicked EDIT and SUBMIT again to see if that changed anything. I'm going to look in PIREPData.class.php again and make sure I have that correct. EDIT: I didn't try the Reset Revenue or Reset Pay + Revenue, only the Go!..... with the correct pirepid Edited January 26, 2017 by ProAvia Quote Link to comment Share on other sites More sharing options...
web541 Posted January 26, 2017 Report Share Posted January 26, 2017 Nope I mean admin/index.php/PayChecker/viewPIREPS , choose a pilot and then click View PIREPS 2 minutes ago, ProAvia said: I'm going to look in PIREPData.class.php again and make sure I have that correct. If you find anything, let me know, this could be interesting. Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted January 26, 2017 Author Administrators Report Share Posted January 26, 2017 Oh - 'Check PIREPS' under Tasks in the sidebar......, then the pilot in question, View PIREPS. 1 Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted January 26, 2017 Author Administrators Report Share Posted January 26, 2017 It shows his Last PIREP Pay = $241.00, Last PIREP Real Pay = $241.00 Viewing the particular PIREP in question PIREP Gross: 34800 Actual Gross: 34800 Expenses: 0 Fuel Price: $ 18, 022.70 Pilot Pay: $ 241.00 Actual Revenue: $ 16, 536.30 PIREP Revenue: $ 16, 777.30 Why the discrepancy between the last two entries? Quote Link to comment Share on other sites More sharing options...
web541 Posted January 26, 2017 Report Share Posted January 26, 2017 Finally might be onto something, The 'Actual Revenue' shows my calculations which are taken place on the page itself using values from the PIREP table The 'PIREP Revenue' shows phpVMS's calculations which are taken place internally, most likely by the PIREPData.class.php getPIREPRevenue function and for some reason, it is not subtracting the pay (might've copied the lines incorrectly) To prove that the 'Actual Revenue' is true, you go to the 'PIREP Revenue' and subtract the pilot's pay for the flight ($241) and you should get the 'Actual Revenue' if I'm not mistaken. 16, 777.30 - 241 (pilotpay) = 16, 536.30 <= check that to see if it's correct. Confirm this theory with another PIREP. If you're game, you can go back to the index page of the PayChecker and select 'Recalculate Revenue', go back to the 'View Pilot's PIREP's' page and they both should have the same (I hope) correct values. Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted January 26, 2017 Author Administrators Report Share Posted January 26, 2017 (edited) 21 minutes ago, web541 said: 16, 777.30 - 241 (pilotpay) = 16, 536.30 <= check that to see if it's correct Yup - correct! Confirm with another 3 PIREPS 'Reset Revenue' - PIREP Gross: 34800 Actual Gross: 34800 Expenses: 0 Fuel Price: $ 18, 022.70 Pilot Pay: $ 241.00 Actual Revenue: $ 16, 536.30 PIREP Revenue: $ 16, 536.30 So the pay isn't being subtracted "somewhere" to give the correct 'revenue' - if I understand you correctly. And 'Reset Revenue' only did the calc internally and didn't seem to change anything in the DB. I'm done for tonight - but tomorrow, I can easily blow the DB out and set it back to where it was before messing with PayChecker and Reset Revenue if needed. Computer is going off now - but will be on tablet to check forum. No, I won't even attempt to mess with the site files/DB from the tablet cause I'll fat finger something and mess it all up. Thanks again! Edited January 26, 2017 by ProAvia Cause I can't spell Quote Link to comment Share on other sites More sharing options...
web541 Posted January 26, 2017 Report Share Posted January 26, 2017 (edited) 17 minutes ago, ProAvia said: I'm done for tonight - but tomorrow, I can easily blow the DB out and set it back to where it was before messing with PayChecker and Reset Revenue if needed. Computer is going off now - but will be on tablet to check forum. No, I won't even attempt to mess with the site files/DB from the tablet cause I'll fat finger something and mess it all up. No problem, 'Reset Revenue' does update the revenue in the DB for all PIREPS to match what it actually is supposed to do, when you can (later), can you upload your PIREPData.class.php so I can take a look, just to make sure you haven't accidentally made the wrong adjustment, because after a made the change, I filed a few PIREPS and they seemed to update straight away. EDIT: Nevermind actually, I'll take another look, it seems that now I'm getting the incorrect revenue as well, the same as above. Yeah, something's messing with the pay EDIT-2: Also figured out that it only happens when I accept the PIREP, when it is submitted, the revenue is calculated correctly. Edited January 26, 2017 by web541 Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted January 26, 2017 Author Administrators Report Share Posted January 26, 2017 OK - happy to know it's not just me! Also glad I figured out why my fuel cost changed - although I'm not sure the FUEL_SURCHARGE is fully implemented.... But that's for another time - or maybe I don't really want to know. Quote Link to comment Share on other sites More sharing options...
web541 Posted January 26, 2017 Report Share Posted January 26, 2017 (edited) Still don't know for sure why this is happening (couldn't trace down an error, dead ends...), but I managed to find a fix (not a great one, but it works). In PIREPData.class.php around line 1226, find this self::calculatePIREPPayment($pirepid); Replace it with this self::calculatePIREPPayment($pirepid, true); Then on the calculatePIREPPayment function around line 1256, replace it with this public static function calculatePIREPPayment($pirepid, $update_revenue = false) { $pirep = DB::get_row( 'SELECT `pirepid`, `pilotid`, `flighttime_stamp`, `pilotpay`, `paytype`, `flighttype`, `accepted` FROM `'.TABLE_PREFIX.'pireps` WHERE `pirepid`='.$pirepid ); if($pirep->accepted == PIREP_REJECTED) { return false; } if($pirep->paytype == PILOT_PAY_HOURLY) { $pilot = PilotData::getPilotData($data['pilotid']); # Get the pilot info for payrate in case pay field is changed later $flighttime = explode('.', $data['flighttime']); # split the flighttime into two parts $flighttime_min = ($flighttime[0] * 60) + ($flighttime[1]); # Calculate no. minutes $pilotpay = ($pilot->payrate / 60) * $flighttime_min; # Finalise the payment // This was the original // Only multiplies payrate (pay field) by the flight time without taking into account the minutes / 60 but min. / 100 # $pilotpay = $data['pilotpay'] * $data['flighttime']; } elseif($pirep->paytype == PILOT_PAY_SCHEDULE) { $amount = $pirep->pilotpay; } $params = array( 'pirepid' => $pirepid, 'pilotid' => $pirep->pilotid, 'paysource' => PAYSOURCE_PIREP, 'paytype' => $pirep->paytype, 'amount' => $amount, ); $entry = LedgerData::getPaymentByPIREP($pirepid); if(!$entry) { LedgerData::addPayment($params); } else { LedgerData::editPayment($entry->id, $params); } PilotData::resetPilotPay($pirep->pilotid); if($update_revenue === true) { $pirep = self::getReportDetails($pirepid); $payment_type = PILOT_PAY_HOURLY; $revenue = self::getPIREPRevenue(json_decode(json_encode($pirep), true), $payment_type); $fields = array('revenue' => $revenue); self::editPIREPFields($pirepid, $fields); } return $amount; } And that will force it to recalculate the revenue of the PIREP whenever it is accepted (any other time, it will be ignored). I did narrow the potential cause of this issue, if you file a PIREP, the edit you did to the PIREPData.class.php a few posts back would have worked, but only until you accepted the PIREP (not even rejected, just accepted), and then I narrowed it down to the PIREPData.class.php line where it recalculates the payment, but I still don't know where it's overriding the revenue. Let me know if this works for you. Edited January 29, 2017 by web541 Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted January 28, 2017 Author Administrators Report Share Posted January 28, 2017 Sorry - life got in the way of trying this. Just need an uninterrupted block of time to wrap my head around it again. Hoping to tackle over the weekend. Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted January 28, 2017 Author Administrators Report Share Posted January 28, 2017 (edited) On 1/25/2017 at 8:28 PM, web541 said: On 1/25/2017 at 8:16 PM, ProAvia said: I'm referring to a number such as 50.40 being displayed as 50.4 - it's dropping the zero after the .4 - like Excel does in a cell if you don't have it set to use two decimal places. I guess 'float' might drop trailing zeros. I just tested it and you were right, entered a 5.10 value into phpmyadmin and it rejected the 0, but I'm not sure it's because it's a float value. I just tested this - in a DB table 'Type' column if set to FLOAT it drops any trailing zeros (floating-point) if set to DECIMAL and Length/Values is set to x,2 (where 'x' is a number of how many digits to left of '.' and '2' is how many digits to right of '.' you want to display) it will display 2 decimal places to the right of '.' (fixed-point). Note: there is a comma ( , ) between the two numbers in Lengths/Values. You can display more than two decimal places if desired. It's also explained in more detail in the MySQL documentation. This may be something that can be incorporated in version 3 to better display any DB entries that have to do with money (at least for those of us who use it that way). Guess there may be instances in some countries where a single decimal place works with their currency. Edited January 28, 2017 by ProAvia Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted January 28, 2017 Author Administrators Report Share Posted January 28, 2017 On 1/25/2017 at 11:47 PM, web541 said: I did narrow the potential cause of this issue, if you file a PIREP, the edit you did to the PIREPData.class.php a few posts back would have worked, but only until you accepted the PIREP (not even rejected, just accepted), and then I narrowed it down to the PIREPData.class.php line where it recalculates the payment, but I still don't know where it's overriding the revenue. And leave the first edit in or put it back to original? (see first edit below) Quote Go to PIREPData.class.php line 1042 and between the if statement (the one with if($payment_type == PILOT_PAY_HOURLY) {) on it replace it's content with this $pilot = PilotData::getPilotData($data['pilotid']); # Get the pilot info for payrate in case pay field is changed later $flighttime = explode('.', $data['flighttime']); # split the flighttime into two parts $flighttime_min = ($flighttime[0] * 60) + ($flighttime[1]); # Calculate no. minutes $pilotpay = ($pilot->payrate / 60) * $flighttime_min; # Finalise the payment // This was the original // Only multiplies payrate (pay field) by the flight time without taking into account the minutes / 60 but min. / 100 # $pilotpay = $data['pilotpay'] * $data['flighttime']; Quote Link to comment Share on other sites More sharing options...
web541 Posted January 29, 2017 Report Share Posted January 29, 2017 (edited) 7 hours ago, ProAvia said: I just tested this - in a DB table 'Type' column if set to FLOAT it drops any trailing zeros (floating-point) if set to DECIMAL and Length/Values is set to x,2 (where 'x' is a number of how many digits to left of '.' and '2' is how many digits to right of '.' you want to display) it will display 2 decimal places to the right of '.' (fixed-point). Note: there is a comma ( , ) between the two numbers in Lengths/Values. You can display more than two decimal places if desired. It's also explained in more detail in the MySQL documentation. This may be something that can be incorporated in version 3 to better display any DB entries that have to do with money (at least for those of us who use it that way). Guess there may be instances in some countries where a single decimal place works with their currency. Noted. 7 hours ago, ProAvia said: And leave the first edit in or put it back to original? (see first edit below) Should be able to leave it in, but it shouldn't matter as you are just replacing the function here and it should override whatever you've already got. Edit: Literally just got what you meant, updated the post, it should work. Edited January 29, 2017 by web541 Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted January 31, 2017 Author Administrators Report Share Posted January 31, 2017 (edited) Update: Adding in the last code seems to fix it once you Accept PIREP from the Edit page - except if you change the pilot's pay rate using the Edit function. This is with a PIREP submitted and accepted AFTER the file changes. Ledger table shows correct pilotpay - as it did before. Still need to check PIREPS submitted prior to file changes - if I edit and accept again. Additionally, using the Save PIREP option does not change revenue to correct amount. This is with a newly submitted PIREP or one submitted before the file changes. Same flight - only difference was initial pilotpay @ $40/hr. Prior to accepting PIREP, changed pilot pay to $60/hr. PayChecker gave following results. PIREPData => CalculatePIREPPayment 241 This amount equals the entry in the Ledger table PilotData => resetPilotPay 1348.99 Haven't checked this yet Current Pilot's Payrate (per hour) 40 This is the pay based on pilot's rank New Algorithm Using Decimal Form 160.666666667 This is the pay based on rank times hours.minutes New Algorithm Using Flight Stamp Form 160.666666667 This is pay based on rank time hours:minutes What you are getting now (I think) 160.4 This is what I was getting before the file changes Revenue For This PIREP 16616.6333333 This is the correct revenue - based on pay by rank 4.01 = 4 hours 1 minute = 241 minutes __________________________________________________________________ ($60/hr / 60) * 241 = $241 ($40/hr / 60) * 241 = $160.666666667 As you can see, revenue is now taking pilotpay into account. But, if you change pilotpay via admin PIREP edit, it doesn't apply the new pilotpay to the calculation. DB shows pilotpay = 60, revenue = 16777.3 Here's the Admin Paychecker, Check PIREPS, View PIREPS for the same pirep id. #ID DepICAO ArrICAO A/C Flighttime Date Submitted Status Last PIREP Pay Last PIREP Real Pay FA1038 KMDW KLAS B737-800 (N138FA) 4.01 01/30/2017 Accepted $ 241.00 $ 160.67 Revenue PIREP Gross: 34800 Actual Gross: 34800 Expenses: 0 Fuel Price: $ 18, 022.70 Pilot Pay: $ 241.00 Actual Revenue: $ 16, 536.30 PIREP Revenue: $ 16, 777.30 Actual Revenue is correct and calculated on pilotpay $60/hr. PIREP Revenue is NOT taking ANY pilotpay into account. I think the mud is turning into quicksand! Edited January 31, 2017 by ProAvia Quote Link to comment Share on other sites More sharing options...
web541 Posted January 31, 2017 Report Share Posted January 31, 2017 PIREPData.class.php Around line 855, find this (in the updateFlightReport function at the bottom) self::calculatePIREPPayment($pirepid); And replace it with this self::calculatePIREPPayment($pirepid, true); See if that fixes anything, pretty sure it has something to do with this in the updateFlightReport function # Recalculate finances if these fields are set... if($recalc_finances === true) { $data = array( 'price' => $pirepdata['price'], 'load' => $pirepdata['load'], 'expenses' => $pirepdata['expenses'], 'fuelprice' => $pirepdata['fuelprice'], 'pilotpay' => $pirepdata['pilotpay'], 'flighttime' => $pirepdata['flighttime'], ); $gross = floatval($pirepdata['load']) * floatval($pirepdata['price']); $revenue = self::getPIREPRevenue($data, $pirepinfo->paytype); $pirepdata = array_merge($pirepdata, array( 'flighttime_stamp' => $flighttime_stamp, 'gross' => $gross, 'revenue' => $revenue, ) ); } Don't have time now to look at it though. Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted February 1, 2017 Author Administrators Report Share Posted February 1, 2017 That corrected the SAVE issue. PayChecker results remained exactly the same. In Admin PayChecker, it's now subtracting pilotpay (based on rank $$ amount only) in PIREP Revenue. So it's subtracting pilotpay now - but the pilotpay based on rank, not the $$/hour I changed it to in EDIT. Database shows pilotpay = 60, revenue = 16616.6 - the revenue is based on pilotpay = 40, not pilotpay = 60. PIREP Gross: 34800 Actual Gross: 34800 Expenses: 0 Fuel Price: $ 18, 022.70 Pilot Pay: $ 241.00 Actual Revenue: $ 16, 536.30 PIREP Revenue: $ 16, 616.60 If I input a different Pilot Pay while editing the PIREP in admin, it doesn't take the new rate into account when recalculating. 34800 - 18022.70 - 16536.30 = 241.00 = 4:01 @ $60/hour = 241 minutes * (60 / 60) = Actual Revenue 34800 - 18022.70 - 16616.60 = 160.70 = 4:01 @ $40/hour = 241 minutes * (40 / 60) = PIREP Revenue No rush - whenever you have a chance to look it over. Always appreciate your help and insight! Quote Link to comment Share on other sites More sharing options...
web541 Posted February 1, 2017 Report Share Posted February 1, 2017 By pilot pay, you mean a new rate per hour? And does this only occur when you edit a PIREP? Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted February 1, 2017 Author Administrators Report Share Posted February 1, 2017 Yes - if I change pilot pay to a new value when editing a PIREP. The pireps table shows the updated pilot pay figure, but it's not being reflected in revenue. Quote Link to comment Share on other sites More sharing options...
Administrators ProAvia Posted February 2, 2017 Author Administrators Report Share Posted February 2, 2017 (edited) I don't know if this is related or not - or even if it's an issue with the processing elsewhere ... line 825 in the original PIREPData.class.php file $pirepdata['flighttime'] = str_replace(':', ',', $pirepdata['flighttime']); I think that statement basically replaces the ' : ' with a ' , ' . Should the 'comma' in - str_replace(':', ',', $pirepdata be a 'period' instead str_replace(':', '.', $pirepdata Seems it's replacing the colon with a comma instead of replacing the colon with a period. I did try changing it and the results I'm seeing didn't change at all. ____________________ I believe my issue is that, when computing revenue, the pilotpay is getting the payrate from the pilot or ranks tables instead of pilotpay from the pireps table. And if I change the pilotpay when editing the PIREP, the new pilotpay isn't taken into account - because it's using pilotpay from $pilot->payrate. But I don't know what to change or where to change it. Edited February 2, 2017 by ProAvia clarification Quote Link to comment Share on other sites More sharing options...
web541 Posted February 2, 2017 Report Share Posted February 2, 2017 2 hours ago, ProAvia said: $pirepdata['flighttime'] = str_replace(':', ',', $pirepdata['flighttime']); Yeah, this is basically useless, can't see a point where this would be used, but it's probably there for a reason, so I'd leave it alone. And yeah, your right, I made the script earlier to get the pilot's payrate instead of the pilotpay from the pireps table in case that field needed to be used in the future, but you should be able to go and change your PIREPData.class.php function from before to this public static function calculatePIREPPayment($pirepid, $update_revenue = false) { $pirep = DB::get_row( 'SELECT `pirepid`, `pilotid`, `flighttime_stamp`, `pilotpay`, `paytype`, `flighttype`, `accepted` FROM `'.TABLE_PREFIX.'pireps` WHERE `pirepid`='.$pirepid ); if($pirep->accepted == PIREP_REJECTED) { return false; } if($pirep->paytype == PILOT_PAY_HOURLY) { # $pilot = PilotData::getPilotData($data['pilotid']); # Get the pilot info for payrate in case pay field is changed later $flighttime = explode('.', $data['flighttime']); # split the flighttime into two parts $flighttime_min = ($flighttime[0] * 60) + ($flighttime[1]); # Calculate no. minutes $pilotpay = ($pirep->pilotpay / 60) * $flighttime_min; # Finalise the payment // This was the original // Only multiplies payrate (pay field) by the flight time without taking into account the minutes / 60 but min. / 100 # $pilotpay = $data['pilotpay'] * $data['flighttime']; } elseif($pirep->paytype == PILOT_PAY_SCHEDULE) { $amount = $pirep->pilotpay; } $params = array( 'pirepid' => $pirepid, 'pilotid' => $pirep->pilotid, 'paysource' => PAYSOURCE_PIREP, 'paytype' => $pirep->paytype, 'amount' => $amount, ); $entry = LedgerData::getPaymentByPIREP($pirepid); if(!$entry) { LedgerData::addPayment($params); } else { LedgerData::editPayment($entry->id, $params); } PilotData::resetPilotPay($pirep->pilotid); if($update_revenue === true) { $pirep = self::getReportDetails($pirepid); $payment_type = PILOT_PAY_HOURLY; $revenue = self::getPIREPRevenue(json_decode(json_encode($pirep), true), $payment_type); $fields = array('revenue' => $revenue); self::editPIREPFields($pirepid, $fields); } return $amount; } And see if that does anything Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.