J2ME Order Entry Cell Phone Application(repost)

Description - A requirement exists for customers to place orders for parts using a cell phone application, effectively eliminating time-consuming requests to a call-center. The catalogue of parts is small and relatively static, currently approximately less than 100 part identifiers and their corresponding prices. A copy of the catalog will be resident on the cell phone, which may be updated when catalog changes are made. Customers will place an order by selecting (or searching for) a part number and the quantity of parts needed. Normally an order will contain several different parts. On completing a part order, the mobile user will be permitted to review, edit, and accept/reject the part order before selecting an additional part. After completing the final order for all parts, the mobile user will need to review/edit/cancel or accept the completed order. The mobile is then connected and submits the order to the host server, which acknowledges receipt of the order. Details of the project are in the attaches zip file. ## Deliverables Deliverables. 1) Complete and fully-functional working program(s) in executable form as well as complete source code of all work done. 2) Documentation consisting of user documentation and a separate technical (programmer’s) manual. The technical manual will contain a functional description of all program modules, processes and variable, a description of all test procedures used, and the results of these test procedures. 3) Deliverable software must be in ready-to-run condition, as follows (depending on the nature of the deliverables): a) For web sites or other server-side deliverables intended to only ever exist in one place in the Buyer's environment-- Deliverables must be installed by the Seller in ready-to-run condition in the Buyer's environment. b) For all others including desktop software or software the buyer intends to distribute: A software installation package that will install the software in ready-to-run condition on the platform(s) specified in this bid request 4) All deliverables will be considered "work made for hire" under U.S. Copyright law. Buyer will receive exclusive and complete copyrights to all work purchased. (No GPL, GNU, 3rd party components, etc. unless all copyright ramifications are explained AND AGREED TO by the buyer on the site per the coder's Seller Legal Agreement). * * *This broadcast message was sent to all bidders on Thursday Apr 20, 2006 3:12:16 PM: Thank you all for your prompt responses to our RFB. We submit the following clarifications for your consideration: 1. The completed order will probably be sent via HTTP, although we would like to keep our options open - e.g. SMS as an alternative. Whatever will work the most efficiently. 2. MIDP 2.0 is specified in order to take advantage of the improved forms capababilities (e.g. scrollable combo boxes) and the updated RMS API (e.g. Sharing record stores between MIDlets). 3. Customer information will be stored on the server side. User authorization may be granted by a PIN, the mobile's number or universal id, username/password, account number, or whatever, and is a server side function. 4. The sample data attached to the RFB is legacy data and contains some input errors (record 28, compare Productid with SearchField). Also, the minimum quantity i s irrevalent, since there will be a default of quantity of 5. Actually, the only information needed to place an order is a set of productids, the quantity and cataloged price of each product ordered. 5. Also note that the SearchField normally, but not always, contains all or part of the Productid (e.g. 6.8x2.6mm, SR626SW,30mAh and 377/SR626SW). This implies that the data can be significantly compacted without any loss of information on the server side. A restructured data set will be provided shortly. 6. Our servers currently run SQLServer under Windows 2003. 7. Also, in case you hadn't noticed, this is a self-contained shopping cart project. ## Platform J2me Mobile phones supporting cldc midp 2.0