robinsonvendredi

Bonjour sgauvin et bienvenue sur le Hub. Le site du zero s'adresse plutôt aux adeptes de php.(à ma connaissance ) D'après ton site tu codes en asp, je te conseille de consulter http://www.4guysfromrolla.com/, c'est mon site favori sur la question.

C'est exactement cela. Il ne faut pas oublier qu'une commande est contractuelle : elle t'engage et elle engage ton client. D'ailleurs, si tu as le temps de le développer, garde une trace des principales étapes de la transaction : devis / commande / BL / facture. Pour cela j'ai choisi d'enregistrer des fichiers XML sur ma base, qui correspondent à chaque étape.(d'autres méthodes que XML sont possibles, mais pour moi c'était le meilleur choix). Comme ça à tout moment, je peux sortir les pdf correspondant à ces fichiers XML, ils sont figés et j'ai une bonne traçabilité de toutes les opérations du devis jusqu'à la comptabilisation. En cas de litige, ce type de système peut te sauver.

Le cas des objets de collection ou artisanaux que cite Altar est bien connu depuis les débuts du commerce en ligne : un produit rare, dont le marketing One to One est facilité par les moteurs de recherche. Par exemple si je vends des "autocollants pour porsche 911 de 1973" je touche ma cible très efficacement. Mais pour moi c'est un "effet secondaire" des moteurs de recherche qui n'explique pas le formidable boom du commerce en ligne, qui concerne aussi les produits de consommation courante. Par ailleurs, n'oublions pas le commerce en ligne B2B qui réalise des volumes encore plus importants que le B2C : dans ce domaine, l'innovation technologique révolutionne les échanges entre les entreprises, et de ce point de vue, il reste énormément de chemin à faire : les normes XML et les systèmes d'info des clients, fournisseurs, et des banques sont loin d'être homogènes. Là c'est clair qu'il y a un frein très important.

Ce n'est pas exactement comme cela qu'il faut faire. 1. Je te conseille de dénormaliser la table commande, donc ce n'est pas des ID mais le nom du client, la référence du produit, son nom, etc... En effet une commande "vit sa vie" indépendamment du reste de la base de données, une fois qu'elle a été passée. Les infos sont figées une fois pour toutes. Inpensable par exemple de ne pas pouvoir supprimer un produit ou un client de ta base à cause de l'intégrité référentielle avec une commande passée il y a deux mois. Au niveau de la structure de la bdd, il est plus logique d'avoir une table "en-têtes de commandes" et une table dépendante "lignes de commandes" plutôt que tout dans la même table. 2. Il faut un système de tracking des commandes. L'iD de la commande distingue parfaitement deux commandes enregistrées le même jour par le même client. En revanche, en e-commerce, se pose le problème des commandes imprimées avec ou sans validation par le client. Par exemple un client imprime la commande sans la valider (donc elle n'est pas enregistrée) et il envoie un chèque en règlement. C'est pourquoi je te conseille, en plus du tracking par l'ID, d'avoir un identificateur jour/minute/seconde/nombre aléatoire qui s'affiche sur la page commande et te permet de savoir si elle a été enregistrée en double ou pas.

On dirait que c'est l'enchaînement panier-commande-facturation qui te pose problème. La façon la plus simple de le faire est de gérer les paniers en variable de session. Les stocker dans la base de données n'est utile que pour un panier dit "persistant", le client a la possibilité de ré-ouvrir son panier en revenant sur ton site après l'avoir quitté. La variable session qui maintient le panier est un array qui n'est vidé que lorsque la commande est validée par le client. Entretemps il peut ajouter ou enlever des lignes. Le processus de passation de commande /enregistrement client dépend de ton business, il existe plusieurs scénarios. Dans le cas d'une boutique B2C classique, tout le monde peut compléter un panier avec le même tarif, l'identification préalable du client n'est donc pas nécessaire. Elle peut intervenir juste avant de valider la commande (écran : "J'ai déjà un compte de client / je n'ai pas encore de compte de client"). La facturation c'est une autre histoire...Ton client a passé une commande, mais un certain nombre d'étapes te séparent de la facturation. Notamment le bon de livraison qui retire physiquement des stocks les articles commandés.

Rassure toi Portekoi tu n'es pas le seul, en ce qui me concerne, je suis également ravi de "produire du code". Dans mon secteur d'activité qui est le logiciel de gestion pour le web, il faut connaître la législation française ce qui ne permet pas le recours à la sous traitance offshore.

D'accord avec toi sur le "pissage de code", j'ai l'exemple en tête d'une petite boîte de développement de logiciel avec 50% de l'équipe en France et 50% offshore.

