ProAvia

Thinking about that again, I think it just slipped through the cracks. In the example I gave the data for the flight was: Gross Revenue: (187 load / $ 180.00 per unit) $ 33, 660.00 Fuel Cost: (16367 lbs fuel used @ 0.68 / lb) $ 11, 129.56 Net Revenue: (after all expenses) $ 22, 400.20 Which leave $130.24 - of which pilotpay(flighttime) was $130.20. I'll assume the 4 cents was for rounding somewhere. But the pilotpay(flighttime_stamp) was $137.00. So the revenue as reported is a higher dollar value that the actual ending dollar value giving pilotpay @ $137.00 Jeez - I'm really glad I didn't go into accounting!

Quite possibly - or it just slipped through the cracks over the years. Maybe it's to adjust for the big virtual bucks the management gets paid. Will this update the revenue column in pireps for previous entries too? Hmm, I'll back up the DB before I attempt. Will have to wait until tomorrow though. Thanks for all your time and effort with this. I really do appreciate it! Hard to believe I started this thread asking about the flight time separator (period vs colon) and morphed to pilotpay only to find that's correct and the revenue was off. I do have two more questions, if I may - While I NOW know that the way I tried calling Pilot Pay below is incorrect, how do I call it? I tried substituting flighttime_stamp for flighttime, but that gave me pilotpay based on the hour and dropped the minutes. So 02:37 was computed as 2 hours. Is there a way for pilots and admins to see how much a pilot has been paid for a PIREP and a total pay somewhere? I'd like to provide a table with that data for pilots/admins to review. <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);?></td> </tr> Thanks!!

I just checked, for all months prior to January 2017, Pilot Pay column shows $0.00. This is from when we switched over to phpVMS in May of 2014 through December 2016.

I checked random ledger amounts and compared to PIREP. The pilot pay appears correct. The revenue column is all positive - except for a couple random negative entries. Not enough that it should have anything to do with the 0 issue in admin. Here's that report. I converted over in January of this year. Month Flights Revenue Pilot Pay Expenses Fuel Total 2016-10 2 $ 25, 300.00 $ 0.00 $ 0.00 ($ -9, 570.32) $ 15, 729.68 2016-11 8 $ 164, 100.00 $ 0.00 $ 0.00 ($ -40, 284.56) $ 123, 815.44 2016-12 3 $ 75, 300.00 $ 0.00 $ 0.00 ($ -20, 744.08) $ 54, 555.92 2017-01 19 $ 346, 750.00 ($ -123, 709.70) $ 0.00 ($ -125, 454.56) $ 97, 585.74 Total: $ 291, 686.78 My guess is that the addition of the ledger table caused this. There's probably not a method to compute the data correctly for prior to conversion. That's why the 0 entries and negative hit on conversion. It should all balance out in the end though.

