AdamFeerst
Registered User.
- Local time
- Today, 05:38
- Joined
- Sep 21, 2015
- Messages
- 63
I'm developing a database that will allow people in different departments (e.g., sales, finance, customer service, executive) to be able to view revenue related data (revenue, transaction volume, principal) in different aggregations and summaries.
Background: This is a unit of a company that processes payments for clients. The payments can represent different products depending on the payment source/type, industry, incoming or outgoing, speed, etc. Clients can have different products, and can have multiple services within a product. And, a company can have subsidiaries and/or separate units that are treated as different entities, sometimes with different sales reps, contacts, billing info, etc. This was built on a legacy system where there's a 1-1 relationship between unique service (ClientID) and Customer. While a customer can have multiple ClientIDs across multiple products, my system is the only one that allows aggregation.
There are several reasons to use something other than Access as the UI.
Background: This is a unit of a company that processes payments for clients. The payments can represent different products depending on the payment source/type, industry, incoming or outgoing, speed, etc. Clients can have different products, and can have multiple services within a product. And, a company can have subsidiaries and/or separate units that are treated as different entities, sometimes with different sales reps, contacts, billing info, etc. This was built on a legacy system where there's a 1-1 relationship between unique service (ClientID) and Customer. While a customer can have multiple ClientIDs across multiple products, my system is the only one that allows aggregation.
There are several reasons to use something other than Access as the UI.
- This will be used across a wide area. Remote users are having difficult getting access to the folder where the BE resides. We are migrating the BE to a sequel server, which may or may not resolve that problem.
- Data transmission for remote users (via VPN) can be slow.
- Sales reps, when traveling and visiting clients, would like to be able to view this on a mobile device, like they can with SF.
- Management would like it to be in SF because
- SF is the source of record for client hierarchy, active products/services, etc.
- They use SF regularly, so it would be easier if it were there rather than having to launch a separate app.
- It's easy to build/maintain hierarchical relationships in SF.
- Even if SF is not the UI, we'll need to maintain data consistency with SF.
- Speed does not seem to be an issue with SF, web based.
- Did I say that's what mgmt wants?