Discussion :

[mameziane]

Bonjour à tous,

Je commence la conception d'une base de donnée relationnele en Interbase pour notre société afin de faire une application en delphi par la suite, toutefois je me trouve devant un problème qui m'a paru dûr.

Je vais essayer ici de simplifier le problème pour un seul ARTICLE en disant que :
Notre société achète un ARTICLE qu'on va appeler ART001 de chez plusieurs fournisseur F001, F002, F003... à divers prix et l'enregistre dans le stock via des bons d'entrées avec des références fournisseur différentes ainsi le prix de revient est différent selon le fournisseur ce qui donne:

FICHIER ARTICLE:

ID_ART ... CODART ...... REF_FOUR ..... DESIGNATION ...... PRIX_ACHAT....PRIX_VENTE ...... Q_EN_STOCK
-------------------------------------------------------------------------------------------
32 ........ ART001 ........ F_12555 ........ ARTICLE XYZ ........ 15.00 ........ 21.00 .................... 47
44 ........ ART001 ........ RTC5450 ........ ARTICLE XYZ ........ 16.50 ........ 21.00 .................... 82
46 ........ ART001 ........ FRTFY99 ........ ARTICLE XYZ ........ 13.75 ........ 21.00 ................... 29
.... etc

Mais à la vente et via le Bon de livraison, le client ne doit avoir qu'une seule ligne qui cummule
les qtés eu à partir des différents articles ART001:

CODE ............ DESIGNATION........ PRIX UNITAIRE..................QTE
----------------------------------------------------------------------
ART001 ......... ARTICLE XYZ ............. 21.00 .......................120

La question est : comment faire pour savoir la qté en stock de chaque article à part et ainsi connaitre
comment les qtés soustraites ont été vendues (historique de vente) pour une période donnée.

Remarque:
Ce problème se répète pour des dizaines de produits qui sont achetés et calculés statistiquement indépendamment
mais vendus cumulés.

Merci de vous intéresser à ma question

[seabs]

Bonjour,

Il y a plusieurs questions dans ta demande. A mon avis :

• Ordre d'imputation des sorties
• Calcul de la valeur des produits qui restent en stock

Il s'agit d'abord d'un problème comptable, car je suppose que l'inventaire de fin d'année sera valorisé à partir de ta base de données.

Pour l'historique des données, il est possible de retenir le principe du premier entré premier sorti. Ainsi, l'article ancien est toujours sorti le premier. Pour savoir, les articles qui sont en stock à une date donnée, il convient de remonter la liste des articles pour identifier l'origine des quantités restantes.

Pour la valorisation du stock, la méthode prévu au plan comptable est le coût moyen pondéré. Après chaque entrée ou sortie, il est y a lieu de calculer la valeur moyenne pondérée. La technique du premier entré, premier sorti peut être utilisée, mais lors de la rédaction du bilan, de fin d'exercice, la valorisation des stocks doit se faire au coût moyen pondéré. Certes, il faut reconnaître qu'en pratique, cette technique n'est pas toujours appliquée et même pas très souvent.

Voilà pour les principes. Après, il reste à analyser les moyens pour parvenir à à ces résultats puis écrire les requêtes qui vont bien. Sur le plan programmation, la réalisation ne comporte aucune difficulté majeure.

A ta disposition pour tout autre renseignement et de donner des explications plus techniques si nécessaires.

Bon courage

[mameziane]

Bonjour seabs;

Merci d'avoir répondu aussi vite.

Votre réponse porte sur le calcul comptable (cout, prix ...) mais ma question concerne seulement la manière de gestion, je m'explique:
Ce qui m'intrigue en tant que Développeur c'est qu'à l'entrée les articles se considèrent comme différents (selon la référence fournisseur), à la livraison ils sont considérés comme un seul article (selon Code article qui est interne) ainsi le client n'aura qu'un seul article à la livraison (quelque soit sa provenance) mais à l'inventaire l'administrateur doit avoir un état de stock détaillé pour chaque article.

Ma question est comment distinguer les articles à l'entrée et à l'inventaire en les cumulant à la vente ??

Merci encore

[seabs]

Bonjour,

Si je comprends ton approche, au moment de la livraison, l'opérateur doit choisir les articles qui sont livrés. Il est donc nécessaire d'identifier l'article qui est sortie. Par contre, lors de l'édition de ta facture, la requête doit regrouper en une seule ligne l'ensemble des articles ayant la même identification.

Cette démarche peut se faire en automatique premier entré et premier sorti en regroupant les produits quelque soit leur provenance. Sinon, tu fais une une sortie par article avec identification facture et tu regroupes en une ligne sur la facture.

Il convient d'aménager en conséquence ta table des sorties avec un identification du client et une identification de la facture. Le code article sera utilisé pour faire les regroupements dans ta facture.

Afin de te présenter un exemple concret, tu peux me transmettre le schéma de ta table des sorties. Sinon, tu m'expliques ce que tu as prévu pour effectuer les sorties.

