Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
page 1/6
Technical specifications of a vtiger module called vtiger relations to document and analyze relationships among various stakeholders
Table of Contents
1. General Description ............................................................................................................................. 1 2. Data Items ........................................................................................................................................... 2 3. Usage ................................................................................................................................................... 2 3.1 Input ............................................................................................................................................. 2 3.2 Output ........................................................................................................................................... 4 3.3 Export ............................................................................................................................................ 5 4. Implementation and known issues ..................................................................................................... 5 5. Licensing .............................................................................................................................................. 6 6. Procedure and Payment Conditions.................................................................................................... 6
1. General Description
This document outlines the technical specifications of a new module in vtiger called Vtiger Relations. It serves as a request for proposals (RFP). Vtiger provides us with a structure to manage data related to entities called accounts and contacts. The new module makes it possible to manage data related to a directed relationship between two stakeholders including relations between two contacts, two accounts, as well as between a single arbitrary contact and a single arbitrary account, or, vice versa, between a single arbitrary account and a single arbitrary contact selected by the user. Thereby, every relationship is handled as an entity of its own. It is not just an annex of one of the other entities. The basic structure and functionality of the new module resembles other modules. The module shall be an optional extension of vtiger and shall be available at the Marketing-tab. It shall be a 100% compatible to the module manager of vtiger using vtlib. Its usage shall be restricted by the rules defined throughout roles and profiles. Its picklists shall be administrated via the picklist-editor of vtiger. Furthermore, the administrator shall be able to add custom fields at the module manager interface . The module is designated to (1) document, show and edit relationships among accounts, contacts as well as accounts and contacts and, vice-versa, contacts and accounts. As usual, the view of every single relationship shows the two classical tabs: Relationship Information and More Information. It shall be possible to analyze relationships by (2) list, order, filter and search relationships and by (3) the usage of social network analysis software using
by Florian Dieckmann florian.dieckmann@gmx.net 2011-05-22
page 2/6
collected data through an export of collected and selected data to comma separated value (csv) files.
2. Data Items
A relationship represents a data entity with an own primary key. The number of those relationships is potentially unlimited due to the unlimited number of various types of relationships which might be defined. Their number can be calculated as follows:
number of relationsships = (number of stakeholders)2 * number of types of relationships
A relationship consists at minimum of the following data items: 1. ID of the relationship (Primary Key like e.g. REL1, REL2,, RELn) 2. Actor A (uitype 10 to Accounts or Contacts) 3. Actor B (uitype 10 to Accounts or Contacts) 4. type of relationship (string from picklist) 5. relationship start date (manually entry, converted into timestamp) 6. relationship end date (manually entry, converted into timestamp) 7. creation time of entry (automatic timestamp) 8. time of last editing (automatic timestamp) 9. owner (vtiger user in charge) 10. relationship status (string from picklist) 11. transacted good (string, direct input) 12. transacted value (string, direct input) 13. general description (input of some plain text) The administrator shall be free to add additional custom fields.
3. Usage
3.1 Input
The usage of the new module shall be similar to other modules like e.g. Accounts or Contacts. As known from other modules like e.g. leads, accounts, contacts, potentials etc., any Relationship Information can be associated with More Information like e.g. Activities, Activity History or Documents. The user is free to add a new relationship or to edit or to delete an existing one. First he has to capture 1. the first stakeholder or source of the relationship from the account or the contact module by a dialogue menu. 2. the second stakeholder or destination of the relationship from the account or the contact module by calling the dialogue menu a second time. Furthermore, the user has to enter manually
by Florian Dieckmann
florian.dieckmann@gmx.net
2011-05-22
page 3/6
3. the type of relationship chosen from a drop-down menu (defined by the picklist editor) 4. the status of the relationship chosen from a drop-down menu (defined by the picklist editor) 5. relationship start date (optionally) 6. relationship end date (optionally) 7. transacted good (optionally) 8. transacted value (optionally) 9. general description (optionally) 10. data in custom fields (optionally) Data related to versioning and ownership such as 11. creation time of the relationship entry 12. last editing time of the relationship entry 13. user assigned to the relationship has to be entered automatically, whereby the user assigned to the entry can be changed manually.
by Florian Dieckmann
florian.dieckmann@gmx.net
2011-05-22
page 4/6
3.2 Output
by Florian Dieckmann
florian.dieckmann@gmx.net
2011-05-22
page 5/6
For example, it will be possible to look for all relations related to a certain stakeholder (source or destination) on which the user is focusing. One of the most interesting feature ideas is to list outgoing and ingoing relationships at the +info tab of the account or contact entity.
3.3 Export
The ability to export entries as a list of comma separated values is crucial to make use of data by e.g. social network analysis software. The export as comma separated values (csv) has to include all data items according to section 2, including not only ID of source and ID of destination (like e.g. ACC1, ACC2,, ACCn or CON1, CON2,,CONn), but also name of those (name of account/ name of contact like e.g. Mr. John Doe) ID of relation (like e.g. REL1, REL2,,RELn) ID of source (like e.g. CONn or ACCn) Name of source (like e.g. John Doe or ACME Co., Ltd. ID of destination (like e.g. CONn or ACCn) Name of source (like e.g. John Doe or ACME Co., Ltd. type of relationship status of the relationship relationship start date relationship end date transacted good transacted value general description data in custom fields
If analysis needs data about the stakeholders, users are free to export account or contact information by using the according export functionality implemented in the account or contact module and to merge it based on the ID of source or ID of destination.
by Florian Dieckmann
florian.dieckmann@gmx.net
2011-05-22
page 6/6
5. Licensing
The new module shall be Open Source Software. Its license shall be compatible to the license model of vtiger. I suggest to publish vtiger relations under GNU General Public License or, if preferred by the programmer, under LGPL. The programmer is free to offer any other licensing model which open the opportunity for the customer to get into an open discussion, advanced evaluative programming and free usage of the software with others.
by Florian Dieckmann
florian.dieckmann@gmx.net
2011-05-22