[Aurélien]

Je transmets merci ! Bonne journée

[Aurélien]

de plus précision de Illona : la commande a buggé après avoir tenté de la migrer sur un autre séjour, ça vient de me faire pareil avec la CO9645, j’y avais accès jusqu’à ce que je la migre et maintenant j’ai le 505 error..

[Aurélien]

Bonjour, merci ! Nous avons déjà réalisé nos exports sur cette période, nous allons testé l’export de décembre début janvier.

Cdlt

[Aurélien]

Bonjour Roy / équipe technique,

Merci pour le correctif précédent : les montants négatifs sur les lignes transport ont bien disparu ✓

En revanche, sur les avoirs qui comportent des frais de transport, l’écriture reste déséquilibrée (total débit ≠ total crédit).

Exemple concret sur un avoir du 01/11/2025 (FAV16655 – CO8069) :

– Ligne 411… (Prix total) → Crédit 776,00
– Ligne 70600000 (Accro Montagne) → Débit 946,00
– Ligne 70600100 (Transports France) → Débit 170,00

→ Total débit = 1 116,00
→ Total crédit = 776,00
→ Déséquilibre de +340,00 en débit

Attendu (écriture équilibrée et logique) :
– 70600000 → 606,00 débit (776 – 170)
– 70600100 → 170,00 débit
→ Total débit = 776,00 = crédit client → parfaitement équilibré

En comparaison, un avoir sans frais de transport (même date) est lui parfaitement équilibré :
– Prix total → Crédit 733,00
– 70600000 (Vacances Méditerranéennes) → Débit 733,00

Le problème ne se produit donc que lorsqu’il y a une ligne transport sur l’avoir.

Actuellement, le montant mis sur la ligne produit (70600000) est manifestement le montant total de l’avoir + les frais de transport au lieu d’être le montant total de l’avoir − les frais de transport.

Le montant sur la ligne du compte 70600000 doit être la différence entre le montant crédité au client (ligne 411…) moins le montant des frais de transport (ligne 70600100), afin qu’il corresponde exactement au prix HT du séjour seul.

Pouvez-vous corriger cela définitivement pour tous les futurs exports (comme vous l’aviez fait pour les montants négatifs) ?

Merci d’avance,
Cordialement,

Attachments:

You must be logged in to view attached files.

[Aurélien]

Bonjour Roy, merci pour le correctif, nous avons déjà corriger les anciens fichiers CSV.
Bonne journée

[Aurélien]

Merci Roy, Je transmets bonne journée

[Aurélien]

Ok merci, je fais remonter l’information pour corriger le fichier.
Bonne journée

[Aurélien]

Bonjour Jean-Marc,
Ce que j’appelle la fiche du représentant légal, c’est l’endroit qui contient toutes les informations d’un RL dans le back-office. Depuis cette interface, nous pouvons cliquer sur « l’œil » pour nous connecter directement à son compte client.
À partir de là, nous avons essayé de reproduire le problème signalé par le client, à savoir le téléchargement de son trousseau.

Effectivement, lorsqu’on clique dessus, c’est un fichier HTML qui se télécharge.
Bonne journée,

[Aurélien]

Bonjour Roy,

Malheureusement, cette solution ne nous convient pas, car pour les grosses commandes, tous les RL ne soldent pas nécessairement leur commande en même temps. Cela peut entraîner un oubli de re-cochage pour la saison suivante au niveau du client, ce qui constitue une source d’erreur.
Merci pour votre retour. Nous restons dans l’attente d’un correctif.
Cordialement,

[Aurélien]

Bonjour Roy,

Merci pour votre retour.

Je me permets d’insister car votre réponse, tout comme celle de Maïssa, ne correspond pas à la situation rencontrée. Le point central de notre problème, et la raison de ma demande initiale, est justement que les actions de suppression ont échoué bien avant que la facture ne soit créée.

Pour être le plus précis possible, voici la chronologie exacte :

Le 26, 27, 30 juin et le 1er juillet : Nous avons effectué de multiples tentatives de suppression des enfants DOSSO sur la commande 9260.

À chaque fois : L’interface de Vackelys semble valider l’action (aucun message d’erreur n’apparaît), mais les participants restent visibles sur la commande.

Suite à ces échecs, et aux mêmes dates : Nous nous sommes résout à utiliser l’action « annulé », pour que les effectifs soient à jour. mais cela ne convient à notre besoin initiale ; supprimer l’inscrit et ne plus le voir sur la commande

La semaine suivante seulement : La facturation pour cette commande a été produite.

Le blocage par la facture n’est donc pas la cause du problème, mais une conséquence du fait qu’il a été impossible de nettoyer la commande en amont.

La vraie question est donc : Pourquoi, à ces dates précises, les suppressions n’ont pas fonctionné, alors que le système donnait l’impression de valider l’opération ?

[Aurélien]

Ah oui la c’est bon ! merci !

[Aurélien]

Super merci !
Par contre nous avons essayé sur plusieurs navigateur, vidée le cache sur plusieurs pc différents, mais le texte n’apparait toujours pas.

[Aurélien]

– Serait-il possible de ne pas activer cette fonction sur notre instance ? Nous utilisons le peu de flexibilité offert par le template de base afin de réaliser un peu de mise en forme sur notre page d’accueil, et nous avions d’ailleurs terminé une refonte récemment.

– Pourriez-vous également nous tenir informés lorsque vous réalisez ce type de modification, afin que nous puissions corriger au plus vite et comprendre rapidement d’où vient le problème ?

Merci

[Aurélien]

Bonjour,

Cela ne semble pas systématiquement lié à la facturation, par exemple sur la commande 9275.

Mélaine a essayé d’annuler Melkumyan Samuel la semaine passée. Sur le coup, la ligne disparaît, mais le vendredi suivant, il semble revenir dans la commande.

Elle l’a donc passé en annulé, car il est impossible de le supprimer de la commande.

De plus, cette commande n’a pas de facturation.

Merci de votre aide.

[Aurélien]

Mélaine me reprécise sa question :

pourquoi les multiples annulations de l’enfant DOSSO n’ont jamais été validées alors que je les ai enregistrées maintes fois ?
c’est bien parce que la suppression ne fonctionnait pas que j’ai du me résoudre à passer par l’action « annulé »

[Auteur]

Messages