Voila mon probleme sous access  
 
je dois gerer 3 types de documents qui sont tres semblables :
 
des devis, des factures et des bons de commandes
 
pour l'instant j'ai une table devis et detail devis ainsi qu'un formulaire et un etat  ce qui me permet d'ajouter , de modifier, de supprimer , d'imprimer des devis  
 
Seulement j'ai mis pas mal de temps a faire ca et j'aimerais bien pouvoir utiliser la meme structure de données pour une facture, un bon de commande ou un devis.  
De plus il faudrait pouvoir transformer rapidement un devis en bon de commande et en facture pour ainsi ne pas avoir a retaper tout le devis...
 
Est-ce que c'est possible ou suis je obligé de créer des tables factures et bon de comandes (avec a chaque fois le detail facture et le detail bon de commande... )
 
merci

Salut
 
non, t'es pas "obligé" a priori de créer d'autres tables
si la structure est strictement identique
alors
  tu peux typer tes tables
ou bien utiliser un état d'avancement
 
mais mais mais mais... méfie-toi
 
en général, un devis, un bon de commande et une facture ne contiennent pas la même chose et n'ont pas le même but, un devis est estimatif et modifiable, une facture est destinée à obtenir le règlement des travaux du bon de commande
 
donc c pas forcément si évident que çà
 
faudrait voir
 - le modèle
 - les besoins
 
remarque : pour un pb conceptuel, peu importe le "sgbd" que tu utilises
 

effectivement c plus compliqué :
 
si un client vient et achète un ou plusieurs produit, il faut éditer une facture donc pas besoin de devis  
 
par contre il peut y avoir la suite d'evemenemnts :  devis puis rien ou alors devis puis bon de commande puis facture donc je sais pas trop comment organiser mon application puisqu'il faudrait pouvoir "transformer" un devis en bon de commande puis en facture
 
De plus c vrai que c pas exactement la meme chose devis, bon de commande et facture par exemple dans un bon de commande ya le delai exigé
 
donc tu me conseille koi instantdharma ? et est ce que c possible de typer des tables et de faire des etats d'avancement dans access pasque g regardé dans l'aide et ya rien du tout!

Surtout :
 
-> Dans un devis, on as souvent plusieurs lignes avec le même produit pour des prix différents.
-> Dans un bon de commande, les produits identiques sont regroupés.
-> Une facture est éditée pour chaque envois de colis, ne reprennant que ce qui est livré dans le colis, et à titre informatif, on indique généralement le reste à livrer.
 
Il va de soit que c'est pas si simple à modéliser.

 
hum  modeliser une table en "copier/coller" même aprés les avoir modifié c'est un risque d'erreur, car tu as de lien avec ta table devis qui ne seront pas utile dans commande. Le risque est plien de message d'erreur ou d'incohérence de donnée, et tu vas passer plus de temps a corrigé les erreurs qu'a refaire des tables belles et propre de tout code ou commande.
 
conseil avertie, créer des tables autant que tu en a besoin, en SGBD le copier/coller est vraiment source d'erreur.
 
 
 
   

ok mais je voi pas l'interet des requetes de creation de tables
 
 
a mon avis ca va etre trop compliqué cette histoire  
 
tant pis je ferais les factures et les bons de commande de la meme manière que les devis ...

Perso, je suis plutôt habitué aux tables poubelles de ERP.
 
Dans GENERIX par exemple, c'est modèliser en 3 tables :
 
EVE : Evènement. Dedans, on a les factures, les devis, les bons de livraison, les commandes, les réapro, les réceptions de stock, les réception de SAV, les... (y'en a encore long comme ça )
 
EVL : Ligne d'évènement.
 
EVP : Post d'évènement (fonctions rattachées à une ligne d'EVL, par exemple la tarification)
 
Ca gère tout, c'est très souple et tout.
 
