This item was previously placed for bid (item 24970). In this request, I have reduced and clarified the scope. What is a Pre-Enrollee? A Pre-enrollee is a lead that has elected to be placed into a free Concorde Group Powerline by submitting their information. See [url removed, login to view] Please DO NOT enter your information since this is a live website. To complete this bid, it is not necessary that you fully understand the concept of pre-enrollee. Hereafter, I abbreviate PRE-ENROLLEE as PE. The PE ROTATOR ASP script will work in conjunction with existing PE VERIFIER & PE POSTER ASP scripts. All input and output is with the PE POSTER ASP script. PE VERIFIER is necessary to provide input to PE POSTER for testing purposes. The successful bidder will receive access to the source of both these currently functioning programs for testing or necessary modifications to make the programs work together. Purpose of the PRE-ENROLLEE ROTATOR Program: After receiving the rotator AccountID and PEID from PE POSTER, the PE ROTATOR script will: 1) Determine the recipient of the next pre-enrollee by selecting a rotator member MemberID from the rotator database based upon pre-defined logic. 2) Increment all rotator selection tables. 3) Pass the PEID and MemberID back to PE POSTER. If PE POSTER is unsuccessful in posting to the designated SiteID, it will notify PE ROTATOR to decrement rotator tables in the rotator database. Purpose of ROTATOR ADMIN Program: This program will is a way to add to or change necessary aspects of the Rotator Database. For a better idea of the program functions, please see the “non-operative?? interface that I have place at: [url removed, login to view] The ROTATOR ADMIN script requires the one-time creation of the Rotator Database and tables. The program will be written in VB Script (ASP) and HTML. The database will be made using Access. The platform is Win 2000. The developer will be given access to the server for development and testing.
I. ROTATOR ADMIN program will be a two page web based interface to the ROTATOR DATABASE and consist of the following: A. ROTATOR DATABASE : TABLES - There will be four database tables for the Rotator Database; AccountInfo, Rotators, RotatorMembers, and MemberInfo. · AccountInfo ??" This table will have a six digit alpha-numeric AccountID key, a 1 digit string AccountType, a 32bit integer MemberID key, a 32bit integer DefaultMemberID, a 32bit integer TotalDelivered, a 32bit integer TotalPurchased, a 32bit integer ActiveRotators and a 32bit integer CurrentRound. · Rotators ??" This table will contain fields: a six digit alpha-numeric AccountID, an 8bit integer RotatorNum, a 32bit integer Round, an 8bit integer Shares, a 32bit integer NumDelivered, a 32bit integer TotalDelivered, a 32bit integer MaxDelivered, StartDateTime · RotatorMembers ??" This table will contain fields: a six digit alpha-numeric AccountID, an 8bit integer RotatorNum, a 32bit integer RotatorID, a 32bit integer Round, an 8bit integer Shares, a 32bit integer NumDelivered, a 32bit integer TotalDelivered, a 32bit integer MaxDelivered, StartDateTime · MemberInfo ??" This table will contain fields: a 32bit integer MemberID key, a 20 digit alpha-numeric Fname, a 20 digit alpha-numeric Lname, a 35 digit alpha-numeric Email, a 20 digit string Phone, a 30 digit Company, a 40 digit Address, a two state/province, a ten digit ZipPostalCode, a two digit Country. PARENT-CHILD RELATIONS: · AccountInfo to MemberInfo ??" unique key MemberID · AccountInfo to Rotators ??" unique key AccountID, ActiveRotators in AccountInfo is one factor in determining active rotators in Rotators. · Rotators to RotatorMembers ??"a combination key of AccountID and RotatorNum · RotatorMembers to MemberInfo ??" only if RotatorID is numeric then RotatorID is keyed to MemberID · RotatorMembers to AccountInfo ??" only if RotatorID is non-numeric then RotatorID is keyed to AccountID. (This allows nesting and multiple layers of rotators.) NOTES: · All Accounts are owned by members, not all members own accounts. · An AccountID can be converted to an AccountType and MemberID. Conversely, an AccountType and MemberID can be converted to an AccountID. I will supply the algorithm to convert back and forth. Conversion will only be necessary when creating a new AccountID and when displaying the account owner and account type in the ROTATOR ADMIN Interface. · The DefaultMemberID will be used when no rotators are active or rotators have reached their maximum. · In the non-functioning interface below, I used SiteID in place of MemberID. They are the same number. Used MemberID for the scripts. B. ROTATOR ADMIN Interface: · Interface with all aspects of the Rotator Database. The interface will consist of two interface pages: 1. [url removed, login to view] ??" This page will have two sections. One to Add/Lookup MemberInfo. The other section to Add/Lookup AccountInfo. 2. [url removed, login to view] - Similar to the “non-operative?? interfaces that I have place at: [url removed, login to view] · In the final, the pages will be ASP. After lookup/creating a new member on [url removed, login to view], the MemberID will be placed in both the new member and new account portion of form. · After creating a new account on [url removed, login to view], then automatically go to [url removed, login to view] with all known fields populated. · The [url removed, login to view] screen view will vary base upon the number of rotators chosen. · The members of only one rotator will be displayed at once as determined by the “Display?? radio button. II. PE ROTATOR ASP script details: After receiving the rotator AccountID and PEID from PE POSTER, the PE ROTATOR script will determine the Rotator recipient of the current pre-enrollee: · The active rotators will be sorted by “Round?? and then “NumDelivered?? and the top Rotator will be chosen. For continuation, see Platform section.
Deliverables Continued: · To determine the RotatorID recipient of the current pre-enrollee, the chosen Rotator will be sorted by “members with more than 0 shares where TotalDelivered is less than MaxDelivered, then “Round??, then by “NumDelivered??, then by “StartDateTime??. · The top member will be selected and the NumDelivered & TotalDelivered fields will be incremented by 1 and then if the NumDelivered equals Shares then Round will be incremented by 1 and NumDelivered set to zero. NOTES: · The RotatorID can contain either a MemberID or an AccountID. If it is an AccountID, then selection will continue through the cycle again in nested fashion. · When a MemberID is selected, pass the PEID and MemberID back to PE POSTER. · Even if a rotator/member is displayed, but has "0" shares, they are inactive. · When a rotator/member reaches their MaxDelivered, they are inactive.
## Deadline information
If minor details change in the above, it will not affect the overall requirement that complete and useable programs as generally described above must be delivered for the contract to be considered complete. Support if needed will be included for three months. Programmer must use MSN Messenger for communication purposes. Platform is ASP and Access on Win 2K Server