Il me faut bien comprendre ton cheminement pour de donner un exemple complet.

A pluse

[mameziane]

Monsieur Seabs, Bonsoir

Claire qu’elle soit, votre analyse m’a vraiment enrichi les idées.
Effectivement j’ai prévue deux champs dans ma table article pour l’identifier et en voici une idée sur la structure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

ID_ARTICLE      INTEGER NOT NULL :  Identifiant unique auto incrémenté
ID_MARQUE       INTEGER          :  Pour jointure avec la table MARQUE
ID_FOURNISSEUR  INTEGER          :  Pour jointure avec la table FOURNISSEUR
ID_NDP          INTEGER          :  Pour jointure avec la table NDP 
ID_DEVISE       INTEGER          :  Pour jointure avec la table DEVISE
CODARTICLE      VARCHAR(13)      :  Sert à grouper les articles dans le Bon de livraison
DESIGNATION     VARCHAR(75)      :  Description de l’article (Modifiable dans le BL)
DESCRIPTION     BLOB SUB_TYPE 1 SEGMENT SIZE 80 : Plus de détail (si plusieurs lignes)
REFERENCFOUR    VARCHAR(13)      :  La référence du fournisseur (différente selon provenance)
QTESTOCK        INTEGER          :  Qté actuelle en stock
QTEALERTE       INTEGER          :  Qté d’alerte
DEPARTUSINE     NUMERIC(12,3)    :  Prix départ usine (selon devise)
PACHATDEVISE    NUMERIC(12,3)    :  Prix d’achat en devise (après remise fournisseur)
TXMARGE         NUMERIC(6,2)     :  Taux de la marge bénéficiaire
VALMARGE        NUMERIC(12,3)    :  Valeur de la marge bénéficiaire
TXREMISFOUR     NUMERIC(6,2)     :  Taux de la remise fournisseur
VALREMISFOUR    NUMERIC(12,3)    :  Valeur de la marge bénéficiaire,
TXTRANSPORT     NUMERIC(6,2)     :  Taux de transport (si importation)
VALTRANSPORT    NUMERIC(12,3)    :  Valeur des frais de transport
TXTRANSITAIRE   NUMERIC(6,2)     :  Taux des frais transitaire
VALTRANSITAIRE  NUMERIC(12,3)    :  Valeur des frais de transitaire
TXFRAIS         NUMERIC(6,2)     :  Taux pour les frais divers
VALFRAIS        NUMERIC(12,3)    :  Valeur des frais divers
TXREMISEDIST    NUMERIC(6,2)     :  Taux de la remise accordée aux distributaire
VALREMISEDIST   NUMERIC(12,3)    :  Valeur de la remise accordée aux distributaire
PVENTPUBHT      NUMERIC(12,3)    :  Prix de vente public en hors taxes en (DINAR TUNISIEN :TND)
PVENTPUBTTC     NUMERIC(12,3)    :  Prix de vente public TTC en TND
PVENTDISTHT     NUMERIC(12,3)    :  Prix de vente Distributeur HT en TND
PVENTDISTTTC    NUMERIC(12,3) :  Prix de vente public TTC en TND
VALCIFDT        NUMERIC(12,3) :  Valeur en coût et Fret en TDN
TXRPD           NUMERIC(6,2)  :  Taux de la RPD (Taxes)
VALRPD          NUMERIC(12,3) :  Valeur de la RPD 
PACHATDT        NUMERIC(12,3) :  Prix de revient en TND

Comme vous l'avez remarqué le CODARTICLE et REFERENCFOUR auront le rôle d'identifier l'article :

CODARTICLE : sera le même pour les articles identiques même si le prix et la provenance sont différents
ainsi il sera imprimé dans le Bon de livraison et la facture dans les lignes cummulées

REFERENCFOUR: sera un identifiant pour chaque article à part donc il sera différent même si la désignation de l'article se répète dans la table

ID_ARTICLE : Cet identifiant aura un rôle important dans les jointures de la table Article avec la table LIGBONLIV , FOURNISSEUR ... etc


Je doit connaître que le traitement qui va servir à modifier un Bon de livraison ne sera pas facile à développer à savoir que le bon de livraison sera sauvegardé de deux manière:

- La première dans les Table BONLIV (entete) et LIGBONLIV (lignes)

- La deuxième sauvegarde dans les tables LIVCLI et LIGLIVCLI dans lesquelles on trouvera le bon de livraison tel qu'il a été adressé au client et qui sera utilisé lors de la facturation.

Voilà tout, j'attend votre avis sur ce modeste bout de travail

et encore merci

[seabs]

Bonjour,

C'est avec un peu de retard que j'ai examiné votre table article.

La méthode utilisée peut répondre à votre demande initiale de regrouper les produits en une ligne sur le BL ou la facture.

Par contre, je m'interroge sur certains points :

