Je cherche qqn pour me coder un petit programme

[Pwalodwa]

Bon, je crois que je peux difficilement être plus clair que ça:

1. La date est la date du jour, la date de facturation = date de commande si encodé avant 13h, date de commande +1 si après 13h

2. petit listing clients (chaque nouvelle commande est mémorisée sur ce n° et nom)

3. "commande en cours" si "En attente", "commande validée" si "Validation"

4. On entre le prix, le programme ajoute automatiquement le prix d'achat HT et autres (pourcentage fixe)

5. "En attente" -> Listing "à facturer", "Validation" -> Impression d'une note d'envois.

 

Ca ne m'a pas l'air très compliqué vu que je peux le faire en basic (pas de chances, j'ai plus de Commodore 64 ^^) et que je pense que les fenêtres de saisie sont plus simple à gérer sous Windows (je suis peut-être complètement à coté de la plaque).

 

Petit problème: mon budget est loin d'être illimité (une société m'a demandé 1.650€ pour ce boulot... c'est nettement au dessus de mes moyens d'où mon post).

 

PS: A chaque nouvelle commande correspond un nouveau code caddy. Il faut aussi qu'en entrant un code caddy existant le programme affiche toutes les infos (noms, état de la commande, etc.)

Modifié le 15 mars 2005 par Pwalodwa

[3psilon]

Bonjour,

 

Meme si je suis bien moins actif que certains membres, je partage ton opinion kewlcat.

 

Bon j'ai fais un rapide schéma pour la base de données, je précise tout de même que je ne suis un PRO de l'analyse, alors il se peut qu'il y ai des erreurs, à vous de me corriger .

 

 

Donc pour résumer, un client peut avoir de 0 à N commande(s), et une commande contient de 1 à N produits. Cette association quand à elle serait porteuse de donnée : la quantité du produit.

 

Vous pouvez également créer une entité FAMILLE DE PRODUIT, ou encore une entité DATE, voir une entité STOCK. Le schéma peut être extensible.

