A voir également:
- Espace membre pour devis et facture php
- Espace insécable word - Guide
- Logiciel devis facture - Télécharger - Comptabilité & Facturation
- Free devis facture 2 - Télécharger - Comptabilité & Facturation
- Comment liberer de l'espace sur gmail - Guide
- Membre indisponible vinted - Guide
7 réponses
anatolekadel
Messages postés
102
Date d'inscription
jeudi 26 mai 2011
Statut
Membre
Dernière intervention
18 novembre 2011
3
24 oct. 2011 à 18:07
24 oct. 2011 à 18:07
Il y a plusieurs moyens de faire ça.
Tu peux faire une variable session() en PHP qui contiennent l'id du client récupéré par SQL.
Ensuite, le client peut par exemple cliquer sur un lien pour afficher la liste des dossiers.
Dans ce cas là, il y a une liste de liens, renvoyant vers un script, tu passe l'id du dossier par la méthode GET.
Ensuite, le script reçoit à la fois l'ID du client et celui du dossier.
Tu compare avec par exemple une table SQL AUTORISER qui contient l'id du client et le dossier auquel il est autorisé à consulter.
Si l'ID du client et du dossier son référencer sur le même enregistrement, cela signifie qu'il est autorisé à lire le contenu du dossier.
Sinon, tu le renvoie à la case départ (c'est un tricheur, il n'a que ce qu'il mérite ^^)
Enfin, s'il est autorisé à lire le dossier choisi, tu ajoute un script pour lire ou télécharger le dossier...
Voilà, c'est un moyen comme un autre, tu peux autrement, comme par exemple, permettre au client de voir uniquement des dossiers dont il est autorisé à consulter (ce qui est mieux ^^)
Tu peux faire une variable session() en PHP qui contiennent l'id du client récupéré par SQL.
Ensuite, le client peut par exemple cliquer sur un lien pour afficher la liste des dossiers.
Dans ce cas là, il y a une liste de liens, renvoyant vers un script, tu passe l'id du dossier par la méthode GET.
Ensuite, le script reçoit à la fois l'ID du client et celui du dossier.
Tu compare avec par exemple une table SQL AUTORISER qui contient l'id du client et le dossier auquel il est autorisé à consulter.
Si l'ID du client et du dossier son référencer sur le même enregistrement, cela signifie qu'il est autorisé à lire le contenu du dossier.
Sinon, tu le renvoie à la case départ (c'est un tricheur, il n'a que ce qu'il mérite ^^)
Enfin, s'il est autorisé à lire le dossier choisi, tu ajoute un script pour lire ou télécharger le dossier...
Voilà, c'est un moyen comme un autre, tu peux autrement, comme par exemple, permettre au client de voir uniquement des dossiers dont il est autorisé à consulter (ce qui est mieux ^^)
Merci pour la réponse,
en gros pour les sessions de toutes façon elles s'initialisent au moment du login et si j'ai bien compris, si je veux mettre un lien permettant au client d'ouvrir telle ou telle facture, je dois faire pointer le lien vers un script permettant de lier l'id de la base mysql à au fichier pdf concerné?
merci pour l'info en tous cas
en gros pour les sessions de toutes façon elles s'initialisent au moment du login et si j'ai bien compris, si je veux mettre un lien permettant au client d'ouvrir telle ou telle facture, je dois faire pointer le lien vers un script permettant de lier l'id de la base mysql à au fichier pdf concerné?
merci pour l'info en tous cas
anatolekadel
Messages postés
102
Date d'inscription
jeudi 26 mai 2011
Statut
Membre
Dernière intervention
18 novembre 2011
3
24 oct. 2011 à 20:22
24 oct. 2011 à 20:22
Euh, je ne sais pas si tu as bien compris (je dois faire pointer le lien vers un script permettant de lier l'id de la base mysql ???)
Donc pour être sûr d'avoir été compris, tu crée un table AUTORISER qui contient au moins 2 champs (idClient, idDossier)
Ensuite, dans ton script PHP, tu vérifie que l'id du client et du dossier sont bien référencé sur le même enregistrement.
Si c'est le cas, alors, tu renvoie le client (avec la fonction header('url');) vers un autre script qui permet la lecture ou le téléchargement du fichier pdf.
Donc voilà le code:
Voilà, c'est un début d'idée. Mais donc, tu as compris, il faut une étape intermédiaire entre le choix du dossier et sa lecture.
Donc pour être sûr d'avoir été compris, tu crée un table AUTORISER qui contient au moins 2 champs (idClient, idDossier)
Ensuite, dans ton script PHP, tu vérifie que l'id du client et du dossier sont bien référencé sur le même enregistrement.
Si c'est le cas, alors, tu renvoie le client (avec la fonction header('url');) vers un autre script qui permet la lecture ou le téléchargement du fichier pdf.
Donc voilà le code:
<?php
//On initialise les deux variables à comparer; tu peux changer le GET par un POST qui est plus sûr
session_start();
$idClient = $_SESSION['idClient'];
$idDossier = $_GET['idDossier'];
//On se connecte à la base de données
$connexion = mysql_connect($hostname, $username, $password) or trigger_error(mysql_error(),E_USER_ERROR);
mysql_select_db($database,$connexion );
//On vérifie que le client et le dossier sont bien dans la BDD
$sql=" SELECT COUNT(*) FROM AUTORISER WHERE idClient = ".$idClient." AND idDossier = ".$idDossier;
$resultat=mysql_query($sql);
if($resultat ==1)
{
//Le client est autorisé à lire le contenu du dossier, on le renvoie donc vers le script qui lui permet de le lire
$lien = 'location: LectureDossier.php?id='.$idDossier;
header($lien);
}
else
{
//Le client est un tricheur, il a tenté de lire un fichier qui lui était interdit de lire, on l'envoie donc ballader
header("Location: https://fr.wikipedia.org/wiki/Tricherie");
}
Voilà, c'est un début d'idée. Mais donc, tu as compris, il faut une étape intermédiaire entre le choix du dossier et sa lecture.
Sauf que c'est pas un système viable.
Pourquoi un dossier?
Il faut que toutes les informations de la facture(le nom du client, la date, prix, taxes, l'objet....) soient enregistrés sur la base de données.
PHP permet éventuellement de générer un .pdf(portable document file) pour que l'utilisateur puisse avoir une version téléchargeable, un affichage HTML est beaucoup mieux adapté à internet puisque HTML est le format d'internet.
Avec un système de dossier et de .pdf pas d'archivage informatique possible (à la limite en .csv/xml/txt ou autre format permettant de placer des repères simples), bon courage pour retrouver une facture parmi les autres .
Une place monstrueuse sur le serveur: Si vous avez 1000 clients avec 2 factures chacun à 1Mo le .pdf(là je suit gentil) vous avez 2Go de stockage inutile sur le serveur...Si le pdf pèse 1.5Mo(valeur crédible) et que vous avez 20000 factures à gérer(c'est pas énorme sur une durée en années) il vous faut pas loin de 30Go rien que pour des dossiers clients, bref c'est pas une solution réaliste.
Sans compter que comme pour l'archivage il faut générer par un script le pdf, à la moindre erreur impossible d'avoir une correction, un retour arrière doit être fait à la main(donc perte de temps, l'informatique n'as aucun intérêt aucun avoir des étagéres avec des tonnes de dossiers sur papiers et les envoyer par courrier ça sera plus rapide), bon courage pour retrouver le bon dossier si vous n'avez pas le nom du client, ou pour trouver le dossier s'il y a des homonymes...
Voici ce qui peut vous aider:
http://www.commentcamarche.net/contents/merise/mcd.php3
Pourquoi un dossier?
Il faut que toutes les informations de la facture(le nom du client, la date, prix, taxes, l'objet....) soient enregistrés sur la base de données.
PHP permet éventuellement de générer un .pdf(portable document file) pour que l'utilisateur puisse avoir une version téléchargeable, un affichage HTML est beaucoup mieux adapté à internet puisque HTML est le format d'internet.
Avec un système de dossier et de .pdf pas d'archivage informatique possible (à la limite en .csv/xml/txt ou autre format permettant de placer des repères simples), bon courage pour retrouver une facture parmi les autres .
Une place monstrueuse sur le serveur: Si vous avez 1000 clients avec 2 factures chacun à 1Mo le .pdf(là je suit gentil) vous avez 2Go de stockage inutile sur le serveur...Si le pdf pèse 1.5Mo(valeur crédible) et que vous avez 20000 factures à gérer(c'est pas énorme sur une durée en années) il vous faut pas loin de 30Go rien que pour des dossiers clients, bref c'est pas une solution réaliste.
Sans compter que comme pour l'archivage il faut générer par un script le pdf, à la moindre erreur impossible d'avoir une correction, un retour arrière doit être fait à la main(donc perte de temps, l'informatique n'as aucun intérêt aucun avoir des étagéres avec des tonnes de dossiers sur papiers et les envoyer par courrier ça sera plus rapide), bon courage pour retrouver le bon dossier si vous n'avez pas le nom du client, ou pour trouver le dossier s'il y a des homonymes...
Voici ce qui peut vous aider:
http://www.commentcamarche.net/contents/merise/mcd.php3
ahhh, j'avais pas pensé à ça, du coup ça fait un très grand nombre de données dans la base, mais en effet c'est préférable, du coup je suppose qu'il faut créer une table par devis/facture puis lier l'id client aux tables concernées en faisant pointer un lien, dont les paramètres passent par get ou post dans l'url?
Surtout pas une table par client!
Vous confondez la donnée et sa valeur, la donnée est générale(nom du champ), donc tous les clients auront un nom, toutes les factures un prix, etc...
Les explications d'anatolekadel sont top:
D'abord collecter les données à partir de documents existant, après on peut regrouper pour faire les tables ce sont des entités de même nature. Les informations des clients par exemple seront tous dans la table CLIENT, la date d'une facture sera dans une autre table(au hasard table FACTURE). En croisant le nom du client et la date on peut ainsi avoir aucune, une ou plusieurs factures pour un client, plusieurs factures de différents clients.
CLIENT (idClient, PrenomClient, NomClient, AdresseClient, etc...)
FACTURE (idFacture, numClient, dateFacture, etc...)
C'est le etc... et les besoins de votre gestion qui vont définir le résultat final(les tables) mais avec ça on retombes bien sur nos pattes(relation 1,n : un client peut avoir 0 à une infinité de facture, on pourras toujours identifier chaque facture, chaque client et chaque facture de chaque client :par dateFacture et idClient ils sont identifiants et idClient sur la table CLIENT est reporté sur la table FACTURE numClient, on parles de jointure de table).
Vous confondez la donnée et sa valeur, la donnée est générale(nom du champ), donc tous les clients auront un nom, toutes les factures un prix, etc...
Les explications d'anatolekadel sont top:
D'abord collecter les données à partir de documents existant, après on peut regrouper pour faire les tables ce sont des entités de même nature. Les informations des clients par exemple seront tous dans la table CLIENT, la date d'une facture sera dans une autre table(au hasard table FACTURE). En croisant le nom du client et la date on peut ainsi avoir aucune, une ou plusieurs factures pour un client, plusieurs factures de différents clients.
CLIENT (idClient, PrenomClient, NomClient, AdresseClient, etc...)
FACTURE (idFacture, numClient, dateFacture, etc...)
C'est le etc... et les besoins de votre gestion qui vont définir le résultat final(les tables) mais avec ça on retombes bien sur nos pattes(relation 1,n : un client peut avoir 0 à une infinité de facture, on pourras toujours identifier chaque facture, chaque client et chaque facture de chaque client :par dateFacture et idClient ils sont identifiants et idClient sur la table CLIENT est reporté sur la table FACTURE numClient, on parles de jointure de table).
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
anatolekadel
Messages postés
102
Date d'inscription
jeudi 26 mai 2011
Statut
Membre
Dernière intervention
18 novembre 2011
3
25 oct. 2011 à 12:00
25 oct. 2011 à 12:00
Non, tu dois faire par exemple, une table CLIENT (idClient, PrenomClient, NomClient, AdresseClient, etc...) + une table FACTURE (idFacture, numClient, dateFacture, etc...)
Bref, tu collecte toutes les informations que tu as besoin pour faire une facture.
Ensuite, quand un client souhaite consulter sa facture, tu vérifie qu'il en a le droit comme je l'ai expliqué, s'il est autorisé à consulter cette facture, tu la construit dynamiquement.
Si tu n'as toujours pas compris, dis-nous de quel type d'informations tu as besoin d'afficher sur une facture (date, nom et prénom du client, etc...)
Bref, tu collecte toutes les informations que tu as besoin pour faire une facture.
Ensuite, quand un client souhaite consulter sa facture, tu vérifie qu'il en a le droit comme je l'ai expliqué, s'il est autorisé à consulter cette facture, tu la construit dynamiquement.
Si tu n'as toujours pas compris, dis-nous de quel type d'informations tu as besoin d'afficher sur une facture (date, nom et prénom du client, etc...)
ok j'essai de comprendre, en fait on a une table pour les infos clients, une table pour les infos facture , en gros dans la théorie, chaque facture est associé a un client (par exemple son numero de client) et du coup il faut que le numero de client soit initialisé dans la session lorsqu'il arrive sur la page "mes factures" (par exemple) merci en tous cas c'est déjà un peu plus précis dans ma mon esprit : )
Dans une table il y a un identifiant(ou plusieurs dans certains cas), c'est identifiant va permettre d'identifier chaque ligne c'est donc cet identifiant qui va être utilisé(ou retenu dans la session) pour pouvoir obtenir les autres informations de la table.
Par exemple: on pourrait dans le meilleur des mondes identifier Jean Dupont par son nom. Mais que se passe il si sa fille Jeanne Dupont est aussi cliente: On peut pas savoir laquelle des deux lignes de données de la table est pour la fille ou le père!
Dans ce cas on pourrait identifier par le champ nom et prénom pour pas les confondre. Pour retrouver chaque autres valeurs de la table(adresse, âge, ville etc...) on va utiliser le nom et le prénom. Probléme résolu dans le meilleur des mondes. S'il y a deux personnes qui ont le même nom et prénom(Deux JEan Dupont ça peut exister sans que ce soit la même personne) on flanques tout le système de gestion de bases de données par terre... un identifiant est donc forcément unique on va lui attribuer un numéro "IDclient", le Jean Dupont de Paris auras pour IDclient 124 et le Jean Dupont de Brest auras pour IDclient 6.
On peut donc différencier les deux sans se tromper.
Pour pouvoir "identifier" chaque facture on va devoir reporter cet IDclient dans la table FACTURE et aussi prendre la date de la facture. On pourras ainsi faire la différence entre deux factures du même client mais qui n'auront pas les mêmes dates.
Que se passe il si un client a fait deux achats le même jour? Il faut rajouter avec la date l'heure(heure et minute) de l'achat pour avoir cette précision, à vous de voir si le système doit prévoir ce cas de figure ou si vous l'empêchez, ce qui pour ce dernier cas provoqueras une erreur dans le cas ou un client a fait deux achats séparés donc deux factures le même jour.
Avec cet exemple trivial(oui bon) je veut vous montrer un aperçu du travail de conception et les risques qui peuvent survenir au moindre oubli.
La méthode Merise permet d'éviter les oublis et les erreurs à travers différentes étapes(8 à 9) qui borne le raisonnement plutôt que de faire une conception plus intuitive(la collecte des informations est la seule étape ouverte au débat, les autres doivent êtres appliquées à la lettre) et risquer d'utiliser un raisonnement humain pour une logique de système d'informations qui n'as que faire de notre logique et de nos idées mais doit tendre à pouvoir être parfait ou sinon évolutif(à travers la 9ème étape) et prévoir que la gestion d'une entreprise peut être améliorée si la dite entreprise dans X années va diversifier ses activités, le Système de gestion bien conçu pourras permettre les ajouts nécessaires et éviter un travail coûteux(et pénible) pour refaire et garder les informations déjà présentes.
Par exemple: on pourrait dans le meilleur des mondes identifier Jean Dupont par son nom. Mais que se passe il si sa fille Jeanne Dupont est aussi cliente: On peut pas savoir laquelle des deux lignes de données de la table est pour la fille ou le père!
Dans ce cas on pourrait identifier par le champ nom et prénom pour pas les confondre. Pour retrouver chaque autres valeurs de la table(adresse, âge, ville etc...) on va utiliser le nom et le prénom. Probléme résolu dans le meilleur des mondes. S'il y a deux personnes qui ont le même nom et prénom(Deux JEan Dupont ça peut exister sans que ce soit la même personne) on flanques tout le système de gestion de bases de données par terre... un identifiant est donc forcément unique on va lui attribuer un numéro "IDclient", le Jean Dupont de Paris auras pour IDclient 124 et le Jean Dupont de Brest auras pour IDclient 6.
On peut donc différencier les deux sans se tromper.
Pour pouvoir "identifier" chaque facture on va devoir reporter cet IDclient dans la table FACTURE et aussi prendre la date de la facture. On pourras ainsi faire la différence entre deux factures du même client mais qui n'auront pas les mêmes dates.
Que se passe il si un client a fait deux achats le même jour? Il faut rajouter avec la date l'heure(heure et minute) de l'achat pour avoir cette précision, à vous de voir si le système doit prévoir ce cas de figure ou si vous l'empêchez, ce qui pour ce dernier cas provoqueras une erreur dans le cas ou un client a fait deux achats séparés donc deux factures le même jour.
Avec cet exemple trivial(oui bon) je veut vous montrer un aperçu du travail de conception et les risques qui peuvent survenir au moindre oubli.
La méthode Merise permet d'éviter les oublis et les erreurs à travers différentes étapes(8 à 9) qui borne le raisonnement plutôt que de faire une conception plus intuitive(la collecte des informations est la seule étape ouverte au débat, les autres doivent êtres appliquées à la lettre) et risquer d'utiliser un raisonnement humain pour une logique de système d'informations qui n'as que faire de notre logique et de nos idées mais doit tendre à pouvoir être parfait ou sinon évolutif(à travers la 9ème étape) et prévoir que la gestion d'une entreprise peut être améliorée si la dite entreprise dans X années va diversifier ses activités, le Système de gestion bien conçu pourras permettre les ajouts nécessaires et éviter un travail coûteux(et pénible) pour refaire et garder les informations déjà présentes.
anatolekadel
Messages postés
102
Date d'inscription
jeudi 26 mai 2011
Statut
Membre
Dernière intervention
18 novembre 2011
3
25 oct. 2011 à 19:40
25 oct. 2011 à 19:40
Si t'as d'autres questions, la communauté CCM est là pour ça ;)