• Les prix de vente ne varient pas tant qu'un article n'est pas épuisé
• Comment allez-vous gérer les augmentations ou diminutions du prix de vente
• Identique pour le taux de marge

La mise en place d'une entité tarif serait peut être la bien venue.

Avant de lancer le développement, vous avez réalisé un MCD. Je pense, qu'il serait utile de le revoir.

Enfin, il s'agit juste d'un avis.

En règle générale, il est plus facile de programmer plusieurs tables liées par une clé étrangère qu'une table importante qui peut comporter des redondances et des doublons.

Bon courage, car le projet me semble important.

[mameziane]

Bonsoir ;

C'est avec un peu de retard que j'ai examiné votre table article.

et c'est avec impatience que j'attendais votre avis

• Les prix de vente ne varient pas tant qu'un article n'est pas épuisé
• Comment allez-vous gérer les augmentations ou diminutions du prix de vente
• Identique pour le taux de marge

en fait, le client préfère gérer les prix de vente indépendamment sans aucune règle,
quant bon lui semble et en allant via le menu GESTION ARTICLE -> MODIFICATION ARTICLE
il fera les modification voulues et c'est instantanément que les prix seront pris en considération,
bien sure chaque vente sera comptabilisée au prix enregistrée lors de sa création
et c'est aussi le cas pour la marge, les frais et toutes les variables utilisées lors de la vente
elle seront toutes enregistrées dans chaque BL

Avant de lancer le développement, vous avez réalisé un MCD. Je pense, qu'il serait utile de le revoir.

si MCD voulait dire modèle conceptuel de données, eh bien je suis vraiment désolé de vous informer
que je suis autodidacte en base de donnée et en développement en visuel et je n'ai jamais réaliser un MCD

Monsieur Seabs;

Votre avis m'est très intéressant, dans cette discussion je vous ai détaillé seulement la table article qui est liée
avec plusieurs autres (fournisseurs, devises,ndp,marques...) et je ne vois pas si c'est nécessaire de la 'découper' encore

Vous m'avez vraiment aidé par votre avis et je m'y mets à réaliser "de regrouper les produits en une ligne sur le BL "

Avant je me trouvais seul devant cette application qui me parais gigantesque
mais votre encouragement et votre soutien me donnent des forces

Mille merci encore

[seabs]

Bonjour,

si MCD voulait dire modèle conceptuel de données, eh bien je suis vraiment désolé de vous informer
que je suis autodidacte en base de donnée et en développement en visuel et je n'ai jamais réaliser un MCD

Effectivement MCD est bien modèle conceptuel de données. Le fait d'être autodidacte n'est pas un handicap. Il existe des livres bien conçus pour apprendre. Exemple : Conception Méthodique des Bases de Données de Gérard BUENO - 23,76 € chez Amazon. Je suis moi-même autodidacte en programmation et pourtant je développe régulièrement des logiciels pour la gestion commerciale

Par expérience, je pense que la création d'un MCD permet de créer une base solide qui simplifie ensuite la programmation.

Mon objectif est de vous aider car j'ai bien compris qu'il s'agit d'un développement important qui représente du temps. Dans ce type de projet, il est difficile de faire des modifications car il faut tester de nouveau l'ensemble de l'application. C'est pourquoi, il faut prendre le maximum de précautions au départ.

Si vous me communiquez l'ensemble de vos tables, je peux essayer de vous bâtir un MCD puis le modèle logique de données. En m'adressant directement un exemplaire de votre base de données vide, s'il s'agit d'Interbase 6, je peux le réaliser en automatique avec Poweramc. Même si cette approche est imparfaite, elle vous aidera.

Pour mes développements, j'utilise principalement Delphi avec Firebird qui est identique à Interbase, mais gratuite. Pour mes MCD, je dispose de plusieurs outils mis à disposition par un de mes enfants.

en fait, le client préfère gérer les prix de vente indépendamment sans aucune règle,
quant bon lui semble et en allant via le menu GESTION ARTICLE -> MODIFICATION ARTICLE
il fera les modification voulues et c'est instantanément que les prix seront pris en considération,
bien sure chaque vente sera comptabilisée au prix enregistrée lors de sa création
et c'est aussi le cas pour la marge, les frais et toutes les variables utilisées lors de la vente
elle seront toutes enregistrées dans chaque BL

Dans votre démarche, il vous faut stocker tous les éléments dans le bon de livraison ou de la facture car vous n'aurez aucun historique des évolutions de prix. Bon, il s'agit d'un choix possible, d'autant que la politique de prix est de la décision de votre client.

Il faut reconnaître que la gestion des tarifs est toujours complexe à mettre en oeuvre, il n'y pas aucune solution toute faite qui soit parfaite. La difficulté est de tester pour qu'il ne reste aucune anomalie.

A votre disposition.

[mameziane]

Suite à votre aide à partir de laquelle j'ai pu avancé dans la résolution du problème, je vous remercie et je ferme cette discussion.

Merci pour tout