Par contre, il faut être extrêment rigoureux quand on modélise, et quand on s'en sert par la suite. Ces tables font l'objet d'une dizaine de pages de documentation chacune, sans compter le fonctionnel (description de la structure d'une commande par exemple).

 
oui mais les ERP sont! des poubelles    
 
nan je rigole, quoi que, il y en a tellement dedans que son utilisation est réservé à un public avertis, quand a son exploitation que se soit SAP, Clarify, people Soft, Oracle ou autre, la c'est réservé à une élite qui a été formé et pour qui la modélisation de x tables n'est qu'une rigolade.
Surtout pour le premiers.
 
Mais c'est vrai je connais pas ces produits si ce n'est que par l'utilisation de clarify.
 
 

Generix n'a plus aucun secret pour moi
 
Le problème, c'est que ça va bientôt fermer, et que chez GE, ils passent sous Oracle pour l'ERP, donc j'ai tout à réapprendre de A à Z
 
Sinon, j'ai jamais fais de formation dessus, pas plus que SAP (avec lequel je me suis contené de bosser uniquement avec les interfaces). En fait, c'est simple : T'as le client il te donne 2 jours pour faire un truc qui en demande 20, et il te donne pour unique support deux classeurs de 500 pages contenant le MPD
 
Après tu te démerdes Bah t'as très rapidement plus le choix : tu retrousse tes manches et du passes deux nuits blanches
 
Mais moi j'adore ça. Se prendre la tête avec un modèle complexe bourré de lacunes (la souplesse et la réutilisabilité sont les enemis du spécifique et de la performance) pour résoudre un problème qui ne l'est pas moins, c'est un challenge que j'adore...
J'aime moins quand ça te tombe dessus un vendredi à 16h30 (ce fût le cas vendredi de la semaine dernière, je suis parti du taff à 22h )

en fait, la problématique devis / bon de commande / facture n'es absolument pas triviale, parce que la réponse à apporter en termes de base de données dépend du domaine d'activité et des besoins du 'client'...
g fait une appli comme çà ya qq années, yavait des devis et des factures, dans une boite de maintenance / réparation / nettoyage de conteneurs
le basculement devis / facture est toujours particulier (génération de n°s de facture, calculs divers et variés ; dans mon egzemple, yavait besoin de calculer le nb de jours d'immobilisation des conteneurs sur le parc, ca générait en + des lignes de commandes particulières (tant de jours à tant par jour, ca vous fait tant).
donc :
mieux vaut plus d'entités /asssociations (restons conceptuels )
une modélisation et une analyse des traitements / processus est impérative pour affiner la modélisation
-
intéret des scripts de création de base :
pour moi, fondamentalement utile, pour créer direct une base de développement, une ou plusieurs bases réelles selon les besoins, mais je crois qu'on sort un peu du cadre de ce post

Nan moi je te jure, j'adore les tables boubelles
 

 
La première fois que tu dois faire une requête là-dedans, on te file un bon de réduction pour acheter une corde

 
 
tu bosses chez GE?
 
tu verras oracle c'est de la bal    
 
pas plus compliquer que d'apprendre le japonais    
 
quand au doc la c'est 8 classeurs    
en anglais    
 
courage

Ouais, je suis habitué à leur trucs de ouf
 
Le mieu, c'est de faire les conf-call de mise en prod en anglais avec un indien comme maître de conférence... Je comprends pas un traître mot de ce qu'il me dit

 
   y a des indiens partout maintenant en info  tu sais et puis tu as de la chance il aurait pu te parler le ;
 
tamoul
hindi
gujarati
kaçmiri
ourdou
telugu
malayalam...
 
sans oublier les dialectes austro-asiatique ou sino-tibétain
 
l'anglais ne suffit plus mantenant, nous devons être polyglothes    
 

Bah... A part chez GE, y'apas beaucoup d'indiens sur le marché en europe quand même
 
En tout cas, un truc est bien, ils se sont apperçus que si sur le papier ils ont une formation aussi bonne que les européens pour un salaire largement inférieur, leurs compétences sur le terrain sont loin d'être aussi avantageuses que ça... Depuis 1 an ils ont abandonné tout recrutement de nouveaux indiens en France. En, à ma boîte on avait fait pour eux un document de demande de subvention européenne (6 millions d'euros) pour je sais plus quoi. C'était bien parti, le dossier était presque passé, pis y'a un inspecteur du travail qui a mis son nez là dedans : il a pas digéré que la subvention en question (servant à la base à motiver GE à embaucher du personnel) serve à embaucher des indiens à la place d'européens. Du coup ça leur est passé sous le nez, alors que cette subvention était largement plus importante que le gain qu'ils ont eu en prenant de la main d'oeuvre pas chère venue d'Asie (et toc ! faire bosser le tier-monde n'a pas toujours que des avantages financiers)

 
surtout que GE est la plus grosse Société financière du monde    et je crois même qu'ils ont détenu le record de la plus grosse capitalisation boursière au monde!!
 
Excuse nous spitagor on a un peu détourné ton post.
 
Au faite Magic si il change leur ERP est ce qu'il change les serveurs avec?

Ca, je sais pas du tout.
 
Tout ce que je sais, c'est qu'ils avaient prévu d'abandonner Generix en tout début d'année, ma mission chez eux ayant été au départ reconduite pour l'étude de l'impact sur le site que ma boîte avait fait pour eux, ainsi que les développements nécessaires à cette évolution.
 
Au dernière nouvelles, c'est repoussé au mois de juin. Mais depuis février, ils n'en parlent plus, donc à priori, au plus tôt à la fin de l'année (j'y crois pas du tout )
 
