web541

No, not the default number sorry, the ordering, because it looks for number then length (I think), 0 comes before 1, so theoretically is you have these 10 20 1000 It will become like this currently 10 1000 20 By if you re-route a zero in front of it, it should become like this 0010 0020 1000 etc, so the id matches the length while still keeping the number there, might look silly, but it works.

Another option would be to make a json response from the 'Pilot Module' and check the length of the pilotid, if it's shorter than four, append a zero to it before the number so 996 would be 0996, then 1000, not ideal, but it should work. Then you can re-route datatables to read this.

You could re-arrange the query, or you could just do it the easy way... $last_location = PIREPData::getLastReports($pilotid,1, PIREP_ACCEPTED); $last_location_apt = OperationsData::getAirportInfo($last_location->arricao); $last_location_name = $last_location_apt->name; echo $last_location_name; Haven't tested it, but it should work

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.

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.

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.

Nope I mean admin/index.php/PayChecker/viewPIREPS , choose a pilot and then click View PIREPS If you find anything, let me know, this could be interesting.

Ah, you're using the older version, do you have a skin on your website, if so, try lib/skins/YOURSKINNAME/pilots_list.tpl and replace all the content in there. If that file is not there, then try the one in core/templates/pl/pilot_list.tpl which I think is the one Parkho gave you. No need to be embarrassed, it's just like learning another language, you'll get it eventually And for the error, try replacing this line (on line 8) $pilots = PilotData::findPilots(['code' => $airline->code]); With this one $pilots = PilotData::findPilots(array('code' => $airline->code)); Your PHP version might be very old.

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.

Try putting it in lib/skins/YOURSKINNAME/pilots_list.php and replace all the content with the one Kyle sent above, that should do it!

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. 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.

Ah ok, yeah I saw that, but I guess it's another phpVMS encounter when they call it "Gross Revenue" 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. As stated above, your fix will only apply to the PIREPS submitted after the edit has been made. 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. 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

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).

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

Yep, that should do it.

Ok, I've gone ahead and made the module again (now with extra features) and it should allow you to recalculate all your PIREP's revenue (and Pilot pay if you wish) and allow you to monitor the pay of each PIREP from each pilot. Before you do this, please, please backup your database as I've tested the script multiple times and it seems fine to me, but if it's wrong for you, it might screw up. If you've got a local version of your website handy, I suggest you try this there first before bringing it live. The upside is that it shouldn't delete any data, only update it. Grab the module More details here

Nice Job bass Yes, that API is much better actually. I've amended the module to allow a page to be displayed with all your airports, but check the API rules to see if there is any strain on their servers first before use as it pulls the data every time you reload the page, but bass's idea above should be better because it only pulls the data form one airport at a time, so if you have a hub page or something for each airport, this will also work. VATSIMATC.zip

Care to share your code? I like learning things

disregard

No problem, glad to help.

Alright, shouldn't be a problem then. I can make it that the pilot can see their pay for their flight on their view pireps page as well as an admin page for all pilots and their last pirep (as well as a link to view all other pireps as well)

I found out the issue here, if you look closely at your figures here for fuel cost (11,129.56), but in your database (from the txt file provided) the fuel cost is 11129.6 so it rounded it up before entry into the database, this one is probably to do with your acars client rounding it off as it doesn't go through phpvms I don't think. After the revenue change above, the pilot pay will be adjusted, so these figures are before the change above has been implemented (I'm guessing).

Nope, it won't affect your previous entries, but I will amend my PayChecker script to change this data for you (and possibly recalculate the pilot's pay), but please back up your DB first. Now for your questions The way it is calculated is different (I assume this info will be placed on the view pirep page), use something like this <tr> <td align="right">Pilot Pay: <br /> (per hour based on rank)<br /> <td align="right" valign="top"> <?php echo FinanceData::FormatMoney($pirep->pilotpay * $pirep->flighttime);?> <?php $flighttime = explode('.', $pirep->flighttime); $totalminutes = ($flighttime[0] * 60) + ($flighttime[1]); $pilot = PilotData::getPilotData($pirep->pilotid); // In case the pilotpay value changes in the future $totalpay = ($pilot->payrate / 60) * $totalminutes; return FinanceData::formatMoney($totalpay); ?> </td> </tr> You should be able to view this in edit pirep (admin), but I'll make a table for you to show this, do you want it per pilot or per pirep?

I just had a thought, maybe the revenue is being counted like that on purpose? Anyway, if you want to calculate the pilotpay (to affect the revenue) based on pilot's payrate and correct flighttime (number of minutes instead of the flighttime itself as a decimal form / 100), then here is the fix. 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']; And you should be able to see the calculation affect the revenue with the correct amount as per the ledger table. Once you check this, report back with your results and if they're correct, I'll amend the PayChecker script with a reset revenue function which will allow you to reset all revenue and recalculate it using the new method, without fully resetting the pilot pay itself (unless you want it to do this).

Ok thanks, you should be able to reset it, but I'd do it after as it may recalculate revenue as well which might screw it up further. With this, I just took a look and it seems that it is just multiplying the pilotpay in the pirep (which is the payrate set by phpvms) by the flight time, so I should be able to fix this for you pretty easily with the scripts from the PayChecker confirming your results, just as you thought earlier.