Une commande, plusieurs banques, plusieurs prix

[nikodes]

Bonjour,

Première boutique, pas encore installé de module de paiement.
Phase de signature avec mon client, il souhaite :

1 - que l'utilisateur puisse payer sa commande mais que cette derniere envoi le paiement a plusieurs banques/comptes (TPE je crois ?)
Les produits n'appartiennent pas à la même entité juridique/commerciale, il y en à 3. Il doit falloir identifier les 3 "catégories" de produits dont le destination paiement est différente, puis à une étape (?) de configuration, déterminer ces 3 destinations ?? Comment ?

2 - avoir le même "catalogue produits " mais avec des prix client Pro (magasins), un peu façon intranet. J'ai pensé bêtement et simplement aux codes réductions, ou remises, mais c'est un peu de la bricole, les prix grands publics étant toujours affichés .. 2 sites différents ? 2 bases de données ? Un log client sur le front grand public pour les amener ailleurs, ou sur place mais avec des prix différents ?
D'avance merci ...

[LIKEAROBOT]

Bonjour,
Je crois que l'expression "usine à Gaz" prend un sens concret dans ce projet....
1- Je ne pense pas que techniquement et bancairement parlant que cela soit possible. Bonjour le casse tête pour le comptable. Je pense qu'il est plus simple que tout arrive sur un compte et qu'il soit dispatché ensuite soit par le client (ou le comptable, ou la banque)...
Un site marchand ne peut appartenir qu'à une seule entité juridique à moins de faire une nouvelle société dans laquelle plusieurs société auraient des parts. Mais tout dépend de l'activité exercée. Donc pour rediriger un paiement en fonction de l'entité cela va être compliqué... Il faudrait mieux que le site soit gérer par une société à part qui recommissionne ensuite les autres...

2- je ne pense avoir tout compris. Mais l'idée du bon de réduction n'est pas idiote puisque les prix affiché seraient tout public et le bon de réduction (que tu peux renommer en 'identifiant Pro') servirait au final de remise professionnelle...

Bon courage...

A +++

[nikodes]

Merci pour cette réactivité que j'apprécie. Usine à gaz, tout à fait d'accord, c'est dans cette "direction" que je voulais amener la discussion avec mon client (+ de dév, plus de temps, plus de gestions, plus de risques ...) Pour la question 2, je vais "re-poster" plus en détails, et rechercher/réfléchir davantage... Merci

[ningu]

Pour 1/, je ne vois pas trop comment ca peut marcher.

Si un client, dans une même commande, demande 2 produits qui appartiennent à des entités commerciales différentes, comment doit s'effectuer le paiement ?
Il faut recalculer ce qui doit être payé sur chacune des entités ? et comment gérer le fait qu'une sous-partie soit payée mais pas l'autre ?....
Quid des frais de ports ? des bons de rédustions ? qui sont globaux à la commande ....
Ca n'a pas l'air simple....

Une piste, mais pas sûr que côté client final ce soit le top :
-- en plus des catégories classique, créer 3 catégories correspondant aux entités commerciales.
-- associer chacun des produits à la bonne entité (jusque là pas de souci)
-- créer 3 groupes de clients, 1 par entité
-- côté moyen de paiement, créer les 3 associés à chacune des entités, et restreindre leur usage chacun des groupes de clients (par l'onglet paiement en BO)
-- ensuite, lors de la validation du panier, AVANT de proposer les moyens de paiements, vérifier que la panier ne comporte qu'une seule catégorie :
si ok, modifier les groupes auxquels appartient le client, pour n'avoir que celui du panier => 1 seul moyen de paiement visible
si non OK, indiquer aux clients qu'il faut faire plusieurs commandes

Ou alors carrément plus simple, créer 3 comptes par client final, chaque compte étant associé à un groupe de client.