The osSuite that we are currently working with is a combination of an old Nola version and an old osCommerce version. What the original developers did was use the Nola as the "core" and "added" the osCommerce store portion. This means that they used the Nola database structure and changed the osCommerce to use Nola's database structure. This changed nearly all of the code in osCommerce.
In order to upgrade osSuite to use the most current options that are available in the current version of osCommerce, we would have to rewrite almost the entire osAdmin and osCatalog.
The current version of osCommerce ALREADY includes the "osAdmin" and "osCatalog" portions of osSuite and they are much more updated with many more options available. The only part of osSuite that the current version of osCommerce is missing is the osERP part.
The reason for JUST changing the osERP to work with the current version of osCommerce is twofold:
1. Nola is outdated and development has ceased and the original osCommerce version that osSuite is based off of (back then it was called "The Exchange Project" or "TEP") is radically outdated and also unsupported.
2. The current version of osCommerce is currently in development, supported, and has a plethora of users/developers/contributors that are writing code for it every day.
I see no reason to go back and retouch all of the osAdmin and osCatalog code in order to do something that's already available (and stable) in the current version of osCommerce. In order to make osERP work with the current version of osCommerce, we merely need to ADD to the current osCommerce database structure to include what osERP needs to run and we would have to rewrite ONLY the SQL code for osERP. It will be MUCH less work to do it this way, thereby being much faster to get it operational. We would also have tons of help from the osCommerce users/developers/contributors who are interested in having an ERP backend to their store.
The osERP is not the most important part of the store, however, it is the only part of the Suite that is not already currently available in the current version of osCommerce.
Let me know your thoughts!
--Brandi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Brandi:
1) Thanks for the background.
2) "In order to make osERP work with the current version of osCommerce, we merely need to ADD to the current osCommerce database structure to include what osERP needs to run and we would have to rewrite ONLY the SQL code for osERP".
When somebody says that something like linking two systems like these is going to be easy, I normally doubt it.
But I admit that it will certainly be easier.
I think we will put osERP connect to osC database, arrange the tables with a prefix maybe.
Can't see much of the need of changing the SQL code, but maybe you know something I don't.
Connecting the whole, that will be the challenge.
For starters we will have to figure out a way for sharing the session, or would we use the login for each separate module as it is?
I guess we are going to have a bit of a conversation going on around this.
I am gonna grab a stable ver. of osC and get in touch with the new code.
Walt:
Thanks for the links, I will dig on these.
Sorry for the naive questions.
Pedro A.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
May I???
Maybe I'm too enterprise minded... and please correct me at anytime...
SESSION: sharing should not really be considered if both apps are not one app as a whole.. eg
When implementing such, your OsC user shoild not have access to your ERP... its actually a BS7799 faux pas..
In a team oriented environment, I would not give my OsC admin keys to my kingdom. After all there is just way too much legal information involved in the OsERP. Like bcc'ing the entire company the payroll section [as a for instance]
Hence the login for each seperate module...
Naivete is the key to growth... and that's coming from a neophyte...
you people are amazing... I look forward to monitoring and if at any length possible helping in any way I can...
Dan--
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree that this won't be "EASY", however it will be "EASIER". *GRIN*
If we use a prefix it will defeat the purpose of integrating the two, unless you are speaking of only those tables dedicated to osERP that do not use the osC (payroll, etc.).
We will have to change the SQL code in two ways; initially to update the table/field names to reflect any changes there, and also (I believe) when osC releases their Milestone3 (not sure if this is in the SQL or the PHP yet, I haven't dug that far yet).
Connecting really won't be an issue (again, I THINK) because the two systems are fairly independent, other than they use the same database and pull the same data. Sessions won't be affected at all. You will always need to login to EITHER the admin side of osC or the osERP side. As Dan (godzhand) mentions above, they shouldn't be TOO integrated, for the purposes of security. (Example: I currently have my brother entering products into my store via my osC admin account. I do NOT necessarily want him digging into the payroll section of osERP and changing his paychecks. *GRIN*)
We will go ahead and change osERP to use the osCommerce 2.2MS2 version for now. When 2.2MS3 releases (whenever that is) we'll update our version and offer it separately. (i.e. we'll support both versions for a while) This is because so many people have 2.2MS2 and have modified it so heavily that they may not want to upgrade to MS3 in the near future.
My test site http://www.brandiruppell.com/ossuite offers links to the osCommerce 2.2MS2 version of the admin and catalog sections. You can play with it to see how it works and then download it from osC and play with the code. Honestly, I don't think we'll have to change that much, if any, osCommerce code.
I'm also very enterprise minded. I have worked for some VERY large companies where security was an absolute necessity. I'm looking at this solution from a "company" standpoint, as I am planning on having several employees with several different "rights". Just because the majority of osCommerce users are home-based businesses and/or single employee businesses does not mean that we should slack on security measures that medium to large sized businesses would insist on. This project summary states that this is written for small to medium sized businesses (written as "enterprises") so we need to keep those medium sized biz's in mind.
Let me know your thoughts!
--Brandi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Brandi,
Excellent, I appreciate everything you said... User rights within osERP is / was my next point of reference...
Being a neophyte I have no idea of how difficult it would be to develop the rights for A/R, A/P, Personell Dept., admins and managers and or any other misc. users which can contribute and extrapolate the business information... This can be a quandry when generating KPI's or Key Performance Indicators through various reports...
I'm going to tangent here a sec please forgive... CRM would you consider osERP classified to handle the in-between needs of such? I've been using SugarCRM...
[http://sugarcrm.com], Class act that app...
Being a work in progress... can there be any tie ins for such an app.. as well as the jpgraph implementation for a dashboard like repository reporting schema?
Is it worth it, time and effort... keeping it simple is such a desirable state and maintaining focus is paramount...osERP is no simple matter as it is as you stated, let I not distract from the primary current goal...
I get carried away sometimes... must be all that darn reading...
Dan---
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Users and Rights:
Lo and Behold, when you dig deeper into something and stop "skimming" through it you find what you're looking for. :)
The original writers DID include the ability to add users and RIGHTS! Look under the "Admin" tab. The first option is "Users and Rights", beneath the "Edit Selected User" button there is a small "Add new user". Here you find where you can add:
username, password, language, active (yes/no), supervisor (yes/no), accounts payable (read/write/setup checkboxes), Accounts Receivable (read/write/setup checkboxes), General Ledger (read/write/setup checkboxes), Payroll (read/write/setup checkboxes), Inventory (read/write/setup checkboxes). The things you find... :)
So, that's one less thing to worry about! :)
As for your CRM question: 1. I haven't looked that deeply into the core osERP code to see everything it can or cannot do. 2. I, honestly, haven't touched any sorts of CRM package in a long time to see what they can and cannot do and/or how easily they would be to include. HOWEVER, when I spoke to the original writers a while back, they said they were looking at "XCRM"?? (which I've not looked into) and another mentioned SugarCRM.
Goals:
1. Our first (and current) goal is to get osERP running with osCommerce 2.2MS2. The current version of osERP is fairly "stable" in that there aren't that many bugs (in the ERP side) and not much is needed to change to keep it "updated" as the writers left so many customizable options that it's fairly simple (i.e. the sales/payroll taxes are not "hardcoded", in fact, not much is "hardcoded" AT ALL). The original writers obviously had the future in mind for this app! That is GREAT for us, as our only job is to made it adaptable to the current osCommerce version. (Of course, if we find something else that needs changing, we'll change it.)
2. IF osCommerce upgrades to MS3 before or immediately after we are done (I have NOTHING to base this on, just offering an "IF") then we will work on and release an updated version as well. (Thereby offering TWO releases for two different osCommerce MileStones). We can either begin working on this immediately after we finish the MS2 version or after we include a CRM...
3. Implement some CRM package that can easily be separate (code-wise) from osCommerce and osERP, BUT be easily configured to use the same database so that upgrades to that CRM will still be possible. (We do not want to shoot ourselves in the foot by implementing a current version CRM and customizing it so dramatically that future upgrades of the CRM are impossible. That is what we're trying to fix in osSUITE right now.)
4. Any future features we need/want. :)
--Brandi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Brandi.
I'm all for not shooting myself in the foot...
I couldn't believe I missed those options when you pointed them out for the permissions...!!!
Feel silly...
I looked into what was left of any reference towards xcrm, for those just tuning in.. what I found was a complete crm module pack for lotusnotes domino server... big 20 something MB nsf file... Don't have one running so I didn't play wit it..
I do have a question if I may...
I have Apache 2.0 on a RH9 server mysql 3.23.54
php4.... and I can't logon...
It took some doing just to get the setup to load passed the first screen...
I've even tried migrating a known good install, flushing the permissions and rebuilding the .sql with the 2003 upgrade...
1.01-1.02_upgrade..
Oserp just reloads login screen on login, osadmin has session and header errors, the old 'session headers already sent by [blah blah filename]'
Anything I missed in the posts other than the WAMP configuration dialogue some month ago??
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The osSuite that we are currently working with is a combination of an old Nola version and an old osCommerce version. What the original developers did was use the Nola as the "core" and "added" the osCommerce store portion. This means that they used the Nola database structure and changed the osCommerce to use Nola's database structure. This changed nearly all of the code in osCommerce.
In order to upgrade osSuite to use the most current options that are available in the current version of osCommerce, we would have to rewrite almost the entire osAdmin and osCatalog.
The current version of osCommerce ALREADY includes the "osAdmin" and "osCatalog" portions of osSuite and they are much more updated with many more options available. The only part of osSuite that the current version of osCommerce is missing is the osERP part.
The reason for JUST changing the osERP to work with the current version of osCommerce is twofold:
1. Nola is outdated and development has ceased and the original osCommerce version that osSuite is based off of (back then it was called "The Exchange Project" or "TEP") is radically outdated and also unsupported.
2. The current version of osCommerce is currently in development, supported, and has a plethora of users/developers/contributors that are writing code for it every day.
I see no reason to go back and retouch all of the osAdmin and osCatalog code in order to do something that's already available (and stable) in the current version of osCommerce. In order to make osERP work with the current version of osCommerce, we merely need to ADD to the current osCommerce database structure to include what osERP needs to run and we would have to rewrite ONLY the SQL code for osERP. It will be MUCH less work to do it this way, thereby being much faster to get it operational. We would also have tons of help from the osCommerce users/developers/contributors who are interested in having an ERP backend to their store.
The osERP is not the most important part of the store, however, it is the only part of the Suite that is not already currently available in the current version of osCommerce.
Let me know your thoughts!
--Brandi
Pedroix had previously posted this message at:
https://sourceforge.net/forum/message.php?msg_id=3183139
Brandi:
1) Thanks for the background.
2) "In order to make osERP work with the current version of osCommerce, we merely need to ADD to the current osCommerce database structure to include what osERP needs to run and we would have to rewrite ONLY the SQL code for osERP".
When somebody says that something like linking two systems like these is going to be easy, I normally doubt it.
But I admit that it will certainly be easier.
I think we will put osERP connect to osC database, arrange the tables with a prefix maybe.
Can't see much of the need of changing the SQL code, but maybe you know something I don't.
Connecting the whole, that will be the challenge.
For starters we will have to figure out a way for sharing the session, or would we use the login for each separate module as it is?
I guess we are going to have a bit of a conversation going on around this.
I am gonna grab a stable ver. of osC and get in touch with the new code.
Walt:
Thanks for the links, I will dig on these.
Sorry for the naive questions.
Pedro A.
godzhand had previously posted this message at:
https://sourceforge.net/forum/message.php?msg_id=3185163
May I???
Maybe I'm too enterprise minded... and please correct me at anytime...
SESSION: sharing should not really be considered if both apps are not one app as a whole.. eg
When implementing such, your OsC user shoild not have access to your ERP... its actually a BS7799 faux pas..
In a team oriented environment, I would not give my OsC admin keys to my kingdom. After all there is just way too much legal information involved in the OsERP. Like bcc'ing the entire company the payroll section [as a for instance]
Hence the login for each seperate module...
Naivete is the key to growth... and that's coming from a neophyte...
you people are amazing... I look forward to monitoring and if at any length possible helping in any way I can...
Dan--
I agree that this won't be "EASY", however it will be "EASIER". *GRIN*
If we use a prefix it will defeat the purpose of integrating the two, unless you are speaking of only those tables dedicated to osERP that do not use the osC (payroll, etc.).
We will have to change the SQL code in two ways; initially to update the table/field names to reflect any changes there, and also (I believe) when osC releases their Milestone3 (not sure if this is in the SQL or the PHP yet, I haven't dug that far yet).
Connecting really won't be an issue (again, I THINK) because the two systems are fairly independent, other than they use the same database and pull the same data. Sessions won't be affected at all. You will always need to login to EITHER the admin side of osC or the osERP side. As Dan (godzhand) mentions above, they shouldn't be TOO integrated, for the purposes of security. (Example: I currently have my brother entering products into my store via my osC admin account. I do NOT necessarily want him digging into the payroll section of osERP and changing his paychecks. *GRIN*)
We will go ahead and change osERP to use the osCommerce 2.2MS2 version for now. When 2.2MS3 releases (whenever that is) we'll update our version and offer it separately. (i.e. we'll support both versions for a while) This is because so many people have 2.2MS2 and have modified it so heavily that they may not want to upgrade to MS3 in the near future.
My test site http://www.brandiruppell.com/ossuite offers links to the osCommerce 2.2MS2 version of the admin and catalog sections. You can play with it to see how it works and then download it from osC and play with the code. Honestly, I don't think we'll have to change that much, if any, osCommerce code.
I'm also very enterprise minded. I have worked for some VERY large companies where security was an absolute necessity. I'm looking at this solution from a "company" standpoint, as I am planning on having several employees with several different "rights". Just because the majority of osCommerce users are home-based businesses and/or single employee businesses does not mean that we should slack on security measures that medium to large sized businesses would insist on. This project summary states that this is written for small to medium sized businesses (written as "enterprises") so we need to keep those medium sized biz's in mind.
Let me know your thoughts!
--Brandi
Hi Brandi,
Excellent, I appreciate everything you said... User rights within osERP is / was my next point of reference...
Being a neophyte I have no idea of how difficult it would be to develop the rights for A/R, A/P, Personell Dept., admins and managers and or any other misc. users which can contribute and extrapolate the business information... This can be a quandry when generating KPI's or Key Performance Indicators through various reports...
I'm going to tangent here a sec please forgive... CRM would you consider osERP classified to handle the in-between needs of such? I've been using SugarCRM...
[http://sugarcrm.com], Class act that app...
Being a work in progress... can there be any tie ins for such an app.. as well as the jpgraph implementation for a dashboard like repository reporting schema?
Is it worth it, time and effort... keeping it simple is such a desirable state and maintaining focus is paramount...osERP is no simple matter as it is as you stated, let I not distract from the primary current goal...
I get carried away sometimes... must be all that darn reading...
Dan---
Users and Rights:
Lo and Behold, when you dig deeper into something and stop "skimming" through it you find what you're looking for. :)
The original writers DID include the ability to add users and RIGHTS! Look under the "Admin" tab. The first option is "Users and Rights", beneath the "Edit Selected User" button there is a small "Add new user". Here you find where you can add:
username, password, language, active (yes/no), supervisor (yes/no), accounts payable (read/write/setup checkboxes), Accounts Receivable (read/write/setup checkboxes), General Ledger (read/write/setup checkboxes), Payroll (read/write/setup checkboxes), Inventory (read/write/setup checkboxes). The things you find... :)
So, that's one less thing to worry about! :)
As for your CRM question: 1. I haven't looked that deeply into the core osERP code to see everything it can or cannot do. 2. I, honestly, haven't touched any sorts of CRM package in a long time to see what they can and cannot do and/or how easily they would be to include. HOWEVER, when I spoke to the original writers a while back, they said they were looking at "XCRM"?? (which I've not looked into) and another mentioned SugarCRM.
Goals:
1. Our first (and current) goal is to get osERP running with osCommerce 2.2MS2. The current version of osERP is fairly "stable" in that there aren't that many bugs (in the ERP side) and not much is needed to change to keep it "updated" as the writers left so many customizable options that it's fairly simple (i.e. the sales/payroll taxes are not "hardcoded", in fact, not much is "hardcoded" AT ALL). The original writers obviously had the future in mind for this app! That is GREAT for us, as our only job is to made it adaptable to the current osCommerce version. (Of course, if we find something else that needs changing, we'll change it.)
2. IF osCommerce upgrades to MS3 before or immediately after we are done (I have NOTHING to base this on, just offering an "IF") then we will work on and release an updated version as well. (Thereby offering TWO releases for two different osCommerce MileStones). We can either begin working on this immediately after we finish the MS2 version or after we include a CRM...
3. Implement some CRM package that can easily be separate (code-wise) from osCommerce and osERP, BUT be easily configured to use the same database so that upgrades to that CRM will still be possible. (We do not want to shoot ourselves in the foot by implementing a current version CRM and customizing it so dramatically that future upgrades of the CRM are impossible. That is what we're trying to fix in osSUITE right now.)
4. Any future features we need/want. :)
--Brandi
Hi Brandi.
I'm all for not shooting myself in the foot...
I couldn't believe I missed those options when you pointed them out for the permissions...!!!
Feel silly...
I looked into what was left of any reference towards xcrm, for those just tuning in.. what I found was a complete crm module pack for lotusnotes domino server... big 20 something MB nsf file... Don't have one running so I didn't play wit it..
I do have a question if I may...
I have Apache 2.0 on a RH9 server mysql 3.23.54
php4.... and I can't logon...
It took some doing just to get the setup to load passed the first screen...
I've even tried migrating a known good install, flushing the permissions and rebuilding the .sql with the 2003 upgrade...
1.01-1.02_upgrade..
Oserp just reloads login screen on login, osadmin has session and header errors, the old 'session headers already sent by [blah blah filename]'
Anything I missed in the posts other than the WAMP configuration dialogue some month ago??