Inventory - Java

Chiuso Pubblicato Mar 1, 2007 Pagato alla consegna
Chiuso Pagato alla consegna

Tha program needs to control the inventory of a company. It is defided between material (goods that are in sotck/supply) and capital assets. Goods are requested by the users to the warehouse, program controls the minimum amount based on the average consumption.

Capital assets are received and sotcked in the warehouse, after that, based on request goes to a department. Capital assets may be transfered to other departments and other companys.

This is a guideline to the program. To the winner I send a complete description of the routines, it is a 10 pages document.

Complete program has about 50 forms/screens and about 50 reports.

Some screens had only 5 fields, about 10 screens, some have 4 fields, about 10 screens, some have 10 fields, about 10 screens, some are bigger with different levesls, about 5.

Some of the reposts are very simple, and some involve a kind of math, about 15.

I have the database done.

## Deliverables

1) Complete and fully-functional working program(s) in executable form as well as complete source code of all work done.

2) Deliverables 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.

3) 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 Tuesday Mar 6, 2007 7:34:28 AM:

I posted an atached file with the full description of the program.

I am willing to choose a coder by tomorrow.

Please, make your offer or correct the value, based on the full description, if it is the case.

Thanks

* * *This broadcast message was sent to all bidders on Tuesday Mar 6, 2007 7:39:37 AM:

2, SPECIFICATIONS 2.1. MINIMUM TECHNIQUES Technological Environment 2.1.1. The access, the navigation and the operation of all the functionalities must be executed only e exclusively saw web browser, without the necessity of installation of specific customers in the work stations. 2.1.2. The solution must have sistêmica architecture in three layers: presentation, rules of business and administration of data. 2.1.3. The architecture must be reflected in the physical implementation of the product of the following form: 2.1.3.1. layer of presentation - executed exclusively through a web browser, (InterNet Explorer 6.0 version or superior, Netscape 7.0 version or superior). 2.1.3.2. layer of rules of business - executed in a server of Java application, compatible platform with the operational system Windows 2000 (or superior). 2.1.3.3. layer of data - executed in a gerencia dor system of relationary data base SQL SERVER 2000 (or superior). 2.1.4. The system will have to possess communication easinesses saw TCP/IP, in the Cliente/Servidor modality. 2.1.5. It must make use of control mechanism that assures the performance of the application and otimização of the use of the net resources. 2.1.6. Orientation paradigm must total be developed according to the objects, in the Java language. 2.2. Security 2.2.1. The gerenciador must contain security mechanisms that hinder consultations or alterations in data for not authorized users. 2.2.2. The transactions must only remain available the users specifically authorized for access to each one of them. 2.2.3. The system must allow to the use of a catalogue of profiles of users, defining specific standards of access for groups of users and making possible to establish restrictions of access in function of the organizacional structure (for agency, Managing Unit, Adminis trative Unit) and/or in function of the chart of accounts (program, subprogram, element of expenditure). 2.2.4. The system must allow that for each authorized access, the administrator can in such a way specify the type of transaction (consultation, inclusion, alteration or exclusion) to be executed in the data as in tables. 2.2.5. The authorizations or degradations, for user, profile or transaction, must be dynamic and to have immediate effect. 2.2.6. The access password must be only for all the modules, individual staff and. 2.2.7. The system must allow the use of digital certificates. 2.2.8. The system must make use of automatic routines for control of integrity of data implemented in the data base (triggers and stored procedures). 2.2.9. The validation of the information must be on-line, with the exhibition of messages in Portuguese to the user. 2.2.10. The system must make use of protection mechanisms that hinder the loss of transa ctions already accomplished by the user. 2.2.11. All transactions must be registered permanently with the indication of the user, date, accurate hour, information of the situation before and later, for eventual necessities of any type of analysis or posterior auditorship. 2.2.12. The system must make use of function of storage of log in proper, independent archive of the archives of data of the solution, allowing bigger flexibility in the administration of the proper system and the data base. 2.2.13. To contain protection against external accesses to the databases of the system and to implement rules of politics of security in the accesses internal besides making possible the accomplishment of backup of daily security. 2.3. Operational characterization: 2.3.1. Transacional 2.3.1.1. The system must allow the administration of some managing units simultaneously, with defined business-oriented rules between itself, control of execution of basic activities, integrated, on-line and real time. All the operations must automatically be reflected in the application and the data base, and immediately disponibilizadas for all the authorized users. 2.3.1.3. The system must hinder that any materialize transaction is eliminated already. In case that it is necessary a rectification of any information, this will have to be reversed so that she is registered permanently. 2.3.2. Documentation 2.3.2.2. It must make use of control of alterations and versions of objects of the solution. 2.3.3. Interface 2.3.3.1. The interface must be standardized in all the modules. 2.3.3.2. In the same way, the reports, messages, buttons and soft keys must be standardized for all the modules. 2.3.4. Parametrização 2.3.4.2. It must allow the configuration of menus to the level of profile of the user. 2.3.4.3. It must allow to the parametrização of documents and necessary information to the good cadastre a nd materials. 2.3.5. Users 2.3.5.1. The solution must allow to the access of a limitless number of users for visualization of consultations or fulfilling of solicitations. 2.3.6. Integration 2.3.6.1. All modules must be integrated, with the Inter-relationship of information being carried through of transparent form for the final user. 2.3.6.2. An only inclusion of each given information or must be enough for the system, independent of the used module. 2.3.6.3. Each module must be auto sufficient for the execution of its basic operations, and the integration between the modules must be automatic. 2.3.7. Temporality 2.3.7.1. All registers of events in the database must be secular in order to allow the recovery of the data in any desired last date. 2.3.7.2. It must allow to the launching of referring data the previous events to the date of implantation of the system. 2.3.7.3. The storage of the information must be for limitless time, with mechanisms that assure the performance maintenance, being able to be defined the limitation of time for the administrator. 2.3.8. Reports 2.3.8.1. It must possess models of the obligator reports for the current law previously elaborated; 2.3.8.2. It must allow to the generation of reports with breaking for groups (in some levels), crossed tabulação and multicolumns. 2.3.8.3. It must allow the emission of reports associated the events or routines. 2.3.8.4. It must make use of report of LOG of access, alteration/inclusion of information I contend name of the user, it dates and hour of the inclusion, and the information previously registered in cadastre. Such report can be parametrizado to contemplate the access for agency, profile, group, user or transaction. 2.3.9. External integration and Exportation of archives 2.3.9.1. The system must make possible the generation of archives in format text obeying the layout defined for the user, with or without delimiters, for exportation of data the systems auxiliary. 2.3.9.2. The system must allow integration with tools clerical as spread sheets, texts and compatible E-mail with interface MAPI and integration with universal agents of e-mail in standard smtp. 2.3.9.3. The system must make possible the importation of daily registers in cadastre it of users of the CONTRACTOR, through automatized procedure to be executed without manual intervention (service). 2.3.10. Table of Materials and Services 2.3.10.1. The system must have for base the Federal table Supply, but it must allow to the adoption of any another standardized table. 2.3.10.2. The table of materiais/serviços must be only e to be available for all the modules of the system and for direct consultation for the authorized users, as format to follow: [url removed, login to view], being that, in the sequence: 99 = group 999 = item 2.3.10.3. The system must allow to the classification of the mat erials or services for expenditure nature. 2.3.10.4. The system must hinder the cadastre of two the same itens of material or service with the same description or code. 2.3.10.5. A registered in cadastre material/serviço cannot thus be excluded and yes disactivated remaining cadastros of materials/active services and inactive. 2.3.10.6. The system must allow to activate an inactive material/serviço after evaluation of inactive for responsible sector 2.3.10.7. The system must allow to the storage and the indexation of the image of the material, of the packing, croquises, petition, plants and other graphical documents of interest of the agency. 2.3.10.8. The system must possess mechanisms of search through words key or radicals contained in the name or the description of itens. 2.3.10.9. It must allow the creation, impression and publication in complete or partial the WEB of catalogues of materials and services, for group, classrooms, cha racteristic and unit. 2.3.10.10. It must allow to the creation of standards of description for each classroom and family of materials, of form to normatizar the inclusion of each item no I register in cadastre; 2.3.11. I register in cadastre of Suppliers 2.3.11.1. The system must make use of registers in cadastre of suppliers, as many physical people as legal, for only access for all the systems, relating the suppliers with grupos/classes of the materials/offered services. 2.3.11.2. The relative data to the documentation, legal representation of the suppliers must be stored of secular form, allowing, thus, the visualization of data that had been modified. 2.3.11.3. The system must the same hinder the cadastre of different suppliers with CNPJ/CPF, or same Social Nome/Razão or, still, with the same Name Fancy. When the sócio/empresa is foreign, field CNPJ/CPF must automatically be inabilitado. 2.3.11.4. The system must allow the blockade of suppliers with irregular situations to participate of any process of licitation. 2.3.11.5. The system must make possible the visualization of the classrooms taken care of for a supplier, as well as which is the qualified suppliers to offer one definitive classroom of materials. 2.3.11.6. The screen of necessary documents to the cadastre must in accordance with be shown the Type of Person (Physical or Legal). 2.3.11.7. The system must allow the search of suppliers from words contained in its name, corporate name or name fancy. 2.3.11.8. The system must allow the search of suppliers from CNPJ/CPF 2.3.12. Table of Structure Organizacional 2.3.12.1. The system must make use of table contends the codified organizacional structure of hierarchic form, also registering the relationship and the subordination of the diverse agencies represented in the table. 2.3.13. Table of Localization 2.3.13.1. The system must make use of table of physical addressing of all the Organization, tied with the table of organizacional structure, establishing complete it and unequivocal localization of each good. 2.3.13.2. For the warehouse module, one second table of localization still must be kept, for internal use of the warehouse, that allows the identification for bar code of the structure of the physics of the warehouse (armários/prateleiras/gavetas, etc); 2.3.14. Prices 2.3.14.1. The system must allow that each material and/or service possess quotations of prices, that are gotten from data of entrances in warehouse, of contractual clauses or consultations the suppliers. These quotations must form a bank of prices, that will assist the estimate of cost of the requests of purchase and act of contract and in the evaluation of proposals presented during purchase processes. 2.3.14.2. The system must stores the historical value quoted and to allow the presentation of the corrected value. [url removed, login to view] .3. The system must allow that the prices of the materials stored in the bank of prices can be visualized in some monetary units, as well as can in accordance with be brought up to date diverse indices of variation of prices, of form to allow comparison between prices during periods where inflationary losses exist. 2.4. FUNCTIONAL CHARACTERIZATION OF THE MODULE MOVABLE PATRIMONY 2.4.1. General characteristics: 2.4.1.1. To make possible the control and countable classification for type of good. 2.4.1.2. To use system of identification of the goods through bar code 2.4.1.3. To allow established sequences of patrimonial numeration in parameters established for the user. 2.4.1.3.1. Code used in the table: [url removed, login to view], being that, in the sequence: 99 = group 999 = item 999 = model 9999 = elemento/sequência 2.4.1.4. To only allow cadastre of good for physical control, excusing the countable control (to give an example, is for example the loan case? Of where it comes the countable classification) 2.4.1.5. To register similar goods and the passíveis materials of consumption of use for each type of good. 2.4.1.6. To make possible the reversal of inclusão/alteração, when cabível, preserving the description of the good. 2.4.1.7. To emit the Term of Responsibility and reports of conference with countable summary. 2.4.2. Entrance of Good: 2.4.2.1. To register in cadastre the goods of individual form or for lot. 2.4.2.2. To register documents associates to the entrance of the good. 2.4.2.3. To register the guarantee of each good. 2.4.2.4. To enter the goods in the supply, or account defined for the customer. 2.4.2.5. To make possible the control and countable classification for type of good. 2.4.2.6. To contemplate the possibilities of entrance of the goods, being classified them of budgetary automatic form in and extra-orçamentaria, as pertinent legislation. (of where it comes the information? Normally it would be through Siafi) 2.4.2.7. To make possible the conceptualization of a main or secondary, added good in to the principal good. 2.4.2.8. To make possible that other goods can be added to the main one already in entrance 2.4.2.9. To define characteristics demanded for cadastre of the goods, being allowed the classification in general and individual characteristics for each good. 2.4.2.10. To exactly allow the cadastre of good of third for physical control (case of the 2.4.1.4. To give an example) 2.4.3. Low of the Goods: 2.4.3.1. To allow to the election and grouping of good for low, by means of parameters and combinations of consultations, for posterior analysis and confirmation of the process of low. 2.4.3.2. Individually to carry through the low one of good or for lot, as previous process and by means of reading optics. 2.4.3.3. To keep description of good for consultation 2.4.3.4. To make possible t he when cabível reversal. 2.4.3.5. To effect pertinent the accountings to the process of low with the original values, corrected and depreciated. 2.4.3.6. To emit to any time reports (term of low, relation of decreases), with the summary of countable classification. 2.4.3.7. To keep the description of the process of low, registering all the transaction, since the opening of the process until its closing, also the conclusion that can be: authorized, not authorized. 2.4.4. Transference of Good: 2.4.4.1. To carry through the movement of some goods, diverse origins, for an only destination, generating automatically a term of transference for each origin. 2.4.4.2. Individually to allow the transference of the goods or for lot. 2.4.4.3. To make possible the transference of good for survey saw collector of data with reading optics. 2.4.4.4. To make possible agendamento of transference between users previously registered in cadastre in the syst em, with profile or not of authorization of the origem/destino sector and the coordination of patrimony. 2.4.4.5. To emit to any time reports (transference term, relation of the consolidated transferences of one determined period and receipt of the transferences), with the information of origin and destination and the responsible ones for the event, folloied of the summary of countable classification when it will be the case. 2.4.4.6. To emit relation of the consolidated transferences of data period. 2.4.4.7. To store all the movements for posterior consultation. 2.4.4.8. Incorrectly to make possible the alteration or reversal of the transference of a effected good observing always the accounting in the legal form. 2.4.4.9. When to occur transferences between distinct administrative units, to effect all the accountings of the original, corrected, depreciated, residual values, etc. 2.4.5. Maintenance: 2.4.5.1. To control maintenance the passíveis contract capital assets, being tied them it the supplier. 2.4.5.2. Emission of reports for control of validity stated periods and attendance of contracts (it needs to make) 2.4.6. Inventory: 2.4.6.2. More than to make possible the union of a survey with the inclusion or exclusion of patrimonial numbers. 2.4.6.3. To emit critical reports of of inventory, using itself of the survey carried through in determined local, by means of the reading optics. 2.4.6.4. To allow the codification of the physical situation of the good, by means of the process of electronic inventory. 2.4.6.5. To after allow to the update of the status of the good the inventory controlling what it is embezzled, what he is being disponibilizado and what already was found (to activate the goods) 2.4.7. Consultations/Reports: 2.4.7.1. The consultations and the reports will have to be elaborated dinamicamente by the users, with exits for video, printer and archive being able to be used in the Word, Excel or other tools. 2.4.7.2. To emit reports personalized from a consultation. 2.4.7.3. To make possible the consultation of a good with all the pertinent information of also registers in cadastre and the occured movements and decreases. 2.4.7.4. To propitiate the visualization of the good, by means of its image. 2.4.7.5. To emit synthetic and analytical managemental reports, for research filters. 2.4.7.6. To emit retroactive reports espelhando the reality do na dates well in question. 2.4.7.7. To emit the summary of movement of pertinent good; (as it is made today) 2.4.8.5. Standardization of the nomenclatures and formattings of the respective fields, composites of process number, document, project and others; 2.4.8.6. Analysis and elaboration of the organization chart and physical space, descriptive and codified form, as hierarchy of the Agency for identification of the property inherited from par ents; 2.5. FUNCTIONAL CHARACTERIZATION Of the MODULE WAREHOUSE And PATRIMONY 2.5.1. General characteristics: 2.5.1.1. To work with periods in open, making possible to the user to any time descriptive, quantitative and financial adjustments, remaking the calculations automatically. 2.5.1.2. To manage some Agencies, Managing Units, Warehouses and sub-warehouses, allowing to define rules of movement of materials between the same ones. 2.5.1.3. To allow the creation of a limitless number of internal sub-warehouses to the CONTRACTOR. 2.5.1.4. To tie supplier with the respective materials. 2.5.1.5. To insert the material through automatic search of the Federal table of materials Supply; 2.5.1.6. To make possible that the material can have units of measure differentiated for entrances and exits of the supply. 2.5.1.7. To control the validity of the materials informing its expiration when setting in motion the system. 2.5.1.8. Automatic acknowl edgment of the ressuprimento of the supply. 2.5.1.9. To reverse entrances, in case that it has incorrect launching with automatic reprocessamento of the supply. 2.5.1.10. To tie to the material with a shelf address and standardization of the localization of the storaged materials. 2.5.1.11. Definition of politics of purchases; 2.5.1.12. Stockable and eventual supply divided in; 2.5.1.13. Classification of the supply how much: 2.5.1.13.1. 1. Nature; 2.5.1.13.2. 2. Criticidade; 2.5.1.13.3. 3. Consumption; 2.5.1.13.4. 4. Value. 2.5.2. Entrance: 2.5.2.1. Diversified types of entrance (provisory, proper confection, immediate consumption, suppliment of deep or definitive), as the countable characteristics. 2.5.2.2. Automatic addressing of the material at the moment of the launching of the forma bill of sale; 2.5.2.3. To allow the low one of the ressuprimento order hanging. 2.5.2.4. To make possible the characterization of the material at the moment of the launching by means of previous and inherent parametrização to each material. 2.5.3. Solicitation of Materials: 2.5.3.1. To allow to solicitation on-line with password of restricted security the administrative unit of the requisitante and with option of the responsible one to authorize or not it solicitation for confirmation of the warehouse. 2.5.3.2. To allow the union of order of similar materials as well as the dismemberment. 2.5.3.3. To make possible consultation to the taken care of or hanging solicitations, pertinent the administrative unit of the requisitante. 2.5.3.4. To possess demonstrative archive of all the solicitations for decreasing order. 2.5.3.5. To criticize the excess of order of the requisitante unit, case is above of the monthly average consumption. 2.5.4. Adjustments: 2.5.4.1. To make possible entered physical and financial adjustments already referenciado them in the current month. 2.5.5. Low of Mater ials: 2.5.5.1. To make possible the election of materials for low, with respective justification. 2.5.5.2. To possess cancellation of the low one returning automatically for the supply. 2.5.5.3. To keep the description of the material until the register of the low one, for eventual consultations or alterations. 2.5.5.4. Report with countable summary. 2.5.6. Devolution of Materials: 2.5.6.1. To possess routine for devolution of material, with automatic reprocessamento of the supply generating the new balances. 2.5.7. Consultation/Reports: 2.5.7.1. To allow to the emission and consultation of reports monthly or accumulated as stipulated period. 2.5.7.2. Analysis of consumption for localização/Centro of Cost. 2.5.7.3. Monthly and annual financial summary. 2.5.7.4. To contain description of all the movement of the material for Administrative Unit/Requisitante/Number of the Requisitante Document/Asked for and Supplied Amount. 2.5.7.5. To vis ualize occurrences, with register of all the procedures consisting name of the user, dates and moving material. 2.5.8. Maintenance: 2.5.8.1. To modify the element of expenditure with processing and automatic register for the System; 2.5.8.2. To modify the address of shelf to any time with label impression of identification with bar code; 2.5.9. Inventory: 2.5.9.1. To admit the automatized inventory, with optic reading of the bar code in labels of shelves; 2.5.9.2. To emit financial reports being designated the possible divergences with the physical supply during the inventory process; 2.5.9.3. To make possible automatic adjustments of the possible divergences through registers. 2.5.10. Ressuprimento: 2.5.10.1. The routine of ressuprimento of materials must generate the order of purchases with value of the last acquisition and monthly average balance. These procedures must after be defined the classification of the materials in: 2.5.11. Nature: 2.5.11.1. Active materials. 2.5.11.1.1. Inactive materials in use. 2.5.11.1.2. Inactive materials in disuse. 2.5.12. Type of Consumption: 2.5.12.1. Eventual consumption. 2.5.12.2. Consumption of high frequency. 2.5.12.3. Consumption of low frequency. 2.5.12.4. Immediate consumption. 2.5.13. Value: 2.5.13.1. Classification grouped in function of the value of consumption in data period, as parameters established for ABC curve. 2.5.14. Criticidade: 2.5.14.1. Materials whose lack can cause upheaval. 2.5.14.2. Materials whose lack does not imply in incidental costs. 2.5.14.3. To control the ressuprimento of the materials that has contracts in vigor emitting acknowledgment to the supplier to ressoprar the warehouse. 2.5.15. Implantation: 2.5.15.5. Inventory of the existing current supply with the respective countable summary; 2.5.15.7. Launching of the physical and financial balance; 2.5.15.8. Definition of profiles of the users, as i ts restricted attributions and accesses the information; 3.2.2.2. The system will have to allow the use for a limitless number of active users, for module. 4.8. In the hypothesis of problem of new version or decurrent procedure of orientation of the CONTRACTED one, the CONTRACTED one will have to provide in the maximum stated period of 24 (twenty and four) hours its regularization, without any responsibilities adds for the CONTRACTOR.