Mais c'est tout ce que je sais. Ca sera Oracle à la place, mais je sais pas s'ils changent les serveurs ou non. A priori, ils devraient en changer au moins un, ne serait-ce que le serveur qui va faire tourner l'environnement de prod. En effet, il faut ocnserver le serveur Generix de prod actuel pour backup quelques mois, et donc seul le serveur de dev/test devrait migrer réellement.
 
Ca me semble de toute façon nécessaire, car que ce soit en terme de stockage ou en vitesse, le serveur actuel commence à être un peu juste. Un serveur neuf semble donc requis pour héberger ce nouvel ERP qui à mon humble avis sera beaucoup plus consomateur que Generix (qui est un tout petit ERP, assez limité et sans interface digne de ce nom (interface graphique complètement naze, donc tout le monde utilise l'interface telnet qui est au moins aussi rapide qu'un minitel, la convivialité en moins )

Bah ça change rien.
 
Là c'est GEMS qui demandait la subvention, et GE étant un grand groupe, chaque filliale est totalement indépendante finanièrement parlant. Donc 6 M? c'est 6 M? ça finançait une énorme partie de leur projet, qui lui-même pesait très lourd dans leur budget.

 
pas pour rien les indiens sont là, il y a plus de compagnie certifié cmm 5 en inde que partout ailleur sur la planète

C'est surtout qu'un équivalent bac+5 en informatique qui vient d'Inde demande le smic. Et que du coup, même à loger sur Paris, ça donne une main d'oeuvre bien moins chère que la min d'oeuvre européenne, même si les frais pour les faire venir peuvent sembler énormes.
 
Hors l'Inde qui a un modèle scolaire similaire aux USA (on te forme pour trouver un job, et non pas pour avoir une formation) s'est donc fortement orienté vers l'administration DBA principalement, puisque le vieux continent est en pénurie de tels diplômés, les seuls étant sur le marché demandant 10 K? net par mois...

 
 
bah en France tu as bts info ou on t'apprend "select from where" c'est deja ça.    
 
Lors des examens je disais aux examinateurs que la BD était un métier a part entière, leurs réponses reposaient sur le programme de l'éducation nationnal qui a été réformé et était innovant. Le prob la réforme du programme BTS Info date de .... 1998    
 
Euh réforme et éducation nat