Car dans cette réprésentation, vous ne pouvez pas savoir quel était le stock du produit X à la date N. (C'etait juste un exemple)

 

Effectivement, la question de l'archivage doit de poser. Faut-il garder une trace de toutes les commandes, de tout les flux de stock ... ?

Cela peut être utile dans le cas ou vous désirez réaliser des statistiques.

 

Je comprend votre impatience Pwalodwa, car vous nous montrez déjà ( à juste titre ) une interface, néanmois le primordial ( à mon avis ) c'est justement la gestion des données.

Ensuite, il existera beaucoup de moyen pour 'taper' ds la base de données et ainsi réaliser vos objetifs.

 

 

Cdt

 

Epsilon

[Pwalodwa]

Dans un premier temps il ne faut faire que ce qui est "expliqué"... (donc pas de références des produits, ni d'état du stock, ni de prix). Le prix de la case (4) est entré manuellement (seuls les prix HTVA et autres sont calculés automatiquement).

Bref, pour l'instant on peut faire nettement plus simple que le "schémas" de 3psilon.

Bdd "clients" : code client (3 chiffres) et nom (société ou localisation)

Bdd "ventes" : date de commande, date de facturation, code et nom clients (cf bdd "clients"), code caddy, nom du client, état de la commande (en cours ou validée), composition de la commande (dans l'exemple : tenture - lambrequin - nappe - plaid - autre), confection gratuite/payante (0/1 ^^) - prix de vente

On aurait donc une bdd "ventes" avec des lignes dans ce genre

231 + Jean R. Batignole + 14022005 + 21032005 + 689 + ten - lam - nap - pla - aut + 245€ + attente

A la place de "ten - lam - nap - pla - aut" on peut aussi (et c'est même mieux je pense) faire un code (1/2/4/8/16/32/64/...). Cette vente aurait donc un "code" 9409 (1+64+128+1024+8192)

 

Dans un second temps ($$$) il faudrait ajouter une base de donnée avec le stock et modifier les champs de saisie (ajout de quantités et références) de façon à savoir si le produit est de stock (et modifier le stock en fonction des ventes).

 

J'ajoute que la base de donné clients et la base de donnée des ventes ne doit pas forcément être accessible sans le programme (donc ca peut être un format étrange accessible seulement via le programme)

 

La base de donnée des stocks devra elle être accessible via excel ou word (ou tout autre programme du genre)

Modifié le 15 mars 2005 par Pwalodwa

[jeanbi]

bonsoir,

sous acces c'est realisable , je m'etais fait 2 / 3 truc gestions de stock, je veux bien comme dis Kewlcat donne mon avis ou des pistes je me sert tous lesjours d'un programme de gestions et commence a connaitre les erreurs a ne pas commettre ( celle qui font ch... l'utilisateur ).

donc je suis partant (attention je n'ai qu'access 97)

a+

[KewlCat]

(...)

On aurait donc une bdd "ventes" avec des lignes dans ce genre

231 + Jean R. Batignole + 14022005 + 21032005 + 689 + ten - lam - nap - pla - aut + 245€ + attente

A la place de "ten - lam - nap - pla - aut" on peut aussi (et c'est même mieux je pense) faire un code (1/2/4/8/16/32/64/...). Cette vente aurait donc un "code" 9409 (1+64+128+1024+8192)

 

Dans un second temps ($$$) il faudrait ajouter une base de donnée avec le stock et modifier les champs de saisie (ajout de quantités et références) de façon à savoir si le produit est de stock (et modifier le stock en fonction des ventes).

 

J'ajoute que la base de donné clients et la base de donnée des ventes ne doit pas forcément être accessible sans le programme (donc ca peut être un format étrange accessible seulement via le programme)

 

La base de donnée des stocks devra elle être accessible via excel ou word (ou tout autre programme du genre)

476081[/snapback]

L'idée du "code" est très bien pour économiser de la place (disque ? mémoire ?), mais comme l'appli va devoir supporter des quantités à la place des flags "commandé (oui/non)", ce n'est pas super évolutif (tant qu'à faire, autant penser de suite à la maintenance de l'appli...)

Pour le second temps, on peut très bien envisager l'export (ou tout bêtement l'utilisation (!)) de fichiers csv pour stocker les infos. Au moins ça permettra de faire ce que l'on veut avec les données (même utiliser Excel pour faire l'édition des factures avec une petite macro). La solution passant par un "export" implique la création d'un module d'import, donc ce n'est peut-être pas si idiot de tout faire avec des fichiers texte... Reste à savoir quel stockage on utilise pour les données de l'application. Il y a un SGBD accessible quelque part ?

[p.legal]

Merci pour ces infos, On a une bonne base de discussion, c'est dejà ça.

 

j'ai quelques questions et/ou confirmation :

 

Le prix que tu entre est un prix TTC ?

tu edite des factures sans l'adresse de ton client ?

une commande saisie ne peut elle plus être annulée ?

 

comme l'a dit Kewlcat, je suis d'avis de faire quelque chose d'evolutif....

sinon ça te coutera deux fois plus cher la prochaine fois puisqu'il faudra "TOUT" refaire.

autant prevoir l'avenir et organiser les tables de maniere à être prètes à être reliées à d'autres futures tables....

 

(à la manière d'un maçon qui passe des gaines vides dans les cloisons le jour ou il les construits, parce que tu lui a commandé 2 prises que tu installera plus tard, et 1 an après t'a plus qu'a tirer les fils et a raccorder. ça evite de casser ce qui à deja été fait )

 

et de penser comme ça dès aujourd'hui ne coute pas forcement plus cher. Alors si dans tes rêves les plus fous d'evolution tu a pensé à autre chose dis le nous.

 

@++

Modifié le 15 mars 2005 par p.legal

[Pwalodwa]

Oui, le prix entré est TTC (prix payé par le client)

Ce sont des notes d'envois et pas des factures, donc pas besoin des coordonnées du client.

En principe, une commande "confirmée" ne sera pas annulée... (le fait d'avoir une étape "en attente" évite de toutes façons 99.99% des problèmes).

 

Je suis bien d'accord sur le principe de prévoir les bases de données qui seront (seraient?) intégrées par la suite... mais tout est une question de budget.

 

Dans mes rêves les plus fous il n'y aurait que:

stock (entrées/sorties/prix).

clients (référence, nom, raison sociale, adresse, contact)

historique (facturier) éventuellement avec des stats (annés/mois/semaines et par clients).

[p.legal]

Merci pour les reponses,

 

deux ou trois autres questions,

 

quelle est la definition maxi à laquelle tu peux travailler ?.

800x600

1024x762

autre ...(preciser)

 

quelle est la definition que tu veux utiliser pour l'application ?

 

est ce que l'application et monoposte ou multiposte (reseau) ?

 

quelle est la duree d'acces aux infos (c'est pour la taille de la Base de donnée)

doit'on prevoir un auto archivage au delà d'un certain delai (par exemple 1 an)

ou detruire les données ?

 

@++

Modifié le 16 mars 2005 par p.legal

[KewlCat]

Je ne suis pas bien sûr d'avoir bien compris les différents états des commandes... On commence par la composition d'un "caddy" qui va constituer une première commande à l'état "Commande en attente" ( == "En cours" == "A facturer"), puis on la valide : elle passe à l'état "Validée" ( == "Confirmée"), ce qui provoque l'impression d'une "Note d'envoi" (et non pas "Facture" puisque nous ne disposons que des prix TTC)...

J'ai bon ?

 

En gros, le point d'entrée de l'application, c'est le code caddy (c'est lui que l'on va saisir et qui va faire apparaitre tout le reste des infos, celui auquel sera rattaché l'état de la "Commande") ?

 

Tes rêves les plus fous peuvent très bien prendre forme.

Dans un cas simple, on peut envisager de n'avoir que trois choses :

- le stock (référence article / dénomination, stock actuel, prix TTC par article)

- les clients (numéro de client, nom, etc. etc.)

- les caddies ou "historique des commandes" (indexé par numéro de caddy, possédant un "état" comme vu précédemment, possédant une référence numéro de client et n références d'articles associées à des quantités - ou encore, si le nombre de références d'artcles est prédéterminé, autant de quantités que de références d'articles, sans avoir à préciser les références)

 

Tout ceci peut très bien être stocké sous forme de fichiers csv ce qui rendrait la consolidation (tes "stats années / mois / semaines / clients") faisable par Excel ou n'importe quel autre outil...

 

Pour parler un peu plus de l'aspect purement technique du projet, quelle est la plate-forme cible ? Tu veux du .Net ? Du Java ? Du C pur et dur ? Du VB ? Perl ? Python ? Tcl/Tk ? ...

[vinch]

Java ? Du C pur et dur ? Du VB ? Perl ? Python ? Tcl/Tk ? ...

Tu m'étonnera toujours Kewlcat

 

Yo beau projet les gars, moi je n'y connais que dalle, la seule chose c'est qu'il me semble qu'il faut eviter Accés (lourd) et de pouvoir intégré de l'ASP pour un futur sur le net, si je dis des conneries ce serra les dernières car ces les seuls remarque que je puis faire.

Salut