Je ne suis pas tout à fait d'accord : la programmation apporte encore beaucoup de valeur ajoutée, et rapporte énormément d'argent aux SSII, en France et dans le monde, et pas seulement aux pays de l'est à la Chine ou à l'Inde. Les entreprises ont des besoins croissants en logiciels de plus en plus sophistiqués, en intégration avec leur système d'information interne, en consultants métiers, en chefs de projets (y compris dans le cas de sous-traitance)... Il existe des logiciels payants de CMS, de knowledge management, de veille concurrentielle, ces logiciels communiquent avec des systèmes tels que SAP, pour reprendre ton exemple. Ces logiciels font vivre du monde, ils coûtent très cher, et ont une valeur ajoutée importante. En revanche, développer un CMS isolé des logiciels utilisés dans les entreprises, (uniquement destinés à faire un site web), ceci représente un débouché professionnel plus réduit : avec l'Open source tu as fait le tour de la question.

La grande majorité des applications pour le web utilise une base de données. Les cas où une bdd n'est pas utile sont rares : - petit site web développé et maintenu par la même personne, - système de fichiers XML se substituant à un SGBDR. Donc seulement 2 cas de figure à ma connaissance.

En effet, en règle générale le statut de commerçant n'est pas possible pour un mineur. Donc tu ne peux ni créer une entreprise individuelle, ni être gérant d'une société commerciale. En clair tu n'as pas le droit de prendre la responsabilité d'une activité commerciale à l'égard des tiers quelle que soit la forme juridique que prend cette activité. Tu peux en revanche détenir des parts sociales, ou des actions d'une société commerciale, sans y prendre une part active.

C'est l'article 262 ter du code général des impots qui s'applique aux achats de biens matériels provenant de la communauté européenne. La transaction est en effet exonérée de TVA. Le preneur (zeb) est redevable de la TVA. Toutefois le fournisseur autrichien est solidairement responsable du règlement de cette TVA. Le fait que ton No de TVA intracommunautaire ne figure pas sur la facture, leur fait prendre le risque de devoir régler cette TVA en cas de défaillance de ta part. En ce qui concerne la possibilité d'utiliser un No de TVA qui n'est pas le tien = fraude à la TVA, tu risques un redressement, + un procès devant le Tribunal Administratif qui pourrait éventuellement finir au pénal.

D'accord avec Arlette, Slender et Brocexco. La question initiale de Frozen était : comment "se faire de l'argent de poche" légalement en cassant le prix des prestations professionnelles : ce n'est pas possible, économiquement et juridiquement. La réponse apportée "si tu ne pense pas atteindre les 1000 ne t'embète pas trop." me semble inacceptable car elle encourage Frozen (ou plutôt ses parents) à prendre des risques. Je ne veux pas jouer les pères-la-morale, mais prenez des risques pour vous mêmes si ça vous chante, à supposer que vous connaissez le domaine de la fiscalité (vous êtes inspecteur des impôts peut-être ?) , mais pourquoi vouloir faire prendre des risques aux autres ?(notamment les mineurs qui vont lire ce sujet).

Voici un début de réponse sur XML et les web services, qui pourraient répondre à ta problématique.

Je ne suis pas certain que cela change grand chose. Il n'y a que deux types de prestations à ma connaissance : - avec obligation de résultat : dans ce cas le remboursement ne suffit pas forcément à dédommager ton client - sans obligation de résultat : dans ce cas tu ne garantis rien : tu proposes un conseil en référencement (ou appelle le comme tu veux), mais le client est informé que ta prestation n'aboutit pas forcément à un PR 5. Ce sera peut-être PR3, PR4, PR5, PR6 : en tout cas tu l'auras aidé à atteindre l'objectif.

