1

(38 replies, posted in Modules Add-on's)

Hi

Rewriting a big product! This is absolutely baseless. If this is the case, them one should go for the proprietary product, there is no point in picking up the open-sources.

I'd like to take this opportunity to mention that I've already integrated a full-fledged multi-location inventory, stock movement, reorder levels etc. and invoicing including debit notes, credit notes. vT code is multi-company. One single (multi-theme) UI, one single db, and one single codebase are already in place. The all-powerful VT's workflows and custom fields apply to this product.

This cannot be achieved unless one has a good knowledge of the VT/FA internals. And only, accounting is left. I have made a concrete plan on how to integrate it.

I think there is a difference between my vision and yours and thus the debate. I am looking it from the angle of challenging the ERP-proprietary market. When an ERP company promotes its product, it has to pay to the developers, to the marketing team, placing ads on the popular web sites, maintenance, office/miscellaneous expenditures.

When compared to the major open-sources, the only expenditure is related to the developers. I believe that the developers should be paid if the work is big enough. Had this been a week's or a part-time job, I would have done it gladly for the community. But it needs full-time involvement. Most of the successful open-sources are funded by people/big companies. Why cannot ours?

As I said in my last email, people will join when they come to know of the combo-product (CRM/ERP both). They will use the product and do/report the bug-fix. All that we need to do is to put it on track and the support team will be there automatically.

2

(38 replies, posted in Modules Add-on's)

Hi

I am sorry for being late in my reply. Lots of work!

>Integrate vtiger and frontaccounting  WITHOUT changing the core code of either vtiger or frontaccounting.
I don't believe this is possible. For me, this is not a "seamless" merger but only the "basic" integration. Two different dbs, 2 different UIs (look and feel), 2 different sets of base functionalities, fi, vT role-based security is quite different from that of FA. This kind of integration is a kind of work-around. Or, you can say its a patch-work. If our objective is to challenge the ERP proprietary market, then we should look forward for the seamless integration. Good, stable software are not built in a day, my original quote :-)

There are several disadvantages related to the "basic" integration, The main being:

a. Maintain 2 different PHP code-bases. Let's talk about customization, a company wants to add a new field in its invoice and validate the value of that field. In this case, we have to modify 2 code bases.

b. Backup/Restore/Create tables in 2 dbs

c. The end-users will have to learn 2 different set of UIs and base functionalities (like roles, etc.)

d. The multi-currency concept is different in both the FA and vT.

e. vT is multi-theme, FA is not.

f. For instance, both offer the Sales Order (SO) functionality. We will have to ask the end-user to login to vT and create the SO and then login to FA to perform other operation related to SO which vT does not offer.

g. Two accounts for each user, one in FA and the other one in vT. The user has to keep track of 2 passwords.

h. It will become really difficult for a new developer to maintain the two different code bases. First he will have to learn both More importantly, he will to shift his mindset from one codebase to another while making the modifications.

>we would like to have the ability to take advantage of the awesome updates that both Front Accounting and Vtiger come out with in the future.
Both are pretty stable versions now and if something major update comes, we have to do it manually. Let's think it the other way around, if we come up with a major module, then vT and FA users will be chasing us.

>It doesn't make sense for us to try to compete against FA or vtiger with another ERP system that is a fork of both.
No. vT does not offer, fi, Accounting and FA does not offer CRM. But our version will offer both. So we are better than them :-)

>I think FA should specialize in what it does best, Accounting. and vtiger should specialize in CRM.
If we get good sponsors, our end-product is going to be a very powerful package. I think the sponsor will play a major role in the product's feature and other decisions.

>FA needs the following things: 1. Ability to add Custom Fields ...
Vtiger needs the following things: 1. Ability to add a Task ...
I can do this. I have already planned for the seamless integration. And I am successful whatever integration I have done so far.

For instance, I have made huge changes in the vT source code to make it multi-company . Just like FA, at login time, it asks you to select a company. And the data in the db of multiple companies is completely separate. And one can easily consolidate them for reporting.

If any long-term sponsor is there, I am always around. I know what and how to do from the developer's point of view. Yes, from the features point of view, we need to discuss.

Kind Regards

3

(38 replies, posted in Modules Add-on's)

Hi everybody

Several people are interested in integrating the FA with vTiger. I have followed them closely. Both products have their own pros and cons. And our objective is to take the pros from them and merge seamlessly i.e. single database, same UI, fi, same look and feel for both Accounting (FA) and Leads (vtiger's) modules, same security policies, introducing multi-company feature in vTiger, etc.

I'd like to take this opportunity to mention that I can do this work 100% because I already have done such work before and I have a pretty good knowledge of both the vTiger and FA internals. But all that I need is a sponsor as this is a time-consuming and a difficult task. If done properly and with sincerity, this can be a hot product in the ERP sector and it can pose a challenge to the proprietary ERP products. I have studied the ER market closely and there are hardly any web-based/mobile-based ERPs that can offer so much of functionality (when FA and vTiger combined)

Any sponsors, pl. raise hands. There can be several :-) The point is why not to utilize such a huge, stable codebases!

Looking forward to hear on this issue. Yes, people would like to talk on which features to incorporate, fi, Sales Order of vTiger or FA, or a combo of both. But this can be done later once we agree to work on it (hopefully, yes)

Kind Regards

4

(38 replies, posted in Modules Add-on's)

>Vtiger provides web services and REST APIs I believe - I don't think Frontaccounting does yet.
You are right.

>Maybe the new Extension Manager (see sticky topic) can be used?
No idea about how to use it.

>I wasn't aware of the licence problem - what about the other way around - combine the GPLed code with the MPLed code - does which way this is viewed make any difference?
It is almost confirmed that we cannot combine the these 2 different licenses at the source code level. Combining the GPLed code with the MPLed code and vice-versa are one and the same thing.

>One big hurdle is that both products provide the same functionality in some areas - invoices,quotes,stock control/inventory.
Stock control and inventory in vTiger are too basic to use. FA is much better.

Janus has given some good hints on how to integrate these two big Open Source programs. Read his post in this topic itself. I can give a try integrating them. There are so many hurdles to cross. I believe it will take about 2-3 man months to produce a stable integration. Had this been a week time, I'd have started immediately. But investing so much time is directly proportional to the money involved :-)

5

(38 replies, posted in Modules Add-on's)

Hello friends

I am new to FA.

What different routes one can take to integrate FA with vTiger?

a. Using Web Services

b. Seamless integration at the code level.

c. Any other ...

Can someone integrate it at the code level i.e. taking the appropriate portions of vTiger code and place it in the FA. I believe there are 2 issues relating to this approach:

a. The vTiger code base is too huge to handle.

b. FA is GPL based and vTiger is MPL based and one cannot combine the MPLed code with the GPLed code according to the rules stated in the GPL. I may be wrong b'coz I don't know much about the licensing conditions? What do you say? An early reply will be a welcome.

Thanks