Not necessarily MORE than expected. And it may not affect actual credited pay to the pilot. All ranks with differing payrates. I used the rank @ $60/hour to make the math easier. ... Yes - but may only be using this in revenue computation Yes - this amount is shown in ledger table Yes - as per 3.2 above - $137 PayChecker.php results PIREPData => CalculatePIREPPayment 137 PilotData => resetPilotPay 10642.50 New Algorithm Using Decimal Form 137 New Algorithm Using Flight Stamp Form 137 What you are getting now (I think) 130.2 Here's what I think is happening: Net revenue is being determined using flighttime method of pilotpay. Net revenue = revenue in the pireps table. Now: gross - fuelprice - expenses - pilotpay(flighttime) = revenue Should be: gross - fuelprice - expenses - pilotpay(flighttime_stamp) = revenue Pilot pay for given PIREP is being determined using flighttime_stamp method of pilotpay. This is what shows correctly in the ledger table. This all started when I added the following to pilot_viewreport.php to display via 'pireps/viewreport'. And I can see now that I am calling Pilot Pay incorrectly. But, this lead to finding that Net Revenue is being computed incorrectly. <table class="balancesheet" cellpadding="0" cellspacing="0" width="100%"> <tr class="balancesheet_header"> <td align="" colspan="2">Flight Details</td> </tr> <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> <tr> <td align="right">Fuel Cost: <br /> (<?php echo $pirep->fuelused;?> lbs fuel used @ <?php echo $pirep->fuelunitcost?> / lb)<br /> <td align="right" valign="top"><?php echo FinanceData::FormatMoney($pirep->fuelused * $pirep->fuelunitcost);?></td> </tr> <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);?></td> </tr> <tr> <td align="right">Net Revenue: <br /> (after <u>all</u> expenses)<br /> <td align="right" valign="top"><?php echo FinanceData::FormatMoney($pirep->revenue);?></td> </tr> </table> So, it appears that revenue is not correct as it's computed using flighttime instead of flighttime_stamp. And if that's the case, I guess pilotpay is correct. If this is what is occurring, is there an easy fix for the revenue computation? At this point, I don't really care if it will be retroactive - but moving forward, I'd like it to be correct.

Your 3 links for PilotData.class.php are for version 2.1.x showing the pilot pay calculations? As for PIREPData.class.php, for getPILOTRevenue, lines 841, 1009 and 1038. 841 - Update a specific PIREP, recalculate finances - references '$pirepinfo->paytype' and looks to be using '$flighttime_stamp' 1009 - Populate PIREP with financial info, Set the pilotpay here - references '$payment_type' as in pay per schedule or per hour. But right above this line references 'flighttime' 1038 - Calculate gross revenue of PIREP - references '$payment_type = PILOT_PAY_HOURLY'. But again references 'flighttime' three lines later. This section returns '$revenue', as in net revenue. Lines 1249-1290 looks to actually calculate the pilot payment, uses 'flighttime_stamp', and enters that into the ledger table. Lines 1009 and 1038 might be where my issue originates. For now, I'm going to ignore the large negative number and assume the version 2.1.x calculations were correct. But am willing to look at it at a later time. Thanks!

Thanks for the affirmation on the "lines". Yeah, I over-simplified line 8, but the end result is the same. The text file is just to list what shows in the tables. The ledger table shows the correct pilot payment. The pirep table only shows pilotpay rate, not amount of pilotpay for that flight. However, given your 2., 1. PIREPData.class.php GetPIREPRevenue, it seems that net revenue is not calculated correctly - or maybe just not displayed correctly. And that's how I am determining the supposed 'error' - subtracting fuel cost, expenses and net revenue from gross revenue to see what the pilot pay is. Then comparing that number to what's reported in the ledger. That's where I'm seeing the difference. In version 2.1.936, I don't recall a ledger table - but need to look closer when I get home later. If it's true there was no ledger table, where was that data located? I don't care if the finances are incorrect prior to moving to 5.5.2. But moving forward, I'd like them to be correct. Additionally, after moving to 5.5.2, I noticed that 'Financial Reports' in admin shows 0.00 Pilot Pay for all months prior to conversion month. And a large negative number for pilot pay in the conversion to 5.5.2 month. I'm guessing the large negative number is accounting for all pilot pay prior to the conversion to 5.5.2. I'll look at the PIREPData.class.php file in detail later today also. Thanks!

Thanks for posting your solution. While I'd bet there are very few like you with 'core' elsewhere, it's good to know there is a way to make it work anyway.

