Salut a tous,
 
Voila pour mon stage on me demande de faire un ERP j'ai quelque notion en BDD mais ERP je connaissais pas j'ai fais quelque recherche sur le net et j'ai trouver quelque truc.
 
Mais pourriez vous m'aidez avec des infos complementaires? Et la question que je me pose est-ce dur?
 
Merci d'avance
 
@++

http://www.erp5.org/sections/erp/m [...] 9539881.62

un ex d'ERP, c'est SAP.
Franchement, si t'es débutant en info, te demander de faire un ERP tout seul, ça me paraît pas réaliste. T'as combien de temps parce que si t'as 1 an, à la limite, ça peut être jouable)...

ERP (in english): http://en.wikipedia.org/wiki/Enter [...] e_planning  
PGI (en français): http://fr.wikipedia.org/wiki/PGI

Nan je suis pas débutant je suis en licence reseaux et télécom mais j'avais jamais entendu parler d'ERP
 
Donc voila en 3 moi c'est jouable?
 
Merci d'avance
 
@++

"licence réseau" => t'es encore dans les études => t'es donc débutant dans le monde professionnel
 
Et quand bien même tu aurais 5 ans d'expérience, ça ne suffirait pas. Si tu as lu le document proposé par couak, tu as donc vu que la "simple" mise en oeuvre (pas le codage) d'un ERP prend entre 14 et 18 mois voire plusieurs années (ça dépend de la taille de l'entreprise et si le projet est bien conduit).
 
Pour ce qui est du codage, ça se mesure, non pas en jour/homme mais en siècle/homme tellement c'est complexe...
A mon avis, soit ton maître de stage ne sait pas ce qu'est un ERP (et du reste, j'ai vu qu'il n'y avait pas qu'1 def pour un ERP) et en fait, il veut un petit intranet pour automatiser certaines tâches, soit il veut vraiment un ERP est n'est pas au courant du tout de l'ampleur de la tâche...

Oui debutant dans le monde pro a mon avis le tuteur ne se rend pas compte de ce que c'est...
 
Je sais pas trop quoi faire accepter le stage ou pas...

 
J'ai peur que ça soit un stage "piège". Si dès le départ, le périmètre du stage n'est pas du tout défini, tu risques de ne pas avoir grand chose à présenetr à la fin du stage (car j'imagine qu'il y a une soutenance). Donc, si t'as le choix, vois si y'a pas un meilleur stage...

Ben en fait le gars apperement il n'ont pas d'amin reseaux
 
Donc faut mettre en place un firewall ( barracuda )
 
Ensuite il m'a parler d'ERP et d'autre truc encore et que si je gerrer je serais embauché...
 
Mais les ERP je vient de survoler la doc de couak ca a l'air un epu ( beaucoup ) delicat...
 
Donc je sais pas quoi faire.

3 mois c'est le temps qu'il m'a fallut pour concevoir et réaliser 1 seul des 9 modules d'un petit ERP maison (200 tables). Donc même pour un petit ERP c'est pas jouable ou alors il ne veut pas vraiement un ERP comme dit rufo.
 
Par contre même si c'est infaisable et que tu te plantes, à partir du moment où tu as appris des choses et que tu sais pourquoi tu n'as pas réussi,tu peux réussir une soutenance.  
 
Pour moi le problème est plus d'avoir un stage de developpeur dans ton CV de technicien réseau ou alors tu veux te reconvertir...

 
quel est le rapport entre une install de firewall (tout à fait dans ta branche) et développer un ERP  
Moi, j'ai plutôt l'impression que ce qu'il veut, c'est un outil de monitoring de réseaux avec du reporting du genre Nagios...

Nop Nop
 
En fait c'est une boite qui fait des demodulateur DVB.
 
Le gars il me fait je ve mettre en place un Firewall Barracuda Je dit Ok je connais pas la marque mais bon voila... ca je peut me demerder
 
Ensuite il me parle des differents client qu'ils ont et de la mise en place d'ERP
 
Il me parle aussi des differents comptes qu'il va falloir lire un bouquin M$
 
Et puis voila mais je vais lui envoyer un mail pour avoir plus d'info
 
( Pour le truc Nagios j'ai une boite qui me propose un stage la dedans )

 
Ca a l'air pas clair le sujet du stage... Si tu peux avoir celui sur Nagios, ça correspondra plus à ton profil. Et au moins, le sujet est plus carré, mieux cerné.
 

et puis c'est bien beau de parler de dév. d'un ERP, mais l'intérêt de ce genre de choses c'est surtout de bénéfier des bonnes pratiques éprouvées sinon c'est un soft sur-mesure.
Une entreprise achète un ERP pour aussi remettre à plat les process et les méthodes de travail
 
On s'éloigne du topic "sgbd", et j'ai vraiment l'impression que le resp. de stage est bordélique, et je crains que coacher un stagiaire donnera au stagiaire de mauvaises habitudes

A priori, tu ne vas pas avoir à developpé l'ERP...
 
Par contre, superviser sn déploiment sur le réseau d'entreprise, de ce que je comprends.
 
La boîte fait de la prestation de services réseau, c'est bien ça ?
 
Si oui, c'est comme par exemple dans la boîte où je suis actuellement.
 
Ma boîte est partenaire avec l'ERP Generix.
Je suis en TMA chez un client, et récement, on a dû changer de la version 4.4 à la version 5.2
Nous avons fait appel à une société de prestation réseau partenaire avec nous afin de planifier la mise en place des nouveaux serveurs :
- Installation de Oracle 10gR2
- Migration des données Oracle 8i => 10gR2
- Installation de l'ERP sur un nouveau serveur
- Déploiement d'une plateforme JRE
- Installation d'un nouveau serveur metaframe (Citrix)
- Analyse de la charge réseau du nouveau client de l'ERP (changement de mode de déploiement)
- Etc.
 
Dans la pratique, c'est nous qui avons presque tout fait, mais selon les recommandations du prestataire réseau.
 
Un ERP impact très profondément le réseau d'entreprise. Bien plus que tout le reste en fait. Car si l'ERP ne fonctionne pas, c'est toute la société qui arrête de travailler, par seulement la secrétaire qui n'a plus de lease DHCP depuis sa pause déjeuner...
Donc cela nécessite un audit très poussé, et énormément de moyens pour s'assurer que tout fonctionne.
 
Je ne parle même pas du cas de la sauvegarde. Là on en est à essayer de passer (à grand coups de vaseline) une solution à 60 000 € au client pour assurer un uptime de 100% sur leurs serveurs y compris si une partie des locaux est détruite.

pour info : http://fablain.developpez.com/tutoriel/presenterp/

Je viens de survoler l'article rapidement.
 
Globalement, je suis d'accord avec ce qui y est écrit, sauf quelques détails :
- Un ERP n'est pas forcément multilingue/multidevise
- Un ERP n'utilise pas forcément la touche TABULATION pour accéder aux champs
- Un ERP ne gère pas forcément les stocks
 
Bon, il doit y avoir d'autres inexactitudes, mais le coup de la tabulation notamment, c'est énorme. Et dire qu'il y a une remarque juste pour ça

Bon, je refais une lecture.
 
Mes commentaires :
- Introduction totalement hors propos. Il n'y a aucun rapport entre Internet et un ERP. Le mot purement marketing e-Business est en total décallage avec l'aspect lourd et concret de l'ERP. Si les ERP évoluent actuellement afin de tirer profit des nouvelles technos, et tirent leur épinge du jeu grâce au marketing bidon des nouvelles technologies (Microsoft avec Navision par exemple, est un bon exemple), les nouvelles technos sont en marge des ERP, et ne restent que des moyens d'interopérabilité.
Il vaudrait mieu partir de la définition d'un SI ainsi que les problèmes d'intégration que cela pose dans une grosse structure hétérogène.
 
- I-A : Remplacer "l'essemble" par "un enssemble" : peu d'ERP disposent de modules pour chaque partie. Souvent, on voit plusieurs ERP cohabiter au sein d'un même SI, chacun apportant son expertise dans des fonctions particulières.
 
- I-A : La modularité n'est pas toujours aussi évidente d'un produit à l'autre. Si certains modules peuvent en effet être utilisés "seuls", d'autres nécessitent absolument d'autre modules, ou ne peut cohabiter avec certains. Cela dépend énormément du produit lui-même ainsi que de son paramétrage.
 
- I-A : Pas d'accord avec la définition. Un ensemble d'applications indépendantes qui utilisent la même base ne suffit pas à dire qu'il s'agit d'un ERP. Deplus, à ma connaissance, un ERP est au contraire FORCEMENT paramétrable. Pour moi, la définition d'un ERP, c'est un ensemble d'application qui utilisent la même base, et donc les interactions sont paramétrages (c'est à dire qu'on n'a pas besoin de modifier le source pour en changer les comportements)
 
- I-B-2 : Pas forcément multilingue/multidevise. Même s'ils le sont certainement tous, un ERP n'induit pas ces critères.
 
- I-B-2 : "Pas d'interface entre les modules". Je suis moyennement d'accord. C'est flou comme phrase je trouve. En effet, on n'a pas besoin de passer par un outils du genre EDI afin de communiquer d'un module à un autre, mais c'est justement parcequ'il y a une interface interne qui permet aux modules de communiquer nativement.
 
- I-B-2 : Un ERP ne maîtrise pas forcément les stocks. La plupart disposent d'un système de gestion de stocks, mais pas toujours utilisé.
 
- I-B-3 : Même si c'est effectivement souvent Oracle qui est retenu, je ne pense pas qu'il soit judicieux de préciser la nature de la base de données. Cela peut aussi bien être un système propriétaire (Sage, Navision, etc.) libre (Postre, etc.) ou concurrent d'Oracle (SQL Server, etc.) Depuis qu'Oracle Application devient un acteur fort dans le monde de l'ERP, nombre d'éditeurs retournent leur veste, au profit de solutions PostGre ou SQL Server notamment (SAP par exemple)
 
- I-B-3 : Les ERP ne sont pas forcément compatibles Pack Office. Ca n'a d'ailleurs rien à voir.
 
- II-B : Virez moi ce "e-commerce" et remplaçez ça par "Gestion Commerciale" Les "e-" ça mérite le goudron et les plumes . C'est juste une interface dotée d'un habillage, en aucun cas le module ! Pourtant le schéma est bon...
 
- II-B-1 : "4 ou 5" => "plusieurs" fera l'affaire. En France, la compta est différence de celle de la chine ou des états unis. J'irais pas tirer des conclusions quant au nombre de modules financiers utilisés à l'étranger !
 
- II-B-2 : "Remarque: Une entreprise peut avoir des filiales ou encore être multi-sites." Elle peut aussi être multi-société, multi-établissement, multi-emplacement, etc. et ce, de façon récusrive. Dire simplement "qu'un ERP peut gérer les informations logistiques sur différents niveaux de précisions, allant du groupe au point de vente" est suffisant. Pas besoin d'entrer dans le détail.
 
- Je zappe II-B-2-a / II-B-2-b / II-B-2-c / II-B-2-d / II-B-2-e car il s'agit d'un exemple à partir de SAGE, que je ne connais pas. (on dirait une grosse appli Access, beurk quelle horreur )
 
- II-B-3 : Grand total n'importe quoi. e-Commerce, c'est de la Gescom pure et simple. Il ne s'agit ni d'un module ni d'une application. Il s'agit juste d'un skin qui se greffe à l'interface du module Gescom. On peut y retrouver des bouts d'autres modules aussi (CRM, Logistique, etc.) mais c'est avant tout de la Gescom, et surtout, ce n'est pas un module. Les éditeurs vendent ça comme un module, mais pour avoir écrit à quatre reprise des sites e-Commerce se greffant sur des ERP (Générix 2 fois et SAP 2 fois), sans que le site ne face une once de traîtement, et ne communiquant avec l'ERP qu'à coup d'édition/intégration, je peux certifier que c'est tout sauf un module. C'est rien qu'u front-end comme un autre.
 
Voilà
 
Pour le reste, bon article, il décrit bien ce qu'est un ERP

je t'invite à faire suivre tes remarques au rédacteur

Sinon, concernant le point II-B-1, je connais Oracle Application et la compta multi-site fonctionne parfaitement quelque soit le pays. Eventuellement, les états doivent être adaptés selon les lois en vigueur
La seule spécificité que que je connais est au niveau du secteur bancaire qui a un module de compta générale spécifique

Et pour ta 1° réponse :
1°) on parle d'ERP pro... personnellement, je ne connais pas d'ERP qui ne gére pas le multi-devise. Un ERP doit est un logiciel professionnel qui doit gérer le plus grand périmétre fonctionnel possible.
2°) c'est du standard la tabulation mais c'est vrai que ça n'a pas grand chose à faire ici
3°) c'est pas faux

