[PHP] en office

[gnirts_modnar]

Hallo allemaal,

Verassend genoeg heb ik een probleem, ik werk al een tijdje aan een webbased CRM voor een klant van mij. Die klant kwam met het idee, dat het heel mooi is, als het mogelijk zou zijn om tussen het CRM en de office applicaties data heen en weer te kunnen gooien. Goed idee natuurlijk, dus ik snel een CSV en een tabs seperated presenter aan mn framework toegevoegd. En dat werkt tot op zekere hoogte. Nu willen zij naast de bezoekrapporten en de telefoontjes, de mailtjes naar de klanten ook in het CRM hebben, en wat zou het niet gemakkelijk zijn als het CRM dit soort dingen zou kunnen afvangen en in de DB op zou kunnen slaan.

Verder willen ze graag nog wat andere dingen tussen het CRM en office applicaties heen en weer gooien. Bijvoorbeeld agenda items en taken maken. dat soort zaken.

Even terzijde mijn CRM staat op een Debian bak, maar mn linux / samba kennis houd op bij putty ls -l en chown / chmod.

Ik had zelf aan een soort tussen servicesje gedacht. Ik weet namelijk dat je met system() in php de commandline kan benaderen, en je met visual basic (i know it's crappy) dingen naar office kan krijgen. Ik denk echter dat dit redelijk omslachtig word en ook misschien wel erg lastig gezien dit allemaal op een Linux bak staat.

Ik vroeg mij af of jullie bekend waren met dit soort zeken en misschien een oplossing hadden.

[Verwijderd]

Ik zou ook kiezen voor een soort mail proxy achtig iets. Dus de mail wordt opgevangen -> in het systeem gezet -> opgehaald door outlook (?).
Ik heb ook een tijdje zitten spelen met zo'n idee. Is het niet op de een of andere manier mogelijk om de mail van de inbox van de klant op te halen, en dan een pop3/imap service aan te bieden vanaf jouw server(s)?

Als 't IMAP is kan je 't sowieso wat eenvoudiger aanpakken. Voor zover ik weet haal je IMAP niet meer op, maar blader je gewoon op de server. Dan zou je dus aan de hand van een mailID oid (die mail moet toch een key hebben lijkt me) de e-mail kunnen koppelen aan je contacten.

Een andere mogelijkheid zou zijn om een 'import' te doen van e-mails op een regelmatig interval (ieder uur ofzo?). Dan moet je dus een (php) scriptje maken dat voor alle gebruikers de mail ophaalt van hun mail-server en de gegevens daarvan invoert in je database. Dan moet je echter wel zorgen dat de gebruikers hun e-mail client de mail niet laten verwijderen van de server, tenzij deze ouder is dan pakweg een dag (ruime marge).

Disclaimer: Ik ben geen expert, dit is gewoon actief meedenken en hopelijk je een richting op sturen

[ Voor 22% gewijzigd door Verwijderd op 02-06-2007 01:35 ]

[gnirts_modnar]

Nouja ze gebruiken exchange, en ik ben ook niet echt een exchange whizz. Maar het klinkt allemaal vrij aannemelijk. However ik ben bang dat het vrij ingewikkeld is, omdat ze echt een vrij complex mail systeem hebben.

Het is misschien wel iets om bijvoorbeeld terwijl ze dat mailtje sturen.. een tweede mail naar de deb. server. te sturen en die in het systeem te plaatsen. Of bijvoorbeeld een ftp verbinding openenen en de mailtjes dan storen.. en die met een cronjob importeren.

Maar de vraag blijft.. hoe mod je outlook zo dat het dat soort acties kan doen. Lijkt mij met een service, die nieuwe mails detecteerd.. maar hoe en met welke taal..

P.S. Dit is een lange termijn project dus ik heb alle tijd om me te verdiepen in een nieuwe programmeertaal

[ Voor 16% gewijzigd door gnirts_modnar op 02-06-2007 09:51 ]

[djluc]

Ik zou dat op de server (exchange) regelen. Daarmee is het simpel om van alle mail ook een duplicaatje in een aparte mailbox te plaatsen. Die lees je gewoon uit met IMAP of POP3 en je bent klaar. Ik zou IMAP doen dan kan je een soort transactie bouwen. Je leest dan eerst de mail uit en verwerkt deze. Als dit goed is gegaan geef je een delete commando richting de IMAP server. Zo mis je nooit mail.

[ripexx]

Ik zou zeggen bepaal eerst eens goed je FO.

Verder zijn er natuurlijk al zat open source CRM pakketen met enige Office integratie. Verder hebben zo'n beetje alle professionele CRM leveranciers ook integratie met iig Word en Outlook. Daarnaast is de versie van Outlook zeker relevant, vanaf office 2007 kan je namelijk veel meer bereiken met .net spullen dan daarvoor. In versie 2003 en eerder zal je met com plugins aan de slag moeten.

Verder zou het OS van je server, bij een webbased programma, niet mogen uitmaken. Ik snap dat het leuk is om wat dingen te ontwikkelen maar is het dan noet verstandiger dat je een opensource pakket gaat uitbreiden met de functionaliteiten die ze nodig hebben?

Verder zijn opmerkingen als "Een vrij complex mail systeem" natuurlijk onzin. Immers wat is complex? Met je laatste post zit je in principe al redelijk op weg, maar je bent er lang niet, je kan overigens in Exchange gewoon instellen dat alle mail van een bepaald domein of user wordt geforward naar een ander adres. Dan heb je client side iig niets nodig, maar dan moet je alles nog maar op de juiste manier zien te importeren Denk aan mail conversaties, attachments etc wat ga je er allemaal mee doen.

Oftewel maak een FO, en ga dan pas kijken hoe het technisch uitgewerkt moet gaan worden, immers is de techniek nog zelden een belemmering.

[gnirts_modnar]

Allereerst waardeer ik alle reacties, en ik ga ook zeker aan de slag met het exchange imap verhaal. Dit helpt me echter nog niet met taken en gestaardiseerde brieven etc.

Dan het verhaal over 'FO', ik heb geen idee wat je daarmee bedoelt. Mn best guess is Field Objective oid.

Het OS van mn server maakt denk ik wel uit omdat je daar niet simpel een VB service op installeert die via, de system() functie van PHP kan callen voor het maken van taken en agenda items.

Een vrij complex mail systeem wellicht in jou ogen onzin, zit misschien ook wel iets in.. in ieder geval lijkt het me lastig om de juiste parameters te detecteren in een email.. Voor een toevoeging aan het CRM heb je immers iets van een klant id nodig, iets wat je niet makkelijk uit de mail body haalt. Dan moet je gaan denken aan mensen verplichten het klantnummer in het onderwerp te zetten oid. Niet practisch denk ik zelf.

Open source:

Ik ben zelf nooit zo weg van dit soort dingen.. wellicht gebasseerd op een aantal slechte ervaringen, maar misschien heb ik iets grandioos gemist. Geef mij eens een voorbeeld van een goed CRM dat makkelijk aan te sluiten is op de gegevens uit je: Administratieve pakket, je day to day voorraadbeheer inkoop verkoop relatie beheer pakket (hier zit geen CRM in natuurlijk), en je al bestaande website. En dan kan ik kijken of dit de functionaliteit bied die op zn minst vergelijkbaar is met het CRM binnen het framework wat ik nu aan het bouwen ben, zeker gezien het feit dat het CRM slechts een onderdeel is van het pakket waar ik nu aan werk.

[ripexx]

FO = Functioneel Ontwerp

Voor de mail zou ik het zo doen:
Stuur alle mail door naar een apart mail adres op je applicatie server, een SMTP sever is zowel op windows als linux zo geinstalleerd. Drop alle mail in een folder, Ga met een cronjob of windows service eens in de zoveel tijd alle mailtjes langs. En welk veld van een email is altijd gevuld? Het email adres van de afzender en ontvanger Zoek dus je contactpersoon op basis van mail adres voila je hebt een simpele mail import.

Een van de bekendere opensource CRM applicaties is SugarCRM, geschreven in PHP.

Wat betreft aansluiten, de vraag is of je all-in-one wil of best of breed. Kies je voor het laatste dan kan je denken aan views op externe systemen via webservices etc. Kies je voor all-in-one dan zal je alle functionaliteiten moeten maken en onderhouden. Daarnaast zal je er rekening mee moeten houden dat een bedrijfsproces zomaar kan veranderen en dat je applicatie daar ook mee kan omgaan. Je zal dus behoorlijk moeten doordenken, maar ook niet moeten verzanden in onnodige details. Waarbij de opdrachtgever vanuit tijd en budget zal kiezen voor de easy way met alle mogelijke gevolgen van dien.

Daarnaast snap ik niet wat je bedoelt met inkoop-verkoop relatie beheer. CRM is relatiebeheer + een hoop andere zaken als leadtracking en verwerking, contactbeheer, contractbeheer, offerte/oppertunities etc etc.

Maar hoe dan ook, begin eens top down. Bedrijf de processen die je wil gaan automatiseren/infromatiseren. Bekijk welke taken er dan uitgevoerd moeten gaan worden en welke taken bij elkaar horen. Hieruit kan je dan weer informatie halen mbt je FO.

Als je FO goed is kan je beginnen met een TO (Technisch Ontwerp). Meestal uitgevoerd door een architect op analist. Als dat allemaal af is en goedgekeurd is begin je pas met het schrijven van code. Want nu zal je gaan zien dat het voorschrijdend inzicht je heel veel tijd zal gaan kosten.

[gnirts_modnar]

Aha, nou dat (FO) is er al een tijdje hoor, of althans gewoon in mijn woorden een design op papier met welke functionaliteiten er allemaal in het systeem moeten komen en hoe die genamed zijn en zich verhouden tot het framework.

De contactpersoon zoeken op basis van een email adres is nog niet haalbaar aangezien het bedrijf nog geen compleet bestand heeft met alle contactpersonen en al helemaal niet alle emailadressen, verder lijkt me dit ook tamelijk buggy.. al is het alleen al omdat een klant honderden email adressen kan hebben. (iets wat ook niet in het oude systeem ingevoerd kan worden)

Ik zal zo eens even naar dat Sugar CRM kijken

Over het inkoop verkoop relatiebeheer:

Het huidige systeem, werkt maar bied te kort functionaliteit om alle gegevens in op te slaan, het CRM is bedoelt om alle communicatie met de klant in te verwerken. VB. Offertes staan wel in het huidige systeem, maar de bezoekrapporten of telefoontjes of mailingen naar een klant niet, en de optie om dat oude/eerste systeem uit te breiden is er ook niet. Verder staan de offertes er wel in, maar zijn ze niet te editten, er kan dus maar in een format een offerte gestuurt worden. Er zijn ook geen mogelijkheden om bijvoorbeeld alle adres gegevens van een klant met een bepaalde eigenschap te selecteren.

Dat moet allemaal in het CRM komen, en het CRM is weer een onderdeel van het hele pakket, dat meer een soort uitgebreide functionaliteit toevoegd aan het eerste systeem. De eigenschappen van dit systeem zijn ook allang al beschreven. Soms worden er nieuwe dingen bij bedacht, en dan moet je daar flexibel op in kunnen springen.

[ripexx]

gnirts_modnar schreef op zaterdag 02 juni 2007 @ 20:20:
Aha, nou dat (FO) is er al een tijdje hoor, of althans gewoon in mijn woorden een design op papier met welke functionaliteiten er allemaal in het systeem moeten komen en hoe die genamed zijn en zich verhouden tot het framework.

En op een of andere manier heb ik nog steeds het gevoel als of het op de achterkant van een bierviltje is bedacht. Maar als jij zegt dat je alles hebt beschreven inclusief uitzonderingen dan kom je een heel eind.

De contactpersoon zoeken op basis van een email adres is nog niet haalbaar aangezien het bedrijf nog geen compleet bestand heeft met alle contactpersonen en al helemaal niet alle emailadressen, verder lijkt me dit ook tamelijk buggy.. al is het alleen al omdat een klant honderden email adressen kan hebben. (iets wat ook niet in het oude systeem ingevoerd kan worden)

Tja dat het buggy is, is duidelijk, het gaat ook over de simpele oplossing. Maar als jij Exchange al snel complex vindt en Vb ook weer iets anders is dan weet ik niet zo snel een tussen oplossing. Een echt nette oplossing is natuuurlijk gewoon een Outllok add in in je taskpane oid die bij elk geselecteerde mailtje zoekt naar de best mogelijke match, waarbij iig alle results lokaal gecached worden en je ook direct een contactpersoon kan toevoegen. Alle zit je dan weer met deployment issues, versie verschillen met outlook etc etc.

Ik zal zo eens even naar dat Sugar CRM kijken

Kijk er maar eens na en begin aub niet direct alle excuses te vinden want dan kijk je er echt verkeerd naar. Als je binnen een dag al roep: "Maar dit kan niet, en dat werk ook niet lekker" of iets van die strekking dan kijk je door de bril van een programmeur ipv die van de eindgebruiker!

Over het inkoop verkoop relatiebeheer:

Het huidige systeem, werkt maar bied te kort functionaliteit om alle gegevens in op te slaan, het CRM is bedoelt om alle communicatie met de klant in te verwerken. VB. Offertes staan wel in het huidige systeem, maar de bezoekrapporten of telefoontjes of mailingen naar een klant niet, en de optie om dat oude/eerste systeem uit te breiden is er ook niet. Verder staan de offertes er wel in, maar zijn ze niet te editten, er kan dus maar in een format een offerte gestuurt worden. Er zijn ook geen mogelijkheden om bijvoorbeeld alle adres gegevens van een klant met een bepaalde eigenschap te selecteren.

Waarom begin je dan niet opnieuw ipv gaten te vullen met maatwerk applicaties. Bekijk de architectuur en bepaal wat je nodig hebt maar ga niet het ene gat met het andere vullen. Maak een duidelijke kosten baten analyse voor de komende drie of vijf jaar inclusief manpower etc. en kijk dan nog eens opnieuw. Ik ben ik mij werk al te vaak dit soort dingen tegen gekomen.

Dat moet allemaal in het CRM komen, en het CRM is weer een onderdeel van het hele pakket, dat meer een soort uitgebreide functionaliteit toevoegd aan het eerste systeem. De eigenschappen van dit systeem zijn ook allang al beschreven. Soms worden er nieuwe dingen bij bedacht, en dan moet je daar flexibel op in kunnen springen.

Ik krijg weer de kriebels van je opmerkingen als "nieuwe dingen", "flexibel" en zie nu al dat je na afloop het volgende te horen krijgt: "ICT projecten duren altijd twee keer zolang, kosten twee keer zoveel en je krijgt maar de helft van je functionaliteit". Daarnaast is CRM niet zomaar iets bouwen of inrichten. De metaliteit van de medewerkers moet veranderen en dat is vaak nog het aller lastigste. Je kan nog wel zo'n mooi product neer zetten maar als het niet (goed) gebruikt wordt, heb je er ook niets aan.

Maar als laatste nog even terug op de kern van de zaak.

Office aansturing (word en excel) kan veelal via IE met behulp van ActiveX compeneten van Microsoft. De voorwaarde is wel dat het IE only is. Maar dat is zakelijk nog steeds niet onoverkomelijk voor een web-applicatie.
Email koppelingen met Outlook kan je via op een aantal manieren doen:
* Doorsturen en dan uitlezen in je applicatie via (POP, SMTP drop, IMAP etc)
* Outlook addin maken (com object)
* Exchange addin maken

Voor alle oplossing is genoeg op het web te vinden.

[gnirts_modnar]

ripexx schreef op zaterdag 02 juni 2007 @ 22:20:
En op een of andere manier heb ik nog steeds het gevoel als of het op de achterkant van een bierviltje is bedacht. Maar als jij zegt dat je alles hebt beschreven inclusief uitzonderingen dan kom je een heel eind.

Haha, ja ik kan dat ook wel enigszins begrijpen. Ik vind het altijd lastig dit soort dingen uit te leggen, maar ik ga het toch proberen. Het is een klein bedrijfje, en omdat ik student ben, en dus nog redelijk weinig verdien, hebben ze liever dat ik wat tijd in een dergelijk systeem steek, dan dat ze iets ervoor aan moeten schaffen. We hebben grondig onderzoek gedaan zodat we nu, eerdere oplossingen allemaal kunnen intergreren in het nieuwe systeem. En de extra's, waaronder een CRM voor het hele bedrijf ipv alleen voor de buitendienst, daar ook naadloos bij aansluiten.

Tja dat het buggy is, is duidelijk, het gaat ook over de simpele oplossing. Maar als jij Exchange al snel complex vindt en Vb ook weer iets anders is dan weet ik niet zo snel een tussen oplossing. Een echt nette oplossing is natuuurlijk gewoon een Outllok add in in je taskpane oid die bij elk geselecteerde mailtje zoekt naar de best mogelijke match, waarbij iig alle results lokaal gecached worden en je ook direct een contactpersoon kan toevoegen. Alle zit je dan weer met deployment issues, versie verschillen met outlook etc etc.

Zoals ik al eerder heb verteld, vind ik het niet erg ergens tijd in te investeren, binnen het bedrijf krijg ik alle ruimte om nieuwe technieken te leren, waarschijnlijk omdat ik erg goedkoop ben als student. Ik denk dat er niet veel dingen echt complex kunnen zijn als je de tijd hebt om je er in te verdiepen. Die heb ik dus, exchange zal ik, uiteindelijk ook wel begrijpen zeker omdat ik het zelf geinstalleerd heb. Hoewel dat ook niet echt veel zegt. (installeren is vrij gemakkelijk).

Kijk er maar eens na en begin aub niet direct alle excuses te vinden want dan kijk je er echt verkeerd naar. Als je binnen een dag al roep: "Maar dit kan niet, en dat werk ook niet lekker" of iets van die strekking dan kijk je door de bril van een programmeur ipv die van de eindgebruiker!

Dat zal ik zeker doen, maar zoals eerder verteld, willen ze graag het allemaal in een systeem krijgen. En daarom is het nog maar de vraag of dat binnen een opensource CRM gaat lukken. Ik zal niet te kritisch doen en er echt serieus naar kijken.

Waarom begin je dan niet opnieuw ipv gaten te vullen met maatwerk applicaties. Bekijk de architectuur en bepaal wat je nodig hebt maar ga niet het ene gat met het andere vullen. Maak een duidelijke kosten baten analyse voor de komende drie of vijf jaar inclusief manpower etc. en kijk dan nog eens opnieuw. Ik ben ik mij werk al te vaak dit soort dingen tegen gekomen.

Dat ben ik volledig met je eens, en daarom zou mijn voorkeur ook uitgaan naar een totaal nieuw pakket. Het probleem is echter dat het bedrijf verplicht is de software voor in en verkoop te gebruiken door een inkooporganisatie / leverancier.

Ik krijg weer de kriebels van je opmerkingen als "nieuwe dingen", "flexibel" en zie nu al dat je na afloop het volgende te horen krijgt: "ICT projecten duren altijd twee keer zolang, kosten twee keer zoveel en je krijgt maar de helft van je functionaliteit". Daarnaast is CRM niet zomaar iets bouwen of inrichten. De metaliteit van de medewerkers moet veranderen en dat is vaak nog het aller lastigste. Je kan nog wel zo'n mooi product neer zetten maar als het niet (goed) gebruikt wordt, heb je er ook niets aan.

Ook dat ben ik met je eens, maar ik kan je nogmaals verzekeren dat hier al de nodige tijd met de eindgebruikers over gepraat is, en het is ook zo dat er nu iets gevraagd word, in de trend van.. is dit mogelijk, als eventuele aanvulling. Mijn reactie is dan dat ik dat ga inventariseren, en zo komt deze vraag hier terecht. Ook de mentaliteit van de medewerkers is inderdaad belangrijk, maar zij samen met mij en de rest van het management team, gevraagd om dit systeem, dus ik denk dat dat wel goed zit.

Maar als laatste nog even terug op de kern van de zaak.

Office aansturing (word en excel) kan veelal via IE met behulp van ActiveX compeneten van Microsoft. De voorwaarde is wel dat het IE only is. Maar dat is zakelijk nog steeds niet onoverkomelijk voor een web-applicatie.
Email koppelingen met Outlook kan je via op een aantal manieren doen:
* Doorsturen en dan uitlezen in je applicatie via (POP, SMTP drop, IMAP etc)
* Outlook addin maken (com object)
* Exchange addin maken

Voor alle oplossing is genoeg op het web te vinden.

Kijk dit wil ik nu graag horen, het punt is dus dat ik niet zoveel vertrouwen heb in het door mail idee, tenzij het een apparte datamail word ipv een kopie waar bij gebruikers bijv. eerst gepromped worden voor een klantnummer oid.

Als er over het tweede en derde ding zat te vinden is op internet zal ik jullie er niet meer mee storen. En ga ik hier verder zelf mee aan de slag.

Ik vraag me wel af of deze punten het probleem dekken. Er moet namelijk met meer dingen als alleen outlook en/of exchange gecommuniceert worden.

[ripexx]

gnirts_modnar schreef op zaterdag 02 juni 2007 @ 23:03:
[...]
Haha, ja ik kan dat ook wel enigszins begrijpen. Ik vind het altijd lastig dit soort dingen uit te leggen, maar ik ga het toch proberen. Het is een klein bedrijfje, en omdat ik student ben, en dus nog redelijk weinig verdien, hebben ze liever dat ik wat tijd in een dergelijk systeem steek, dan dat ze iets ervoor aan moeten schaffen. We hebben grondig onderzoek gedaan zodat we nu, eerdere oplossingen allemaal kunnen intergreren in het nieuwe systeem. En de extra's, waaronder een CRM voor het hele bedrijf ipv alleen voor de buitendienst, daar ook naadloos bij aansluiten.
[...]
Zoals ik al eerder heb verteld, vind ik het niet erg ergens tijd in te investeren, binnen het bedrijf krijg ik alle ruimte om nieuwe technieken te leren, waarschijnlijk omdat ik erg goedkoop ben als student. Ik denk dat er niet veel dingen echt complex kunnen zijn als je de tijd hebt om je er in te verdiepen. Die heb ik dus, exchange zal ik, uiteindelijk ook wel begrijpen zeker omdat ik het zelf geinstalleerd heb. Hoewel dat ook niet echt veel zegt. (installeren is vrij gemakkelijk).
[...]
Dat zal ik zeker doen, maar zoals eerder verteld, willen ze graag het allemaal in een systeem krijgen. En daarom is het nog maar de vraag of dat binnen een opensource CRM gaat lukken. Ik zal niet te kritisch doen en er echt serieus naar kijken.

Maar denk er maar eens rustig overna. Als jij namelijk alles zelf moet uitdenken en ontwikkelen kost dat ook tijd. Dan kanje beter je tijd steken in het koppelen van een CRM pakket aan de andere applicaties dan eerst zelf een pakket ontwikkelen en dan nog eens de koppelingen. Hoewel het laatste natuurlijk een leuke uitdaging is

[...]
Dat ben ik volledig met je eens, en daarom zou mijn voorkeur ook uitgaan naar een totaal nieuw pakket. Het probleem is echter dat het bedrijf verplicht is de software voor in en verkoop te gebruiken door een inkooporganisatie / leverancier.
[...]
Ook dat ben ik met je eens, maar ik kan je nogmaals verzekeren dat hier al de nodige tijd met de eindgebruikers over gepraat is, en het is ook zo dat er nu iets gevraagd word, in de trend van.. is dit mogelijk, als eventuele aanvulling. Mijn reactie is dan dat ik dat ga inventariseren, en zo komt deze vraag hier terecht. Ook de mentaliteit van de medewerkers is inderdaad belangrijk, maar zij samen met mij en de rest van het management team, gevraagd om dit systeem, dus ik denk dat dat wel goed zit.

Dan komt het wel goed

[...]
Kijk dit wil ik nu graag horen, het punt is dus dat ik niet zoveel vertrouwen heb in het door mail idee, tenzij het een apparte datamail word ipv een kopie waar bij gebruikers bijv. eerst gepromped worden voor een klantnummer oid.

Met zo'n com object kan je alle kanten op. Je kan een button toevoegen aan je toolbar waarmee je een actie uitvoert. Dan kan je ook een dialog maken met ruimte voor een klantnummer. Alle data uitlezen uit de mail en via een webservice voeren aan het betreffende systeem. Het model van Outlook is soms wat onoverzichtelijk maar heeft ook zijn voordelen. Alles is een item (mail, taak, afspraak, contactpersoon) en wordt geplaatst in een folder. Dus een nieuwe contact persoon is niets anders dan een object van het type contact plaatsen in een bepaalde folder. Hetzelfde geldt ook voor een email.

Als er over het tweede en derde ding zat te vinden is op internet zal ik jullie er niet meer mee storen. En ga ik hier verder zelf mee aan de slag.

Ik vraag me wel af of deze punten het probleem dekken. Er moet namelijk met meer dingen als alleen outlook en/of exchange gecommuniceert worden.

De meeste grote pakket beschikken op een of andere manier wel over een platform (Integratieplatform, api's etc) waarmee je gegevens kan uitwisselen. Maar kies waarmogelijk voor (open) standaarden ipv vage eigen bedachte constructies. Bedenkt dat bijna alle grote bedrijven in deze wereld al tegen vergelijkbare problemen zijn aangelopen. Probleem is vaak oude branche specifieke software waarbij de leverancier lekke rmoeilijk doet. Maar als ze een beetje DB gebruiken kom je er meestal wel achter. Alleen moet je dan gaan oppassen met eventuele business rules die je niet terug kan vinden in het datamodel, je kan dan namelijk zeer overwachte problemen krijgen.

[gnirts_modnar]

Ja nogmaals bedankt voor alle hulp, rest nog een vraag, in welke programmeer taal kan ik het best gaan bestuderen om uiteindelijk bijvoorbeeld die extensies eventueel in te schrijven. Ik heb een klein beetje ervaring met VB.net maar ik hoor van alle kanten dat het echt een bagger taal is. Ik heb ook al eens gekeken naar C++ maar dat vind ik vrij ingewikkeld programmeren (voor windows applicaties dan). Zelf dacht ik aan C#. daar hoor ik op mijn andere bijbaantje, goede berichten over.

[BikkelZ]

Ik zou het natuurlijk nooit zeggen als ik geld zou willen verdienen, maar CRM systemen die kun je dus echt het beste gewoon kant en klaar kopen.

Geloof me maar.

Zo niet dan heb je over drie jaar genoeg argumenten om het met me eens te zijn.