Yes, $60/hour - nothing in "payforflight" field The multiplication is correct - if I were looking for hours and tenths. But I am looking for hours and minutes. $60 x 2.17=$130.20 - and - $60x2:17=$137.00 Thanks, I will review that. My issue is with the minutes conversion. I will have to compare my files with those on GitHub to be sure I didn't muck mine up in some way. In the 'ledger' table the pay amount is correct. I wonder where the incorrect amount in my example above is being pulled from? Hmm, more research needed. A few questions if I may - so I can understand this a bit better..... I numbered the lines to hopefully make it easier 1 - // This would usually be dynamic 2 - $pirep->flighttime_stamp = "02:00:00"; 3 - $pirep->pilotpay = "18"; // Sets it to the payrate as phpvms does, will have to override later 4 - // Do the conversion 5 - $peices = explode(':', $pirep->flighttime_stamp); // 021700 6 - $minutes = ($peices[0] * 60) + $peices[1]; // 137mins 7 - /* Pretty sure this is the cause */ 8 - $amount = $minutes * ($pirep->pilotpay / 60); // 0.3 9 - /* The above is basically 137 X (18 / 60) = 0.3 */ 10 - echo $amount; // $41.1 Line 5 - converts the flighttime_stamp from 02:17:00 to 021700 in the example? Line 6 - converts to minutes - $peices[0] = 02 (hours), $peices[1] = 17 (minutes) and the seconds are disgarded? Line 8 - takes the minutes from line 6 and multiplies by (pilotpay/60) - so minutes times pay/minute? Line 10 - shows total pay for 2:17 flight at $18/hour? Since the ledger table amounts are correct - at least since I converted to 5.5.2, I have to believe them. I need to find where the dollar amount I am seeing is being drawn from. Here's to hoping version 3 only has one pay conversion point! Thanks! EDIT: Added file attachment showing discrepancy. Pilot Pay Discrepancy.txt

Maybe a picture of the screen after you add the second charter would help. Does it still list the first charter? Does the second charter appear in the list or does it not allow you to add the second charter? As for limiting each pilot to a maximum of 5 charter flights each month, it may be best to make that a rule/policy and monitor it manually. If a pilot submits more than 5 in a calendar month, send them a note reminding them of the policy and then delete or reject their PIREP.

Now I'm noticing the pilot pay per hour computation for the flight time is messed up. Pilot pay / hour - $60 Flight time - 2.17 (flighttime) 2:17:00 (flighttime_stamp) Total pay for this flight - $130.20 So in the above example, the pilot makes $1 for every minute ($60/hour) - TIMES - 137 minutes (2 hours 17 minutes) - EQUALS - $137.00 (should be). The $130.20 paid is based on 2.17 hours(approx. 2 hours 10 minutes - 2 and 17/100 hours), not 2:17 hours (2 hours 17 minutes - 2 and 17/60 hours). While this example doesn't show a big discrepancy in dollar value, it's still an error. I don't know where to look to try to fix it. I believe the issue is the number after the decimal is being divided by 100 instead of 60. In my example above - 17/100 instead of 17/60. I am not sure if this same issue (x/100 versus x/60) is affecting the flight time calculation between kACARS and phpVMS - I don't presently have enough conclusive data, as the kACARS log totals usually equal - but not always - the flight time shown in the 'pireps' table. It's not that I mind virtually paying the pilots a little less, but I know one of them will eventually catch this. LOL - Hopefully there's an easy fix.... or at least it can be incorporated into version 3. Any and all help is appreciated!

Nice! Looking forward to see the solution.

This is just a wild a$$ guess - In '/core/codon.config.php', comment out the 'define ('SITE_ROOT.........' line. Below it, enter: define ('SITE_ROOT', str_replace('phpvms/core', 'phpvms', dirname(__FILE__))); OR define ('SITE_ROOT', str_replace('phpvms'DS.'core', 'phpvms', dirname(__FILE__))); OR Some other combination of the above. I have absolutely NO CLUE if this will work, but may be worth a try.

Certainly weird. My intent on a new install was to be sure we were all on the same page... virgin, unedited install. The errors you see on the check install page are very similar to what I saw on mine. I think the check install routine and/or the checksums aren't up to date - not in your install, just that they were never updated. See the reference to '.tpl' files? I think you're right about the 'coreyand' and 'core' issue. Hopefully someone with more knowlege comes along soon with a possible solution.

