Re: Access Web Application

Hi Ariel,

Thank you very much for the detailed scenario specifics.

I have some follow-up questions for you.

Concerning this:

Our produce operation will only ever have about 600 item records, but our
entire database with all of our items is getting close to 30,000.

When you say "entire database" does the 30,000 records come from all tables or would at least one
table have 30,000 records? If one table has 30,000 records, about how many records are you adding in
during a month's time?

Concerning this:

I envision them using it mostly on the Network where they are working. The
web access part could be mostly, or all for viewing data, although I'd like
it to be interactive. There would be about 3 - 5 people using it all the
time, and up to 50 that would view the data regularly. The 3 - 5 would be
entering data into the app.

You said you'd like the web part to also be interactive. Would it still be only about 3-5 people
adding/editing/deleting records or would that increase to the 50 you mentioned?

Concerning this:
VI. Application to be Accessible via the Internet.
a. Final Stage to be implemented when all error handling is apparently
complete.
b. Provide user interface accessible over the internet. Logins would be
user specific, some allowing updates, while others only allowing viewing and
printing of report data.

Would the Logins be all internal or from external sources such as vendors as well?

Thanks for your time,
--
Jeff Conrad - Access Junkie - MVP Alumni
SDET - XAS Services - Microsoft Corporation

Co-author - Microsoft Office Access 2007 Inside Out
Presenter - Microsoft Access 2007 Essentials
http://www.accessmvp.com/JConrad/accessjunkie.html
Access 2007 Info: http://www.AccessJunkie.com

----------
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.mspx
----------

"Ariel Dugan" wrote in message:
news:B01A65CA-C3B4-4272-AB97-B59470C53739@xxxxxxxxxxxxxxxx

Hi Jeff,

Thanks for your reply, I look forward to your insights.

We currently have all of our records in an SQL Data Base. (We're a natural
foods retailer, but the way, so these records are for our point of sale
system.)

I just wrote out my statement of purpose today, so I'll paste it below.
Perhaps a bit too much info, maybe you would only want to read the header
section.

Our produce operation will only ever have about 600 item records, but our
entire database with all of our items is getting close to 30,000.

I envision them using it mostly on the Network where they are working. The
web access part could be mostly, or all for viewing data, although I'd like
it to be interactive. There would be about 3 - 5 people using it all the
time, and up to 50 that would view the data regularly. The 3 - 5 would be
entering data into the app.


Access Data Base Statement of Purpose

I. Facilitate Produce / Other Dept Ordering.
II. Facilitate Produce Price changes.
III. Provide Delivery Documentation
IV. Track Purchases and Invoice Payment
V. Weekly Reporting of all Shipping and Billing Data.
VI. Application to be Accessible via the Internet.


I. Facilitate Ordering
a. Import function to get regular updated data from CP SQL server for each
dept table included. (or have function to pull data during each need for
data required, similar to how all of our excel sheets work)
b. Maintain Backorder data with adjustable rule till backorder expires.
(Back order will expire in "x" days.)
II. Produce Price Changes
a. All invoice pricing to be entered from invoices as is done presently.
b. Margin achieved to be calculated by comparing cost to actual retail in CP
SQL server. (Presently we are comparing the cost to the suggested retail,
which is regularly different than the actual retail for ½ of the week.)
c. Produce data for price changes, to be copied and pasted into existing
price change ***.
III. Delivery Documentation
a. Provide separate Delivery Paper for each location, with total charges,
and also the current retail shown.
i. To include total case count.
IV. Track Purchases and Invoice Payment
a. Replace purchase log.
b. P.O.# generated for each order.
c. Form for entering invoices by matching to P.O.#
d. Create an interactive form / report for P.O.'s with no paid invoice
associated with them. User could enter an amount in an "Estimated Field"
until actual invoice is present.
V. Weekly Reporting of all Shipping and Billing Data.
a. Weekly Transfer Report
b. Weekly Cube Rate
c. Weekly Fill Rate by Location
d. Full Detailed Transfer Reports for All locations by time period specified
by the user.
VI. Application to be Accessible via the Internet.
a. Final Stage to be implemented when all error handling is apparently
complete.
b. Provide user interface accessible over the internet. Logins would be
user specific, some allowing updates, while others only allowing viewing and
printing of report data.


.