Go to file
Paul Schneider 044142f8dd cleaning using refs 7 years ago
.nuget Passage à ASP.NET vNext 8 years ago
Assets a basket 8 years ago
CrossZicMoove wip - refacts 8 years ago
CrossZicMoove.Desktop wip - refacts 8 years ago
YaDaemon ... 8 years ago
Yavsc cleaning using refs 7 years ago
Yavsc.Abstract refactoring 7 years ago
ZicMoove refactoring 7 years ago
test a running test template (coreclr) 8 years ago
testOauthClient fixes environment names 7 years ago
wrap GCM Ok[Debug] 8 years ago
.eslintrc.json cs requires uname 8 years ago
Kobush.Build.dll packaging 8 years ago
LICENSE initial import 8 years ago
MSBuildLogger.dll packaging 8 years ago
README.md period 7 years ago
ZicMoove.sln refactoring 7 years ago
build a build scrpit 8 years ago
build.sh packaging 8 years ago
favicon.ico icone 8 years ago
favicon.xcf icone 8 years ago
global.json billing 7 years ago
gulpfile.js wip - refacts 8 years ago
msbuild.xsl packaging 8 years ago
paket.dependencies using Paket from VS Code 8 years ago
yavsc.mdw ya workspace 8 years ago

README.md

Bienvenue dans Yavsc

C'est une application mettant en oeuvre une prise de contact entre un demandeur de services et son éventuel préstataire associé.

Fonctionalités

Elle est censée aboutir à une prise commande, un payement du client, à une collecte du retour du client, et à un paiment du prestataire de services.

Elle comprendra une gestion des litiges.

Elle expose une messagerie instantanée, disponible depuis un navigateur Web ou depuis l'appplication mobile, pouvant garantir la preservation du secret sur toute information personnelle, du client comme du prestataire.

Ni le client ni le prestataire ne sont anonymes pour l'application, il sont même formellement authentifies, au moment de leur accord pour une première facturation en ligne, à l'occasion:

  • pour le client, à la validation d'une commande facturée (de prestation à un prestataire, ou autre).
  • pour le prestataire, de la validation de son profile proféssionnel, qui implique l'acquitement de son adhésion forfaitaire.

La séquence logique (et simplifiable) d'une prestation canonique (sans annulation ni reclamation) est la suivante :

  1. Une commande intervient auprés d'un prestataire, elle est chiffrée et le paiment est provisioné par PayPal, non collécté.
  2. Notifié, le prestataire valide un devis, avec arrhes ou avance. il signe son devis, qui peu contenir des documents attachés à faire signer par le client, un ou des contrats, stokés au format Markdown par le prestataire dans ses contrats à faire signer.
  3. à son tour, le client est notifié et signe le devis aussi
  4. Les arrhes ou avances sont débitées sur le champ
  5. 10 jours avant la date de la prestation le reste du paiement est collecté

Dans le cas des arrhes, à tout moment, jusqu'avant la date et l'heure de la prestation, le client ou le prestataire peuvent annuler:

  • Le prestataire peut le faire, en rendant les arrhes majorées de 20%
  • Le client peut le faire, en perdant les arrhes.
  • Le prestataire peut déléguer à une équipe de son choix un filtrage des demandes des clients.

Limitations temporaires

  • à une commande, une prestation, un paiment

Limitations conceptuelles

  • Dans le cas de l'avance, une fois le paiment client autorisé, pour le moment, aucune annulation de la préstation n'est supportée.
  • Une fois passée la date de la prestation, toute reclamation nécessitera l'intervention d'un système auxiliaire (un processus humain?)
  • Un seul moyen de paiment: PayPal, depuis le Web ou l'application mobile, son interface dite dépréciée NVP/SOAP.
  • Elle ne prendra pas en charge, du moins pas encore, ni la saisie de structures de projets complexes, ni ticketing associé à la prestation.
  • Les professionnels sont tous considérés comme tierces parties, horsmis le propriétaire de l'installation, dont les identifiants PayPal sont utilisés pour collecter tous les paiments. Aucune edition de fiche de paye ni paiment en masse ne sont supportés. Seul les payments unitaires sus-cités le sont.

Développement

Nouvelle activité

L'impact d'une custo de son activité pourrait à peu près tout concerner. Un bon point de départ est la création d'un controller de commande dédié, enrichi des données de profile associées à un nouveau type de profiles prestataire.

Ceci implique:

  • Un modèle de donnée, un controleur web, ses vues et son API pour:
    • Le profile prestataire, dont la donnée est représentée par une classe arbitraire
    • L'éventuelle commande customisée, dont la donnée réalise l'objet abstrait 'NominativeServiceCommand'

Un nouvel environnement d'execution

L'impact de l'usage d'un nouveau nom d'environement d'execution, à l'heure de cet écrit, ressemble à ceci:

  • Ajustement des listes d'environements cités dans les pages:
    • ~/Views/Shared/_Layout.cshtml
    • ~/Views/Shared/_ValidationScriptsPartial.cshtml
    • ~/Views/Home/Index.cshtml
    • ~/Views/Home/About.cshtml