-
Posts
1695 -
Joined
-
Last visited
-
Days Won
75
Content Type
Profiles
Forums
phpVMS Resources
Downloads
Everything posted by ProAvia
-
OK - finally have some uninterrupted time to do this. Between taking the dog to the vet and my grandson being here all day, I've had basically no time. Yes - I will definitely backup the DB. And I will try this on my online test site first (with a separate DB from the live site) also. If I understand correctly, I should: backup the DB, do the replacement in PIREPData.class.php starting at line 1042 see what the results are submit a new PIREP see what the results are again then attempt your last see what happens
-
If you do a schedule search do those flights show up there? http://YourAirlineName/phpvms/index.php/schedules
-
phpVMS 5.5.2 requires the php version of modules. There is a way to convert the tpl versions to php, but for now you may be better off sticking with the already converted ones. Once you have a better feel and understanding of the system, you can try your hand at converting a module. Here's the link to the php version of the events module: https://github.com/DavidJClark/phpVMS-Event-Booking And in looking it over quickly, it appears to have the 'public static function' in the .../core/common/EventsData.class.php file (in place of the 'public static'). After you have the php version of events module installed, I'd suggest you compare all the file of the php version to the tpl version to see the differences. This should give you an idea of how to attempt to convert other tpl module versions to php. Do this by having all files on your local computer and possibly use Notepad++ when comparing the files. When you receive an error like your 3rd one, go to the folder it states and look to see if you have the file mentioned. phpVMS 5.5.2 will look for the .php file extension. So if you have the file name in the correct location, look again at the file extension - most likely you have the .tpl version instead of the .php version if you already have the module installed.
-
There's phpVMS 2.1.x and phpVMS 5.5.x that are publically available - Version 3 is being worked on and hasn't been released yet. Check the bottom right corner of your admin panel or admin panel, 'Site & Settings, General Settings, phpVMS Version' and let us know what exact version. Whether php or tpl version depends on phpVMS version. Have you searched the forums for 'Strict Standards' yet?
-
What version of phpVMS are you using? Probably a good idea to list that in any post asking for assistance. Have you searched the forums for the 'Strict Standards' error? Lots of posts about it. For your first two errors (line 16 and line 17), look in core/common in the EventsData.php file. Are the items listed as 'public function' or 'public static function'? For your third error, that's telling you that the file 'events_index.php' is not in the ... core/templates/events/ folder. Are you using the tpl or php version of the module?
-
Right you are! I hadn't gotten around to looking there. I'll have a go at making the changes you provided above - tomorrow. Again, thank you so much for your efforts and time!
-
1. Yup, on the view pirep page. 2. I was thinking per pilot - showing a a column for date, flight number and pay. I can add more or incorporate into other areas once I know what to call and how to call it. Would this be available for onky the associated pilot to view, as well as admins?
-
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!
-
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!
-
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/'.
-
error RanksData.class.php on line 236 after submit a register
ProAvia replied to ercio's topic in Support Forum
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. -
error RanksData.class.php on line 236 after submit a register
ProAvia replied to ercio's topic in Support Forum
Thanks Kyle!