Web Portal: Daily Data Entry for retail chain

The chain of gas stations I represent is looking for a more efficient way to manage and administrate the daily books of our various gas station/convenience stores. Currently we use a multi-sheet excel spreadsheet in each of our stations and we are expanding to the point where traveling to each store everyday to check that our managers are putting take care of the books is not feasible. The objective of this project is to convert our current excel spreadsheet into a multi-station, multi-user portal where clerks, managers, owners, and administrators (me) can login to complete the daily "end-of-day" data entry. The following specifications are required: User management - Users should be able to be assigned different roles for different stations. Some managers, manage multiple stations. Clerks should only be able to view the current(previous) day as entered by them. Some owners are owners of some locations, and not others. Flexibility is the key. Reports - Reports should be an available feature. They should be obvious(ish) based on the spreadsheet. End of month totals, ___ to date, graphs. Ex: Merchandise sales, gas (revenue & gallons) sold, total sales, payouts/day, credit card sales... Station Specifics: Users should be able to input the payout's, and payin's for the day. Ex: 6/30/08 Pepsi - $500, and description. It would be nice to be able to upload a copy of the invoice in picture format or pdf, but not required. Some stations are commission sites, and do not purchase their own fuel. The commission formula is apparent from the spreadsheet provided. The percentages vary between sites based on different agreements. These sites do not require input pertaining to margins, and fuel purchase price. Some stations have different fuel options, some do not have diesel, some do. Kerosene... The option to add a fuel type should be available. Some stations have different tank setups. Many have two tanks of regular, and one of premium, and blend them to get midgrade. Point being, some locations may not require a diesel inventory, or midgrade inventory as seen at the bottom of the spreadsheet. In the event of two unleaded tanks, they can be combined into one grade. All stations should be able to upload a copy of the fuel delivery invoice for a certain day, aka "bill of lading". While not common, sometimes loads have have two separate bill of lading's and would need to be able to upload two images. Deliveries may occur every day, but usually every 3-4 days, fyi. Rarely do multiple deliveries happen on the same day, but possible. Consequently, stations that pay for their fuel(non-commission sites) should be able to upload their invoices and input the amount and due date that they must pay their supplier. A field for the supplier name would be helpful. A sample bill of lading and invoice can be provided later. All stations have different shifts. At the end of a shift there is a printout. At the end of the day, there is a shift print out and a daily printout. The shifts add up to the daily. Some stations use a format where they input individual shifts, and some stations just use the daily printout totals for the day. The number of shifts vary by site and by day. 24 hour sites, may have more than others. Banking Section: A section for each individual station to help manage the checkbook would be helpful. Description of the check, check number, amount, and who is is being issued to, and a description box. A way to check off if the check has been deposited. A way to upload a copy of the invoice in picture/pdf format would be helpful. A way to keep track of bank deposits for each site. Someway to the safe drops from each day into this system would be helpful to indicate which days monies have been deposited. A way to add multiple bank accounts to help keep track of the above. Drop down box to choose the account is all that's needed. I am sure I have forgot some minor details that will come to me later on. The jist of it is above. The example provided in the excel is a commission site, the more complicated of the two. Price is flexible. Ruby is preferred, but whatever is cheaper/easier will work. Demo required before payment.