En fait, pour les deux premiers points, c'est surtout que :
- Dire qu'un ERP c'est une application "multi-lingue/multi-devise... etc." c'est bien joli, mais 1/ c'est loin de se limiter à ça 2/ ça fait pas forcément tout ça 3/ c'est du peanuts de chez peanuts, on je juge pas de la qualité d'un ERP parcequ'il te dit bonjour en russe au démarrage (chez GE, ils utilisent dans une filliale un ERP français qui parle qu'en français, et ce, même en angleterre, italie, espagne, portugal et allemagne) : parceque c'est le seul du marcher qui sait faire ce qu'il veulent. former les gens à comprendre "Commande d'achat" = "Purchase order", c'est moins chiant que de devoir gérer des dossiers papiers et des macros Excel de 20 Mo pour pallier à des lacunes du SI .
Pour le coup de la tabulation, c'est encore pire Parceque non seulement c'est vraiment un détail, mais surtout, ça implique que l'outils est un minimum ergonomique. Pourtant, mise à part quelques rares produits, l'ergonomie est généralement le tout dernier des soucis d'un éditeur d'ERP (en plus c'est bien, parceque pour expliquer à un utilisateur lambda qu'il fait faire F10 F10 SHIFT F4 D pour valider une commande, ça nécessite une formation dispensée par l'éditeur à 10 000 €... donc ce serait con de faire un truc ergonomique )

oui enfin, le multi-devise c'est quand même important un p'tit peu quand même

ouais, m'enfin ça tiens quand même en 3 lignes de code, c'est vraiment de très loin la fonctionnalité la plus bidon qu'un vendeur puisse annoncer à son client
 
c'est comme aujourd'hui dire qu'un ERP c'est une application client/serveur, ou qu'un SGBD c'est transactionnel.
 
certes, y'a 20 ans, c'était pas forcément toujours la cas. aujourd'hui, le premier outil gnu merdique respecte ce b-a-ba
 
ps : et j'insiste, un ERP n'est pas FORCEMENT multi-devise. ERP ne veut pas dire "ouvert à l'internationnal".
 
et toutes les entreprises n'ont pas besoin de gérer le multi-devise dans leur système.
 
je vois par exemple Generix, qui a récement été mis en place dans les bureau de poste de La Poste.
super, le truc il sert à gérer le retail de timbres et autres enveloppes de collection aux guichets, et gère ensuite l'état des stocks, réappro, etc. de chaque bureau de poste.
 
bah là je crois pouvoir dire sans m'avancer que le multi-langue/multi-devise c'était bien le dernier des soucis du client

 
j'espère que tu plaisantes là    
 
Le multi-devise pose beaucoup de problème notamment dans les conversions puisque le taux est changé quotidiennement. Y'a qu'à voir les écarts dans la compta quand tu as un client EUR/USD pour s'en convaincre
 
Evidemment, les ERP très spécifiques (genre gestion de la compta des coiffeur) se foutent royalement du multi-devise  

Ben non, le principe d'un moteur multi-devise est vraiment à la portée de n'importe quel gamin de 12 ans.
C'est un peu chiant à écrire, mais ensuite, ça marche tout seul...
 
C'est peut-être parceque je me tape du multi-devise depuis 8 ans maintenant que je trouve ça extrêment simple, mais quand même... Comparé à des oppérations de stocks pour effectuer de l'autoapprovisionnement, le multi-devise est vraiment simplissime.
 
C'est un peu comme si un gars te demande de changer ton appli console en appli windows. C'est relou à faire, mais techniquement ça ne pose pas de problème particulier. Par contre il te demande le la passer de mono-utilisateur à multi-poste/multi-session, là ouais y'a de quoi pleurer.

 
Y'a quand même pas de quoi pousser mémé de la falaise...

 
c'est marrant j'aurais dit le contraire moi  

 
maintenant tu mélanges des bénéfices en EUR du 01/03, en USD du 02/03 et dépense EUR et en YEN du 03/03, tu mélanges le tout pendant tous les jours du mois et tu fais le bilan annuel... c'est loin d'être une simple conversion  

Ben si, si tu regardes la fonction que j'ai posté, elle prend une date de valeur en paramètre, qui permet d'aller chercher le cours de conversion à cette date précise. Donc y'a aucun souci
 
Genre :
 
select SOCIETE.ID, sum(CONVDEV(SOCIETE.ID, ECRITURE.DATE, ECRITURE.DEVISE, SOCIETE.DEVISE, ECRITURE.MONTANT)) TOTAL, SOCIETE.DEVISE
from ECRITURE
inner join SOCIETE on SOCIETE.ID = ECRITURE.SOCIETE
GROUP BY SOCIETE.ID, SOCIETE.DEVISE
 
Et zou !