Bonjour à tous,
J'ai déjà vu des messages concernant des connecteurs avec Magento et Prestashop et que des dévs seraient en cours.
De mon côté, j'aurais (ou plutôt un client aurait) des besoins pour injecter dans un ERP des commandes provenant de Magento, Amazon, ebay et Cdiscount (et potentiellement d'autres ...), des relevés de paiements de diverses banques (paypal, CB, etc). Cet ERP s'occuperait alors de toute la compta (factures, avoirs, rapprochements (lettrage), etc).
Nous avons déjà des scripts qui récupèrent toutes ces informations, et qui pourraient facilement être modifiés pour envoyer ces informations quelque part. Reste à trouver ce quelque part ...
OpenConcerto est-il prévu pour recevoir ce type d'informations d'une manière ou d'une autre (webservice, accès direct BD, etc) ? Ou pouvez-vous me proposer un autre moyen ?
S'il y a du dév à faire, un budget est dispo, et même de la main d’œuvre pour développer :)
Petite question subsidiaire concernant le volume accepté par OpenConcerto : est-il capable d'encaisser environ 10.000 commandes par mois, et ce pendant plusieurs années ?
OpenConcerto et e-commerce
Bonjour,
500 commandes par jour? Ce n'est pas un chiffre effrayant.
OpenConcerto peut les gérer à condition d'utiliser un serveur correct et bien configuré.
Pour ce qui est de l'import des données, 2 choix :
- requêtes SQL directes pour les téméraires
- un module qui utilisera l'API d'OpenConcerto (SQLRowValues, etc...)
Ce qui conditionnera le succès de la chose, c'est surtout le budget du client.
Il y a peut être des cas d'utilisation qui nécessiteront quelques aménagements, mais rien de fondamental.
La maintenance, le manuel, quelques jetons et tout ira bien.
Cordialement,
500 commandes par jour? Ce n'est pas un chiffre effrayant.
OpenConcerto peut les gérer à condition d'utiliser un serveur correct et bien configuré.
Pour ce qui est de l'import des données, 2 choix :
- requêtes SQL directes pour les téméraires
- un module qui utilisera l'API d'OpenConcerto (SQLRowValues, etc...)
Ce qui conditionnera le succès de la chose, c'est surtout le budget du client.
Il y a peut être des cas d'utilisation qui nécessiteront quelques aménagements, mais rien de fondamental.
La maintenance, le manuel, quelques jetons et tout ira bien.
Cordialement,
-
Philippe33
- Messages : 6
- Enregistré le : sam. févr. 22, 2014 8:53 pm
OK, super, me voilà rassuré !
Côté serveur, je m'en occupe. J'ai quelque expérience en admin de bases PostgreSQL de taille conséquente, ça devrait tenir de ce côté là aussi.
Je me sens une âme de téméraire ... l'écriture de procédures PL/PgSQL m'intéresse pour ce cas. Je pourrais écrire un certain nombre de fonctions génériques permettant d'importer des données ou lancer certaines opérations que je devrais lancer en batch (je pense au lettrage par exemple).
Tant qu'à les développer, est-ce qu'il serait intéressant d'utiliser ces fonctions pour commencer un webservice en PL/PgSQL (je n'ai rien contre le fait de publier mes dévs en opensource et qu'ils soient intégrés en standard) ? Pour des raisons de maintenance, je ne voudrais pas me retrouver avec un fork qu'il serait difficile de faire évoluer.
En comparaison à d'autre budgets annoncés avec d'autres solutions ERP opensource, on devrait pouvoir s'en sortir.
J'attends le manuel qui est déjà en commande, et dès le retour de vacances, je regarde ça de beaucoup plus près. Je présume qu'il est préférable de me baser sur la dernière 1.3 beta ? Ou plutôt sur le trunk ?
Bien cordialement
Côté serveur, je m'en occupe. J'ai quelque expérience en admin de bases PostgreSQL de taille conséquente, ça devrait tenir de ce côté là aussi.
Je me sens une âme de téméraire ... l'écriture de procédures PL/PgSQL m'intéresse pour ce cas. Je pourrais écrire un certain nombre de fonctions génériques permettant d'importer des données ou lancer certaines opérations que je devrais lancer en batch (je pense au lettrage par exemple).
Tant qu'à les développer, est-ce qu'il serait intéressant d'utiliser ces fonctions pour commencer un webservice en PL/PgSQL (je n'ai rien contre le fait de publier mes dévs en opensource et qu'ils soient intégrés en standard) ? Pour des raisons de maintenance, je ne voudrais pas me retrouver avec un fork qu'il serait difficile de faire évoluer.
En comparaison à d'autre budgets annoncés avec d'autres solutions ERP opensource, on devrait pouvoir s'en sortir.
J'attends le manuel qui est déjà en commande, et dès le retour de vacances, je regarde ça de beaucoup plus près. Je présume qu'il est préférable de me baser sur la dernière 1.3 beta ? Ou plutôt sur le trunk ?
Bien cordialement
Bonsoir,
je ne suis pas sûr qu'il soit nécessaire de faire du dev aussi dépendant de la base de données.
Autant baser le webservice sur OpenConcerto directement, vous gagnez toute la "logique" métier et l’abstraction des accès à la base.
Au niveau performance, rien à craindre.
Pas de soucis pour commiter vos ajouts dans le trunk.
Le mieux est de se caler sur la dernier version dans le svn du projet google code.
Cordialement,
je ne suis pas sûr qu'il soit nécessaire de faire du dev aussi dépendant de la base de données.
Autant baser le webservice sur OpenConcerto directement, vous gagnez toute la "logique" métier et l’abstraction des accès à la base.
Au niveau performance, rien à craindre.
Pas de soucis pour commiter vos ajouts dans le trunk.
Le mieux est de se caler sur la dernier version dans le svn du projet google code.
Cordialement,