Certainly strange..... I'm assuming all your VA stuff is going to be under '.../flight/'. If that's the case, try a totally new install of phpVMS and place all the files/folders in '...flight/phpvms/'. create a new DB and install. Don't change anything or copy anything from the present 'errored' install until after you report back here. List any errors, etc you may get. Maybe we can get a clue from there. I'm not sure putting phpVMS in the 'phpvms' folder will solve anything, but may be worth a try. Is there anything else in the '.../flght/' folder other than phpVMS files/folders? EDIT: Verify the default 'crystal' skin is located in '.../lib/skins/' - NOT '.../core/lib/skins/'.

What is the base url set to in local.config.php? What directory is phpvms (the actual phpvms files) installed in - /flight, /flight/core, /flight/phpvms, or??

Deleting ActivityData.class.php isn't going to alleviate the error. RanksData.class.php appears to be calling "ActivityData". So you have 2 options. Either download a new RanksData.class.php for version 2.1.x that doesn't have the call - or - comment out the entire section in your current RanksData.class.php file referencing that call. Maybe grab the complete file contents from here: https://github.com/nabeelio/phpVMS/blob/master/core/common/RanksData.class.php If you decide on the second option, post lines 230-260 so someone here can help make sure you are commenting out all of the suspect lines. In either case, make a backup of the original file. Then replace the file or contents and test it out.

Thanks Kyle!

My old 2.1.936 - installed 4/2014 - doesn't have an ActivityData.class.php. My new 5.5.2 install does have that file. I didn't think 2.1.936 came with that file - but I've been wrong before. Maybe someone can verify if the ActivityData.class.php file was in version 2. I believe the error you posted is saying that the ActivityData.class.php file is not present - or maybe not in the correct path. In any case, you may want to consider upgrading the the new version 3 once it's released. That should rectify the issue.

What version of phpVMS are you using? In /core/common - do you have an ActivityData.class.php file?

kACARS version must match. Your version of kACARS is 1.0.1.0 Your VA requires version 1.0.1.1 Go to fs-products, download and install kACARS version 1.0.1.1

Thank you! Yup, had read through a few posts about it - including that one. Guess I'll add it a little at a time and see if it breaks anything.

My conversion from 2.1.x to 5.5.2 is mostly complete - I'm just trying to clean up a few items. What is the purpose of following statement? - <?php if(!defined('IN_PHPVMS') && IN_PHPVMS !== true) { die(); } ?> I see it in all the 5.5.2 default template folder php files and those of some updated Modules template files. I think it has something to do with security and/or theft of file content. Am I close? If I'm using any modules or custom template file from my 2.1.x install, should I add the statement to the top of all of those template files? Including those in my skins folder? Including those in 'admin/templates'? Should it be in any other files elsewhere in the install? Are there any downsides to including it in the older modules? (I guess worst case is the 'blank page' issue I read about??) Anything else I should know about this? Thanks! Really appreciated all the help I've gotten here and for you all putting up with my (mostly) newbie questions! I've really learned quite a bit through the conversion '"experience".

Restricted rank - yup, that'll do it! You can use the same DB with all the original records in it. I did this - after tweaking my new 5.5.2 install to my needs. I probably made it harder on myself than necessary in the process of all this, but I took my 5.5.2 install live last night and everything appears to work as it should. Using the original DB allowed me to keep all data from the 2.1.x install. Of course, I installed 5.5.2 on the side and tweaked/tested it with all the modules I use first. Then I converted over on my live site, so the pilots weren't waiting for me to finish. Took me several weeks in my spare time. Was a pain, but very do-able with the outstanding help I received from members here.

I think there is a URL issue. In each notice or warning it shows on the --- First line: /home/yand/public....... Second line: /home/coreyand/public..... What's the base URL set to in local.config.php? As Servetas stated, a url to your site may be useful.