## Platform

Program must be done in Java Web and SQL Server. Windows is the operating system

Java PHP

Rif. progetto: #2863560

Info sul progetto

43 proposte Progetto a distanza Attivo Mar 22, 2007

43 freelance hanno fatto un'offerta media di $3486 per questo lavoro

amunsol

See private message.

$17000 USD in 7 giorni
(112 valutazioni)
7.0
biland

See private message.

$1700 USD in 7 giorni
(26 valutazioni)
6.1
developBest

See private message.

$1275 USD in 7 giorni
(20 valutazioni)
5.9
techtrio

See private message.

$1275 USD in 7 giorni
(8 valutazioni)
5.6
digitalspecks

See private message.

$6800 USD in 7 giorni
(20 valutazioni)
5.6
DavidHK

See private message.

$1530 USD in 7 giorni
(24 valutazioni)
4.9
myvisl

See private message.

$425 USD in 7 giorni
(75 valutazioni)
4.7
ahmadkvw

See private message.

$1700 USD in 7 giorni
(11 valutazioni)
4.6
fusion35

See private message.

$1275 USD in 7 giorni
(19 valutazioni)
4.4
drlsoft

See private message.

$17000 USD in 7 giorni
(11 valutazioni)
4.4
bochum

See private message.

$1487.5 USD in 7 giorni
(5 valutazioni)
4.1
ggeorgakuth

See private message.

$935 USD in 7 giorni
(9 valutazioni)
3.9
karthikeyanr

See private message.

$1700 USD in 7 giorni
(27 valutazioni)
3.9
vw1591149vw

See private message.

$1700 USD in 7 giorni
(9 valutazioni)
3.6
ateliersoft

See private message.

$11900 USD in 7 giorni
(10 valutazioni)
3.5
kirandvs

See private message.

$1445 USD in 7 giorni
(8 valutazioni)
3.3
aqtoorvw

See private message.

$2550 USD in 7 giorni
(2 valutazioni)
4.2
aktechvw

See private message.

$1275 USD in 7 giorni
(5 valutazioni)
2.9
qualitysolu

See private message.

$5950 USD in 7 giorni
(4 valutazioni)
2.9
MartinsNet

See private message.

$1190 USD in 7 giorni
(10 valutazioni)
3.0