En (très) gros : Si tu connais un peu Ajax, la compréhension de SOAP est facilitée. Par exemple tu as une page sur ton site qui construit un fichier XML avec 2 chiffres pour contenu. L'envoi du fichier sur la page du site distant se fait via XMLhttp comme pour Ajax à partir d'IE. (En MS, c'est le même objet COM qui est utilisé. Je ne sais pas pour php. ) La page du site distant récupère les deux chiffres, les additionne à l'aide d'une classe qu'on peut appeler "addition()" et te les renvoit. Tu récupères le fichier XML qui contient le résultat sur ta page et tu l'affiches, ou tu t'en sers pour d'autres calculs, peu importe. Tout ça en temps réel bien sûr. Un web service , par rapport à SOAP, permet en plus : - d'utiliser directement la classe addition() depuis ton site, grâce à une norme XML : WSDL - de rendre publique cette classe addition() sur un annuaire (UDDI) En fait si tu publies un web service, le client de ton site, et de tes données, n'est pas un humain mais un autre site web ou tout autre logiciel ayant accès à http. En espérant t'avoir été utile

J'ai eu des sites chez Alentus.com au canada pendant 3 ans, le service est très réactif et professionnel. La bande passante est en revanche un peu limitée

Bonjour FranckB et bienvenue sur le Hub. Je fais une parenthèse sur les extranets de cabinet comptable : J'ai vu que tu avais l'outil Quadratus, il y a des experts comptables sur le forum, n'hésite pas à nous faire des retours d'expérience. Par ailleurs tu es invité à participer au forum Administration quand tu en auras le temps !

Une solution consiste à proposer votre catalogue en web service : il devient accessible de manière transparente, sur les sites Internet des revendeurs avec qui vous avez un contrat de distribution. De cette manière vous ne faites pas concurrence aux revendeurs, c'est au contraire un service, qui leur permet d'avoir les infos dont ils ont besoin en temps réel : dispo produit, produits en sommeil, commandes en temps réel, etc. Votre site fait la promotion de ce service auprès de la clientèle des revendeurs. Vous obtenez des parts de marché grâce à ce service.

J'adhère à ce qui vient d'être dit, le manque de notoriété est un frein peut être encore plus grand que pour un business classique. On peut tenter de résoudre ce problème avec de la transparence sur les stocks disponibles, et les délais de livraison. Toutefois, ce n'est pas toujours possible, surtout en B2B, car les concurrents ne doivent parfois pas connaître vos stocks... En fait la réussite d'un business en ligne suit les mêmes règles qu'un commerce classique : le choix, la disponibilité en stock, les prix, une bonne logistique, une bonne assise financière et des moyens marketing adaptés à la cible, et enfin une équipe dirigeante expérimentée et bien conseillée (mais il y a des contre-exemples, GrosBill a été fondé par des jeunes mordus d'informatique qui ont développé leur propre système d'information).

Mmmm....Je te conseille de t'adresser à des experts comptables français installés en Espagne. J'en connais deux, un à Madrid et un à Barcelone, si ça t'intéresse tu peux me MP.

Aucun problème avec une table de 40 colonnes (par ex la plupart des logiciels de gestion fonctionnent sur des schémas de tables avec de nombreuses colonnes), si ce n'est la limite physique pour un enregistrement qui va te contraindre à des formats de données de faible taille, selon la bdd que tu utilises et la nature des traitements. Ceci peut poser problème pour les développements futurs. Selon ma modeste expérence tu peux gérer un projet d'une centaine de tables de 5 à 40 colonnes sans dénormaliser, à condition d'avoir une base de données supportant les procédures stockées pour les requêtes complexes. La commande ON DELETE CASCADE est utile pour les suppressions sur des tables normalisées. Les triggers sont utiles si tu commences à dénormaliser.

Je crois qu'il faut être prudent. Quand un FAI facture un particulier, il n'est pas obligé de délivrer une facture. En revanche la loi oblige de délivrer une facture à un professionnel, car cette facture une fois inscrite en comptabilité, fait office de preuve pour les déductions fiscales, notamment la TVA. La facture ne peut être "électronique" (le terme dématérialisée est obsolète depuis la loi de 2003) que si elle est signée . La signature électronique, qui fait l'objet de la loi de 2003, fait intervenir un tiers de confiance (qui peut être une banque), via un prestataire de service informatique (exemple b-process), qui garantit que la facture émise par le fournisseur est bien identique à celle reçue par le client. Donc en effet, à moins que vous ne soyez une grande entreprise qui utilise les services d'un tiers de confiance, votre comptable va vous réclamer des factures papier aussi bien d'achat que de vente pour pouvoir faire son travail. Il suppose que les factures que vous lui remettez sont bien conformes avec celles que vos fournisseurs, de leur côté, ont enregistré, si ce n'est pas le cas, ceci peut poser un problème en cas de contrôle fiscal. C'est pourquoi je vous conseille de demander à vos fournisseur une facture papier pour confirmer la facture envoyée par mail, et qu'il vaut mieux envoyer à vos clients une facture papier dans tous les cas. Documentation en français sur ce sujet

C'est un des points forts du portage, toutefois le projet à tester ne doit nécessiter ni locaux, ni salarié, ni matériel ni financement non plus. En général c'est plutôt adapté à une activité de consultant, qui "revend" son expertise acquise au cours de son expérience professionnelle.

Un expert comptable ou un juriste te conseilleront sur ce point, il n'y a pas de réponse standard.

Le portage salarial n'est pas une alternative au CDI. Si le contrat a un caractère de CDI, la société de portage n'a pas le droit de se substituer à l'employeur car ceci reviendrait à détourner le droit du travail et à fragiliser la situation des salariés. Le portage salarial ne convient que pour des missions de courte durée auprès d'employeurs multiples.