General Ledger segment for MicroFinance system

Debits, Credits, Posting, CashBook, Fiscal Calendar, Trial Balance, Income Statement, Journal Entry, Chart of Accounts. If you are not comfortable with the above terms, please do not bid. If you are not an experienced programmer, the same applies. Production of a functional General Ledger segment for a MicroFinance system is the task before you. You will be working in conjunction with the buyer who is coding the current system. (Your buyer is a programmer running out of time, not an accountant ;-) Although regular contact via email is possible for clarification of any (design) aspects, as per RentaCoder policy, communication via this site is preferred to facilitate arbitration in the unlikely event that this should be necessary. Clarification of the MicroFinance operation will be provided to the successful bidder. Modification of an existing system: If you are the rightful owner of existing, working system code, this may prove sufficient. Depending on what you already have, certain of the deliverables may be relaxed. Please provide relevant details along with your bid that we may discuss this. I have already purchased accounting code from MAEsystems.com. While this code may be used for reference, please do not expect this to be accepted as your deliverable. No infringement of existing copyrights will be tolerated. ## Deliverables **1) Complete and fully-functional G/L segment. ** 1.1) Test script and example data demonstrate functionality. **2) Source. **The source for all tables, forms, queries, reports and VBA code should be delivered in a stand-alone MS-Access database for integration into the existing system. **3) Integration/Interface: ** 3.1) The function routines to be called from the existing system must be completely described. (This to populate and update the G/L segment). 3.2) It is envisaged that these will take the form of callable sub-routines. 3.3) The variables / parameters required to be passed to these routines must be explained. 3.4) The current system can be changed to enable capture or determine this information programmatically. 3.5) Guidance will be provided in terms of the screen layouts. (e.g. the system must be coded for an 800x600 resolution - minus left and top frames) **4) User Intervention** 4.1) Wherever possible manual intervention should be avoided. 4.2) Where this is not practical, a reasonable level of user-input validation should be included. 4.3) The initial setup process must be clearly expained. Screens and options used for this purpose should be visually explicit. **5) Coding Standards and Documentation ** 5.1) A reasonable level of commentary is expected in the code.(especially where code is not "self-documenting" - use meaningful names for your variables) 5.2) Comments must be in English. 5.3) It is preferred that Hungarian notation be used for the majority of variables. Camel or Pascal notation will, however, also be acceptable. 5.4) A separate functional / implementation document must be provided. 5.4.1) The format of these (developer) notes may be plain text or HTML. 5.4.2) These notes will form the basis for the Help File entries. 5.5) Guidance in terms of Form, Table and related naming conventions will be provided. 5.6) While calling native Windows API routines is permissable, the use of any 3rd-party components is to be avoided so as to uncomplicate licencing and installation. **6) Post-implementation Support:** 6.1) A reasonable post-delivery / implementation agreement will be mutually agreed on between buyer and seller. 6.2) If your system and code is sufficiently documented, this should not be necessary. 6.3) Any subsequent modifications or changes requested by the client will be offered to the original coder on a first-refusal basis. 6.4) If you elect, you may provide your name and contact details to be credited as the designer of this component. **7) Timelines: **User Acceptance Testing is scheduled to begin end June / beginning July 2005. 7.1) Regular progress / status reports will be expected 7.2) Please indicate whether you are able to commit to this timeline. **8) Major Functional Elements. ** 8.1) _G/L Structure:_ At least three levels must be supported, e.g. Division, Branch and Department. 8.1.1) A G/L account should (probably) be allocated for each of these locations. 8.2) _Fiscal periods:_ The system should support fiscal periods and be flexible as to the definition of such. 8.2.1) The option to post bank, balancing and adjustment entries into closed periods should be supported. 8.2.3) Depending on your design, MonthEnd and YearEnd processing may be required. 8.3.) _CashBook_ The system should include a CashBook element / View. 8.3.1) The system should support reconciling to multiple bank accounts. 8.3.2) Entry of "Bank" entries should be supported in addition to G/L transactions. 8.3.3) Automated upload of bank statements does not need to be supported at this stage. 8.4) _Balancing and Reversal:_ As far as possible, the system must warn the user immediatley it goes out of balance. 8.4.1) You should consider batching all transactions to aid you in this effort. 8.4.2) You should support real-time posting, i.e. not have to wait for end-of-day 8.4.3) The ability to reverse an errant batch would be appreciated. Please consider this in your design and provide some indication as to how this may be achieved. 8.5) _Reporting and queries:_ Although this aspect has not been clearly defined in the Functional Spec, the deliverable would need to include the following minimal set of reporting and queries. :- 8.4.1) Trial Balance. 8.4.2) Account Query (by Division, Branch, Department) 8.4.3) Cash-Book. 8.4.4) Debtors Balance Listing 9) 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). Thank you for reading thus far. Awaiting your input and bids. Robin. * * *This broadcast message was sent to all bidders on Tuesday May 3, 2005 12:19:24 PM: I've been quiet with good reason, folk. Drama and sadness, I'm afraid. In confirming the requirements with our client, the scope has grown even more - they now want full General Ledger functionality - at the same price !! This segment will now fall away. The new route is to build a txn file for upload into their existing General Ledger. It was very nice meeting you folk. I'm sorry that we couldn't do business. I will add you to my preferred coders. That way I can invite you to bid on my next project. (Probably an Access and web-based CRM offering.) Robin. (Takes a hit on his buyer no-action rating. ) ## Platform Windows 98+, Office 2K+. (Expect Pro, NOT MS-Access Runtime) The segment must be coded for MS-Access 2000. (DAO preferred over ADO, but not critical)