If you have not read tables.txt yet, please start there. INTRODUCTION My vision of this website interface is to create the simplest most friendly professional interface that VOIP providers could use as their billing software. http://billing.sunsaturn.com/?inter_face=local test/test If you look at what is there and have read tables.txt now, you can see what the design was originally thought up as to be as simple as possible. Those little boxes showing a nice background on them, friendly to the eyes, all editing of a DID in the DIDs table all done in a nice easy to look at box. Search function on the top allowing easy navigating, paging so not to many entries are displayed per page. However this project was not completed, and is mising many things, you are more than welcome to build on the existing code, or start from scratch. I willhave to be swayed to give up those little boxes as i think they look great, if you have better design in mind I am more than willing to look at it, but I think that will be hard to beat for simple to use interface. The layout itself I am open to, the current very light blue background makes the boxes pop out at you and very easy to look at. Some work will be needed on this part, but we can always revisit this on finish. I envision people might like a different background occassionally so a place where they can change templates on the fly would be a great added bonus, not every person will share the same vision that a design looks good to them, so leaving options open to them would be great. Keep this in mind when you start wrapping to much code around html on this project especially when doing paging. END INTRODUCTION PAGES admin: (sections of the site) Your welcome to build onto the exiting site. a) local b) longdistance c) my groups d) statistics e) accounts f) imports/exports g) administrator DESCRIPTIONS a) local As you see from what is already in the local section, this is what we are allowing to be editted. Here we have r1 , r2, r3, r1_seconds r2_seconds, and r3_seconds along with rate which was described in tables.txt. That error checking applies here. This section is for parsing the DIDs table and displaying numbers in that table but leaving out the DIDs of type 'longdistance'. Funds is what gets inserted into money_left for that DID. Same with Forwardto, Account NUmber, Route, Bill Minimum and Increment. Discount and Surcharge should be edittable along with Payment Type. If you look at whats already in DIDs table, all this will make sense to you. search function at top for this section allowing the admin to search by phone number for a matching DID. Add function for this page allowing admin to add a completely new entry to the DIDs table. Delete function for allowing deleting of a row in the DIDs table on a search match. Default should be to bring up first 20 rows in that table when going to this section. b) longdistance This is for displaying the longdistance table. Pretty much same layout as the DIDs table except only the listed fields in those boxes from http://billing.sunsaturn.com/?inter_face=longdistance are used here. Search function should be able to search by Country or dialcode on this page. Results should be done with paging as it currently is. Local search function should be removed from this page. Mass update function should allow a mass update on entire longdistance table for selected fields. This mass update is not simply a insert into that field for the one selected. It is used to add or subtract from current rates. ie: If i have all different rates in my longdistance table, let says dialcode 1204 has a rate of .02 and 1604 has a rate of .03 , i should be able to add .01 to mass update rate box, and after the update 1204 is now 0.03 and 1604 is now .04. Currently the layout and design of it looks pretty gimped, need to fix this up and make sure its more clear whats happening here. Add function to add a new entry to longdistance table is needed. Delete function to delete a row from longdistance table. This should always confirm if they want to delete it, anything to do with deletes should confirm to the enduser to make sure they want to do this. The boxes should be further edittable with Country name and Dialcode by clicking on some advanced edit button. Be easier to just make it ediitable in the first place, but I beleive that would destroy the look. c) my groups. This section was never finished it seems but the intent of it was so we could group dialcodes together from longdistance table and be able to do a mass update on one field. Not adding or subtracting , but taking the exact input here and applying it to all fields. So lets say i group all of Canada's dialcodes together, I should be able to update the rate for all those dialcodes to .02 for example on the fly. A nice looking attempt was attempted with this with javascript , but its severely flawed, if I go to add a group the way it is now, it works, but if i switch letters to add a new one, my original selections are not there anymore. Very disturbing, finish this javascript code if possible or build a redo the section completely. The intent of this section was to allow grouping of dialcodes in the longdistance and tollfree tables for mass updates to fields for those dialcodes. d) Statistics, this by far should be where your design talent shines. Use gd or libjpeg and display pie, line or bar charts utilizing the data contained in traffic_$year table. $year means this current year. Each of these tables has already 365 entries in them for everyday of the year, the module itself updates fields for that day of the year, your only job is to display them You should be displaying as much information as possible. Total calls for the day, week, month, year, or a selectable date range. Admin should be able to bring up stats for the day and see how many calls where made in a certain hour if he likes etc. This tool is invaluable, and will be used by people every single day to view stats. In VOIP its important to average out how many calls a day/hour are happening especially so he knows to add new systems etc. This is stats for admin section keep in mind, for user logins we will actually be parsing cdr_$month instead for their accountcode. We will be taking screenshots of this page to put on website so make it look good! The way it was made here with a calendar was a great concept, build onto it if possible. Insert fake numbers into the rows and make sure everything displays properly. What would be really nice here, lets take pie chart for example and I select a date range of jan 1st to jan 7th, it displays pie charts for every one of those days with paging if date range is long. e) accounts This section is for editting user accounts. Our master tables are DIDs sip and iax for this. When adding a new account, you must keep track of a unique accountcode across these 3 tables to use for the new user. SO lets say we used 30002 for last accountcode, lets make sure we are using 30003 for next use we add. To add a new user we are simply adding rows to those 3 tables. Since template was never done for this, we'll go over it together as you are working on it more, but what to insert into those tables was covered in tables.txt and those are the fields we will allow editting of for adding new users. Let the admin specify if he wants to add to the sip and iax tables or just one of them + the DIDs table. Deleting accounts: again make sure to confirm before allowing this. Basically nuke all entries in iax, sip and DIDs tables with their accountcode. This section will be gone over with me, code must be clean here, your to approach me on this section when design and a basic code implementation is doing inserts into the 3 tables, then we'll go over it. If anything leave this one till last. f) imports/exports: this section is for importing rates from other providers into different tables. Here is an example list: http://www.voipjet.com/voipjet30dec05.txt We should be able to delete everything in the longdistance table and import this list directly into longdistance table if we so wish. My suggestion on this is an upload button that takes a file like this , parses on a delimiter, and inserts into appropriate fields. Make it clear to end user how import is done, Country, dialcode, rate, bill minimum, bill increment for example. Those are about only fields providers give so thats all we need to worry about. More flexible you make this , the better. We should also allow an import on tollfree table as well. exporting: allow a complete export of longdistance or tollfree tables. This is great way to check import code after. Export a text file to end users desktop, he reuploads it to the server, all should insert properly. g) administrator as you may guess, all the flexibility in your code and webdesign shows up here. We need to allow changing of passwords for admin login and users. Possible template changes to the design here, maybe someone wants it in red background or yellow instead Paypal IPN, here is where admin should be able to put his paypal account info to use when normal users login and want to pay to add minutes. Default: bring up a list of current User accounts on the page PAGES user: (sections of the site) normal user login. a) call detail records(default page for that month) We will have to 'wing' this section as they say for a good layout... but here is what i want in it: Display their calls for the month using their accountcode and the cdr_$month table. Keep in mind if a context is type 'forward' or 'tollfree_forward' please refer to tables.txt for the way to display those. SOme nice looking graphs in the section would do wonders as well. Remember our objective in this section is to display their calls they made and allow them to add funds to their account, very simple. After we have displaying calls code and design done, we build in paypal IPN here. Anytime they have added confirmed funds to their account, you are to add that amount to money_left fields everywhere in DIDs table that contains their accountcode. Pricing plan is pretty simple, allow editting of that in administrator of admin login section of how many amounts to to let enduser have and what amount. IE: paypal 5 dollars, 10 dollars, 20, 50, 100 and 250 dollars. The user section should parse this table as to what option to allow the user to pay with. If you have extensive experience with many different payment processors, we may add those in as well, but paypal is our main focus. Need to build an invoicing system along with the cdr_$month tables. Users should be able to download an invoice of how much they were charged for their calls for that month. I think best way to do this is build your search functions to display call detail records by month, and just have a invoice button that allows a downloadable format of their calls for the month and how much they got billed for each call. -------------------------------------------- This is our very basic billing system, once this is done we will need to test all the code making sure error checking was done. Test all buttons and functions for accuracy, I will help with this, make final touchups and we are done version 1.0. From here on you'll be on contract assignments to add new features to our core code whenever i add new features to the module itself. It will never take you as long as building the core did, just to addon more pages and features to the webinterface. Everything I;ve described is of a mandatory state for needed functionality. If you will never have the time to ever work on this project again after the core, ie: open up 4-8 hours every so often , maybe couple times a month or months, then please allow someone with a more flexible schedule. I think its a reasonable expectation if you build something of this nature, that bug fixes and new functionality will always be needed on it. For communication, we will communicate by MSN time to time and phone for initial contact, and email for majority of the time your working on this project afterwards. You should work very well independantly and have a flair for getting things done on time. Dan.