robinsonvendredi

En effet mais c'est souvent dû aux habitudes de l'entreprise qui ne veut pas abandonner ses "vieux" logiciels, même si les bases de données sont éparses. Le cas le plus simple c'est en effet la gestion des contacts, mais tout ce qui touche à la gestion étant "sacré", il est difficile de faire changer toutes ces habitudes en général. Le problème c'est qu'il n'existe pas aujourd'hui de logiciel Open Source ou abordable qui réconcilie le monde du web avec celui de l'informatique de gestion. Donc la seule solution est en effet le "home made"...et vivent les "petits" développeurs !!!

J'ai eu une expérience semblable, je pense qu'un virus avait atteint la partition cachée. J'ai dû formater tout en NTFS à partir d'un CD linux , puis repartir sur les drivers téléchargés sur Internet (j'ai un IBM), et depuis tout est OK. Voilà ma modeste expérience, je ne prétends pas être un expert mais si cela peut te servir...

Ce principe est très sûr en termes de performances, mais de mon point de vue, une jointure faite sur un champs varchar avec une contrainte d'unicité et une indexation (par exemple un champs référence) sera tout aussi performante. La clé étrangère sur la table garantit en plus l'intégrité des deux tables en cas de suppression d'enregistrement, par exemple. Mais elle n'est pas absolument nécessaire pour une bonne jointure. Pour le reste, 100 % d'accord avec Therec.

A ma connaissance la banque populaire utilise le soft SIPS ATOS, utilisé par la plupart des banques. Il n'y a rien de spécifique dans la mise en oeuvre de ta solution. Consulte les posts précédents à ce sujet. As tu reçu la documentation du programme, avec les certificats ? Est-ce que le soft est intallé sur ton serveur ?

C'est réalisable puisque EBP propose en partenariat avec un éditeur ASP une solution e-commerce. Pour interfacer la gestion commerciale, il existe 2 difficultés : - la techno EBP de base de données est un ensemble de fichiers (à ma connaissance), et contrairement à une bdd client-serveur telle que sql server ou oracle par ex, l'accès direct aux données (surtout en écriture) est instable et nécessite de réindexer les fichiers à tout bout de champ. - entre deux synchronisations, les données sont fausses (les stocks notamment), aussi bien sur le site que dans la gesco. Tu ne peux envisager ce genre de solutions que pour un site réalisant très peu de transactions. La vraie solution est de re-développer toutes les fonctionnalités de gestion nécessaires au niveau web et d'interfacer la comptabilité et non plus la gestion commerciale. En termes de temps de développement, ça se compte en années, je peux en témoigner !!

La partie client du logiciel s'installe sur ton serveur. Elle permet de crypter les variables lors de l'envoi, selon une clé de chiffrement. Le paiement s'effectue sur le serveur de la banque (la fameuse boutique). Au niveau graphique il existe des possibilités d'adaptation : insérer ton logo, notamment. Au stade de préproduction, il est possible de mener plus loin la personnalisation graphique. Toutefois pour ne pas "discréditer" ton site, je te conseille justement de ne pas trop modifier l'aspect de la boutique. Cette interface est en effet bien connue des internautes et rassure l'acheteur.

Le programme s'installe sur ton serveur (vérifie avec ton hébergeur s'il l'accepte en cas de mutualisé). Il est à demander par ton client au CIC, ce qui suppose un contrat et un abonnement. Je ne connais pas Paybox à fond, mais je pense que ce qui suit s'y applique aussi. L'installation du module de paiement est relativement simple et peut se faire en quelques heures lorsqu'on a l'habitude. Il y a une documentation décrivant les variables à passer au serveur de la banque, et les variables en retour. Ton effort consistera probablement à adapter les exemples fournis à ton propre cas. En ce qui me concerne, je flague la commande comme étant "impayée" durant le traitement de la banque, puis "Payée" au moment où je reçois le code retour OK. Au niveau du délai, il y a une procédure à respecter : d'abord tu peux tester ton installation sur une "boutique" de démo (sur le serveur de la banque), puis tu demandes le passage en préproduction, cette fois c'est ta boutique qui fonctionne mais à blanc, puis c'est le passage en production et cette fois les CB sont réellement débitées. Cette dernière étape ne peut être activée que certains jours de la semaine. Une fois le contrat signé par ton client, tout ceci peut prendre une bonne semaine voire plus. J'espère t'avoir rassuré !!

Il est illégal d'utiliser des moyens de paiement comptant (chèque , CB) pour des règlements à terme. Dans certains cas un système de boutique avec pour seul méthode de règlement, le paiement comptant , n'est pas adapté, surtout si tu t'adresses à une clientèle de professionnels

On distingue d'abord la TVA sur les biens et services dits "immatériels" des autres biens et services. Par ailleurs, selon le pays destinataire (CEE, autres), le régime d'assujettissement à la TVA de ton client, (s'il est professionnel), l'application de la TVA se fera ou pas. Enfin, la possibilité t'est offerte d'opter pour un régime fiscal de franchise de TVA à l'exportation, sous ceraines conditions. Bref, il existe de nombreux cas de figure, renseigne-toi auprès de ton expert comptable ou de ton centre des impôts.

Le logiciel doit aussi prendre en charge la TVA. Le taux dépend du produit, de la zone de livraison, éventuellement de la zone d'expédition, du profil du client... Selon les logiciels, ces fonctions demandent un peu de développement spécifique.

C'est plutôt un comparateur de produits si j'ai bien compris. La partie catalogue d'un logiciel de e-commerce ne sera pas adaptée, en revanche pour les marchands qui te fourniront un catalogue sur excel (ou autre) , le traitement des données relève en effet du "métier" de l'e-commerce, mais je ne crois pas que tu trouveras facilement un logiciel pour te mâcher le boulot. Beaucoup de développement sur mesure à mon humble avis. Bon courage!...

J'ai un plan reseller chez http://www.hostroute.co.uk/ depuis plusieurs années, sans problème particulier.

Déjà un premier truc qui me semble bizarre Tu pourrais avoir plusieurs résultats pour : Select lb_langage.`id_langage` From lb_langage Where lb_langage.`nom_langage` Like p_langage; Donc impossible de les charger sur une seule variable En principe SELECT INTO insère dans une table

Si tu as des astuces blondes avec de fortes poitrines pour packager SQL express, ça m'interesse aussi

essaie "xml database" dans GG. Apparemment il existe des bases de données XML qui pourraient faire l'affaire ?? IL existe un exmeple de logiciel de gestion 100 % XML (à ma connaissance) : exchequer http://business.iris.co.uk/products/excheq...enterprise.aspx <edit> info erronée, ils ont passé la bdd sur pervasive </edit>

Je crois que EASY GROUP WORK est plutôt un workgroup : agenda partagé, mail ,etc... mais pas une GED. Voici les GED en Open source que je connais (un peu) : OpenGed, Maarch, Alfresco. OpenGed et Alfresco ont ma préférence mais c'est du java. Seul Maarch est en php Selon tes compétences en développement, et le cahier des charges, l'un ou l'autre de ces logiciels peut te convenir Pour ce qui est du choix du serveur et de sa maintenance , Dan serait mieux à même de donner un conseil.

C'est tout le problème des applications de gestion made in US ou Open source. Au niveau de la langue ça peut se corriger, mais au niveau comptabilité, c'est rarement possible.

Pour le serveur web tu auras peut être affaire à Tomcat. Commence par installer java SDK et Tomcat, puis il y a des exemples de pages du genre "hello world" installées par défaut avec Tomcat. Bon courage

Les visuels sont très jolis mais ce n'est pas une référence OScommerce. On peut tout faire avec OSC, oui peut être mais un panier en asp je suis dubitatif... https://www.*ucci.com/fr/shopping_bag.asp

Oui Vtiger est un script intéressant, toutefois il manque dans ton cas une gestion des abonnements, et la partie "facture-relance" est un peu faible à mon humble avis. Il faudrait un module de règlement et comptabilité pour prendre en charge correctement la facturation et les relances. Sugar CRM ne résoud pas le problème non plus.

Pars plutôt d'un logiciel puissant pour éviter de réinventer la roue à chaque client. Si tu pars d'un logiciel trop simple il ne te servira pas grand chose, la partie "panier de commande" et "paiement en ligne" n'est que la partie visible de l'iceberg, et pas la plus compliquée à développer. Avec cette approche dès le premier client tu vas manquer cruellement de fonctionnalités. L'autre approche consiste à partir d'un framework avec des objets de bas niveau réutilisables d'un projet à l'autre. Dans ce cas c'est à toi de développer tous tes modules (panier compris) avant de penser à chercher des clients... De toute manière il faut investir du temps, soit en autoformation sur un logiciel puissant, soit en développement préalable de nombreux modules... Bon courage

Je pense qu'il en existe des dizaines voire des centaines de milliers. Cherche shopping cart sur Google...Mais quel est le but de ta question ? Tout dépend de tes besoins, car si on considère les scripts adaptés + les logiciels standard + les savoirs-faires de telle ou telle agence, il y en a peut être encore plus ! voire même autant que de clients...

Pour un dév de A à Z, il faut définir une table "zones géographiques" avec des paramétrages propres à chaque zone : - frais calculés (#poids) et/ou frais forfaitaires, franco de port, coefficient d'assurance, conditions de livraison contractuelle dont incoterms, langue des documents commerciaux tels que facture, facture pro-format, bon de livraison, devise de paiement, banque, mode d'expédition. Idéalement tu peux aller jusqu'aux paramétrages comptables, soit pour chaque zone : - un compte de TVA (et donc un taux qui s'applique à la transaction), un compte de produit, et un compte de transport sur vente. - tu dois pouvoir déterminer pour chaque produit quelles sont les zones de livraison autorisées et celles qui sont interdites (ce qui peut dépendre de contrats de disribution, de normes industrielles, etc...) Pour ce qui est du mode d'expédition, si tes produits sont légers et assez chers, FEDEX est une solution possible : Fedex fournit une API qui te dispense des calculs de tarif.

oui tu te trompes. SQL est utilisable avec une base de données, et pas directement sur des fichiers XML. Si tu n'as pas un niveau expérimenté en XML, oublie l'idée de développer un moteur de recherche. Pour développer un moteur de recherche, (ou utiliser un moteur existant) on utilise généralement une base de données. Commence peut-être par t'intéresser à php avec les bases de données et comment insérer des données dans ta base à partir de fichiers XML...

Si ta base atteint quelques centaines de Mo, tu auras des options à prendre côté hébergement. Pour l'instant, pas d'inquiétude !