Jump to content

ProAvia

Administrators
  • Posts

    1640
  • Joined

  • Last visited

  • Days Won

    70

Everything posted by ProAvia

  1. 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.
  2. What version of phpVMS are you using - 2.1.x or 5.5.x? If the later, change the .tpl to .php in the core_htmlhead file name above and see if that helps. If that doesn't work, maybe posting the contents of your layout.php or template_start.php would help someone diagnose the issue.
  3. 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.
  4. 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!
  5. I messed with the width and was able to set it to 100% and to 80% with no change in the button display. Then I went to datatables.net and started playing around with their download options. I am using a NON-bootstrap skin - and I think that may have been part of my issue. I changed this: <link rel="stylesheet" type="text/css" href="https://cdn.datatables.net/1.10.12/css/dataTables.bootstrap.min.css"/> To this: <link rel="stylesheet"String type="text/css"String href="https://cdn.datatables.net/v/dt/jq-2.2.4/dt-1.10.13/b-1.2.4/datatables.min.css"String/> And now, while I still have the words at the bottom, they run horizontally rather than vertically. Here's the line right after closing script </script>: <table id="schedules" class="table" width="80%" align="center"> ---- aligns table center @ 80% width, which looks better then aligned left @ full width on my particular template. I'll be playing around with the other options at datatables.net to see if I can get the buttons to show.
  6. 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.
  7. The pic was using 'FrontSchedules'. But i checked via 'schedules' and it is full width, with the same issues mentioned. Thanks for the reply! I will have a closer look tomorrow and try your suggestions. Worst case, I try it on a new install with all default files and default skin. EDIT: In thinking about it a bit more, both FrontSchedules and schedules uses the same template file to display the search results. I wonder why schedules displays full width and FrontSchedules doesn't.
  8. The 'X' in the search box does seem to work for me - as long as the focus is on the box. Yeah - I've got to do a LOT more reading over there to get a better understanding of the options.
  9. I believe I am using CDN scripts - just not sure I have all the ones I need. Besides the 2 calls shown in the file contents, are there others I need? Not using a bootstrap skin. The Show and Search boxes don't line up horizontally either. Contents of schedule_results.php <?php if(!defined('IN_PHPVMS') && IN_PHPVMS !== true) { die(); } ?> <?php if(!$schedule_list) { echo '<p align="center">No routes have been found!</p>'; return; } ?> <!-- <table id="tabledlist" class="tablesorter"> --> <link rel="stylesheet" type="text/css" href="https://cdn.datatables.net/1.10.12/css/dataTables.bootstrap.min.css"/> <script type="text/javascript" src="https://cdn.datatables.net/v/bs/jq-2.2.3/dt-1.10.12/datatables.min.js"></script> <script type="text/javascript"> $(document).ready(function() { $('#schedules').dataTable({ "sPaginationType": "full_numbers", "lengthMenu": [ [5, 10, 20, 50, -1], [5, 10, 20, 50, "All"] ] }); }); </script> <table id="schedules" class="table"> <thead> <tr> <th>Flight Info</th> <th>Options</th> </tr> </thead> <tbody> <?php foreach($schedule_list as $schedule) { ?> <tr> <td> <a href="<?php echo url('/schedules/details/'.$schedule->id);?>"><?php echo $schedule->code . $schedule->flightnum?> <?php echo '('.$schedule->depicao.' - '.$schedule->arricao.')'?> </a> <br /> <strong>Departure: </strong><?php echo $schedule->deptime;?> &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <strong>Arrival: </strong><?php echo $schedule->arrtime;?><br /> <strong>Equipment: </strong><?php echo $schedule->aircraft; ?> (<?php echo $schedule->registration;?>) <strong>Distance: </strong><?php echo round($schedule->distance . Config::Get('UNITS'), 1);?> <br /> <strong>Days Flown: </strong><?php echo Util::GetDaysCompact($schedule->daysofweek); ?><br /> <?php echo ($schedule->route=='') ? '' : '<strong>Route: </strong>'.$schedule->route.'<br />' ?> <?php echo ($schedule->notes=='') ? '' : '<strong>Notes: </strong>'.html_entity_decode($schedule->notes).'<br />' ?> <?php # Note: this will only show if the above code to # skip the schedule is commented out if($schedule->bidid != 0) { echo 'This route has been bid on'; } ?> </td> <td nowrap> <a href="<?php echo url('/schedules/details/'.$schedule->id);?>">View Details</a><br /> <a href="<?php echo url('/schedules/brief/'.$schedule->id);?>">Pilot Brief</a><br /> <?php # Don't allow overlapping bids and a bid exists if(Config::Get('DISABLE_SCHED_ON_BID') == true && $schedule->bidid != 0) { ?> <a id="<?php echo $schedule->id; ?>" class="addbid" href="<?php echo actionurl('/schedules/addbid/?id='.$schedule->id);?>">Add to Bid</a> <?php } else { if(Auth::LoggedIn()) { ?> <a id="<?php echo $schedule->id; ?>" class="addbid" href="<?php echo url('/schedules/addbid');?>">Add to Bid</a> <?php } } ?> </td> </tr> <?php /* END OF ONE TABLE ROW */ } ?> </tbody> </table> <hr> Thanks!
  10. That code works great! And I just started reading about all the options that are available. I have the code working in Schedules and View PIREPS. One issue I'm having is the placement of the First, Previous, Next, Last and page selection numbers. Right now they show in a vertical column on the lower right side of each paginated page. Is there a way to move them and possible style them into buttons? Thanks!
  11. And leave the first edit in or put it back to original? (see first edit below)
  12. 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.
  13. 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.
  14. 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.
  15. 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!
  16. 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?
  17. Oh - 'Check PIREPS' under Tasks in the sidebar......, then the pilot in question, View PIREPS.
  18. 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 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
  19. 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.
  20. Nothing like trying to confuse me more. Gross Revenue = gross --- Net Revenue = revenue I think it will recalculate IF you choose to edit a specific pirep. 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) ?? load * price = gross --- how many pax times the amount per pax I think that means if you want a higher gross, then change the load and/or price to a higher number. 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?
  21. I think (not absolutely sure) for #3 it needs to be Charter Flight for it to show in the Charter Center. My basic understanding is the module looks for the 'H' so it knows to list it in the Charter Center. Hope someone with more knowledge comes along with an answer for that.
  22. 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. 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). 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) 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) 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.
  23. Are you adding the charters using the 'Create a New Charter' button in Charter Center, or are you adding them to the database another way? Is the main airline name the same for the Charter Center? In other words, is the 'code' the same? Go to the Admin Panel, under 'Airline Operations', 'Flight Schedules & Routes', find one of your added charter flights and click the EDIT button. Look under 'Fight Type' - does it say Passenger Flight, Cargo Flight or Charter Flight? It should say Charter Flight - as this placed the letter 'H' in the 'flighttype' field of the database.
  24. So, the routes show in a schedule search, but not in Charter Center? Or has the issue resolved itself?
  25. You're welcome! I do hope you take my suggestion to review both the php and tpl version. That will go a long way in helping you to understand the errors you may get in the future with other modules and give insight into the workings of the system.
×
×
  • Create New...