| chat.freenode.net #tryton-fr log beginning Thu Dec 22 00:00:02 CET 2011 | ||
| 2011-12-22 16:34 <jcm> sisalp, cedk : bonjour | ||
| 2011-12-22 16:35 <cedk> jcm: bonjour | ||
| 2011-12-22 16:35 <sisalp> yop | ||
| 2011-12-22 16:36 <jcm> par quoi commence-t-on ? rebate ? | ||
| 2011-12-22 16:37 <cedk> ok pour moi | ||
| 2011-12-22 16:37 <sisalp> ok | ||
| 2011-12-22 16:37 <jcm> product_price-list_party_rebate marche en 2.2 (ne fait pas d'erreur au lancement du serveur) mais ne transmet pas rebate à une vente | ||
| 2011-12-22 16:37 <jcm> est-ce moi qui n'ai pas compris l'usagge? | ||
| 2011-12-22 16:38 <sisalp> comment l'utilises tu ? | ||
| 2011-12-22 16:38 <jcm> j'ai fait une liste de prix intitulée Remise liée au tiers, avec la formule unit_price*(100-rebate)/100 | ||
| 2011-12-22 16:38 <jcm> et mis dans le tiers 32 en rebate | ||
| 2011-12-22 16:39 <sisalp> tu utilises cette liste dans la commande et le prix n'est pas réduit ? | ||
| 2011-12-22 16:40 <jcm> non, la liste est attachée au tiers sur l'onglet Liste de prix du tiers | ||
| 2011-12-22 16:40 <jcm> il faudrait que je la rementionne encore lors de la vente? | ||
| 2011-12-22 16:41 <cedk> jcm: le module sale_price_list le fait automatiquement | ||
| 2011-12-22 16:43 <jcm> mes excuses, avec une nouvelle vente ça marche. Avec la vente ouverte avant que je saisisse le Rebate du party, impossible de voir la liste de prix et le rebate | ||
| 2011-12-22 16:43 <jcm> ça adonc l'air de bien marcher | ||
| 2011-12-22 16:44 <cedk> jcm: on doit stocker la liste de prix utiliser pour la vente | ||
| 2011-12-22 16:44 <cedk> jcm: mais les prix sont calculés à la selection du produit | ||
| 2011-12-22 16:44 <jcm> ok, c'était ça le problème, je n'avais pas compris que ça passait par la liste de prix | ||
| 2011-12-22 16:44 <jcm> donc a priori ok pour moi pour ces modules rebate | ||
| 2011-12-22 16:45 <sisalp> :-) | ||
| 2011-12-22 16:46 <jcm> pour carrier je suis plus perplexe | ||
| 2011-12-22 16:46 <jcm> il semble que le carrier qu'on désigne dans gestion des ventes soit sélectionné par le tiers associé dasn la fiche Carrier | ||
| 2011-12-22 16:47 <jcm> en France, Coliposte est le tiers commercialisant une douzaine de services de transport | ||
| 2011-12-22 16:47 <jcm> je ne trouve pas comment appeler dans une vente un autre service carrier que le premier que j'ai désigné | ||
| 2011-12-22 16:48 <jcm> cedk: je crois que tu avais noté d'ajouter Nom de tiers + Nom de produit pour désigner le carrier | ||
| 2011-12-22 16:48 <jcm> est-ce bien cela la solution ? | ||
| 2011-12-22 16:48 <cedk> jcm: c'est une possibilité | ||
| 2011-12-22 16:52 <jcm> le fond du problème c'est ce que carrier (transporteur) dsigne : service ou compagnie ? | ||
| 2011-12-22 16:52 <jcm> il me semble que dans le formulaire vente, c'est le service | ||
| 2011-12-22 16:53 <cedk> jcm: c'est le lien entre un fournisseur et le service | ||
| 2011-12-22 16:54 <jcm> donc tu es d'accord qu'il faut le désigner sous un autre nom que celui du fournisseur seul ? pourrait être Fournisseur: Service | ||
| 2011-12-22 16:55 <jcm> pourquoi le fournisseur n'est pas renseigné simplement sur la fiche produit du service ? | ||
| 2011-12-22 16:56 <sisalp> j'ai installé carrier et mon formulaire devis n'est pas modifié. Normal ? | ||
| 2011-12-22 16:56 <cedk> sisalp: il faut sale_shipment_cost | ||
| 2011-12-22 16:57 <cedk> jcm: je ne l'ai pas mis sur le produit car je pense que ce n'est pas un bon design | ||
| 2011-12-22 16:58 <cedk> jcm: j'ai fait un patch vite fait: http://codereview.tryton.org/206004 | ||
| 2011-12-22 16:58 <cedk> jcm: j'ai pas testé | ||
| 2011-12-22 16:59 <jcm> ok je vais regarder | ||
| 2011-12-22 16:59 <jcm> je ne comprends pas l'argument du design | ||
| 2011-12-22 16:59 <cedk> jcm: tout les produits ne sont pas des services de livraison | ||
| 2011-12-22 16:59 <jcm> pourquoi pour ce service faut-il avoir le fournisseur de manière diffrente des autres produits? | ||
| 2011-12-22 17:00 <cedk> jcm: parce que c'est un produit qui se comporte différement des autres produits | ||
| 2011-12-22 17:01 <cedk> et aussi non, on a rien qui le différencie d'un autre produit | ||
| 2011-12-22 17:01 <jcm> cedk: en exégérant, on pourrait imaginer que je vende des clous avec une grille de prix variant au poids ou des séjours avec un prix variant au nombre de jours | ||
| 2011-12-22 17:02 <jcm> ne serait-ce pas des produits requérant la même logique de liste de prix et d'unité que carrier ? | ||
| 2011-12-22 17:02 <sisalp> j'ai mis sale_shipment_cost, je ne vois rien de changé | ||
| 2011-12-22 17:04 <cedk> jcm: non parce que tu a une quantité sur la ligne | ||
| 2011-12-22 17:04 <jcm> sisalp: il faut aussi carrier_weight et sale_shipment_cost_weight | ||
| 2011-12-22 17:05 <sisalp> je m'attendais à un nouveau type de ligne | ||
| 2011-12-22 17:07 <jcm> cedk: ce serait parfait avec le total de poids qui apparaîtrait sur la vue vente | ||
| 2011-12-22 17:08 <cedk> jcm: mais la livraison n'est pas un calcul poid * prix unitaire | ||
| 2011-12-22 17:10 <jcm> les clous au poids ont aussi une grille de prix complètement sans rapport avec un prix unitaire ;-) | ||
| 2011-12-22 17:10 <jcm> je veux dire qu'un certains nombre de produits et surtout de services ont des grilles dépendant d'une unité de quantité particulière | ||
| 2011-12-22 17:11 <cedk> jcm: ben non, un clou a un poid unitaire | ||
| 2011-12-22 17:12 <sisalp> cedk : un kilo de clous pèse a peu près 1000 grammes non ? | ||
| 2011-12-22 17:13 <sisalp> si c'est des clous variés de poids variable aussi | ||
| 2011-12-22 17:14 <cedk> sisalp: si tu vend au poid, tu vend au poid | ||
| 2011-12-22 17:14 <sisalp> on est d'accord | ||
| 2011-12-22 17:14 <jcm> je ne comprends pas la différence entre une grille de prix de transport : prix = f(poids transporté) et une grille, par exemple, prix de clous = f(poids acheté), ou prix séjour = f(durée) | ||
| 2011-12-22 17:14 <cedk> sisalp: et donc tu a un prix unitaire au poid | ||
| 2011-12-22 17:15 <jcm> autrement dit, product + price_list + modification pour avoir l'unité de la première colonne = carrier et pourrait servir pour d'autres cas | ||
| 2011-12-22 17:15 <cedk> jcm: parce que la grille de prix de livraison n'est pas continue | ||
| 2011-12-22 17:18 <cedk> vous avez déjà vu une facture avec: frais de livraison 10kg: 20€ | ||
| 2011-12-22 17:18 <cedk> ou: fraise de livraison 200 dcm³: 25€ | ||
| 2011-12-22 17:19 <cedk> d'autant plus que c'est pas la société qui fix le prix | ||
| 2011-12-22 17:20 <cedk> comment on corrige un prix qui est calculer par le système pour qu'il corresponde exactement au prix du fournisseur? | ||
| 2011-12-22 17:20 <cedk> l'utilisateur doit faire une règle de 3 à chaque fois? | ||
| 2011-12-22 17:22 <jcm> c'est vrai que la particularité des frais de port c'est qu'ils sont refacturés | ||
| 2011-12-22 17:23 <jcm> bon, c'est pas grave, je posais juste la question car il me semblait que le mécanisme mis dans carrier aurait pu être dans product | ||
| 2011-12-22 17:23 <jcm> moi ça me va bien comme c'est puisque ça marche! | ||
| 2011-12-22 17:24 <sisalp> je n'ai pas les bons modules. jcm : en fin de création des lignes on choisit un produit transport ? | ||
| 2011-12-22 17:27 <cedk> sisalp: ces modules sont dans la 2.2 releasée | ||
| 2011-12-22 17:27 <jcm> cedk: super le patch | ||
| 2011-12-22 17:27 <cedk> jcm: le patch que j'ai fait ne pourra pas être backporté dans 2.2 mais tu peux l'appliqué tout seul | ||
| 2011-12-22 17:27 <jcm> sisalp : si tu as toujours accès à mon wiki, regarde tous les modules dans la page Tryton install ;-) | ||
| 2011-12-22 17:28 <sisalp> il faut que je trouve pourquoi je ne les ai pas | ||
| 2011-12-22 17:28 <jcm> cedk: je suis sur 2.2 et je garde ma liste de patchs à appliquer, pas de pb | ||
| 2011-12-22 17:28 <jcm> cedk: je reste persuadé que le terme carrier (transporteur) est trompeur | ||
| 2011-12-22 17:29 <jcm> je dirais en français Services de transport (Carrier services) | ||
| 2011-12-22 17:30 <cedk> jcm: c'est parce que le design est un peu particulier c'est un inherits | ||
| 2011-12-22 17:31 <cedk> comme le product.product et product.template | ||
| 2011-12-22 17:31 <cedk> mais entre carrier et party.party | ||
| 2011-12-22 17:32 <sisalp> j'ai 2.2.1 | ||
| 2011-12-22 17:33 <cedk> sisalp: normallement tu devrais avoir tout ce qu'il faut sauf les module rebate | ||
| 2011-12-22 17:35 <sisalp> récupéré par hg nclone http://hg.tryton.org/2.2/trytond/ | ||
| 2011-12-22 17:36 <jcm> cedk: il te reste donc à faire account_invoice_rebate ? | ||
| 2011-12-22 17:36 <cedk> jcm: oui | ||
| 2011-12-22 17:37 <cedk> jcm: j'attendais confirmation pour sale_invoice_rebate | ||
| 2011-12-22 17:37 <jcm> peux-tu me réexpliquer ce que fera account_invoice_rebate ? | ||
| 2011-12-22 17:38 <cedk> jcm: la même chose que sale_rebate | ||
| 2011-12-22 17:38 <cedk> jcm: donc afficher le list_price du produit et le percentage entre le list_price et le unit_price | ||
| 2011-12-22 17:39 <jcm> est-ce long pour toi ? | ||
| 2011-12-22 17:40 <cedk> jcm: une soirée | ||
| 2011-12-22 17:41 <cedk> jcm: mais j'aimerai modifier sale_rebate pour enregistrer sur la ligne le list_price au lieu de le relire de la fiche produit | ||
| 2011-12-22 17:41 <cedk> jcm: car s'il change entre temps le rabais va changer aussi | ||
| 2011-12-22 17:41 <jcm> ah oui, ce serait bien que les ventes soient immuables ;-) | ||
| 2011-12-22 17:42 <sisalp> idealement, if faudrait un bouton "actualiser" (prix, taxes, poids, ...) sur les drafts | ||
| 2011-12-22 17:43 <jcm> le on_change n'est pas déclenché par la sortie d'un champ ? | ||
| 2011-12-22 17:44 <jcm> "list_price" n'est pas traduit : est-ce que ce serait 'prix catalogue' ? | ||
| 2011-12-22 17:46 <cedk> jcm: prix listé | ||
| 2011-12-22 17:47 <sisalp> mais prix listé ne veut rien dire en France | ||
| 2011-12-22 17:48 <jcm> je n'ai jamais entendu ce terme ;-) | ||
| 2011-12-22 17:48 <jcm> sauf dans le livre OpenERP | ||
| 2011-12-22 17:50 <cedk> ben c'est pareil que prix catalogue | ||
| 2011-12-22 17:50 <jcm> ok ;-) | ||
| 2011-12-22 17:51 <cedk> sisalp: pourrait remplacer dans la traduction | ||
| 2011-12-22 17:51 <jcm> je vais soumettre des corrections pour le français | ||
| 2011-12-22 17:53 <jcm> existe-t-il la variante fr_be et fr_fr ? | ||
| 2011-12-22 17:54 <cedk> jcm: non | ||
| 2011-12-22 17:54 <jcm> il me semble que certains termes sont différents entre Belgique, Suisse(fr), Québec et France | ||
| 2011-12-22 17:55 <jcm> sans parler du Bénin, Cameroun et autres lieux où le français est encore langue officielle | ||
| 2011-12-22 17:55 <jcm> nous disons par exemple hors taxe (H.T.° au lieu de non-taxé | ||
| 2011-12-22 17:55 <sisalp> il faut aussi traduire entre toulon et annecy ;-) | ||
| 2011-12-22 17:56 <jcm> sisalp: commençons par les variantes par pays ;-) | ||
| 2011-12-22 17:56 <cedk> jcm: si quelqu'un veut faire le travail pq pas | ||
| 2011-12-22 17:57 <sisalp> à toulon, prix=remisé se dit "tombé du camoin" | ||
| 2011-12-22 17:57 <sisalp> camion | ||
| 2011-12-22 17:57 <jcm> :-] | ||
| 2011-12-22 17:58 <jcm> si je me souviens bien le point suivant serait invoice | ||
| 2011-12-22 17:58 <jcm> ah pardon, le calendrier avant : | ||
| 2011-12-22 17:58 <jcm> cedk: penses-tu possible de faire account-invoice-rebate avant la fin de sem prochaine .? | ||
| 2011-12-22 17:59 <sisalp> cedk: mon hg nclone plus haut est correct ? | ||
| 2011-12-22 18:00 <jcm> sisalp: j'avais noté sans / final | ||
| 2011-12-22 18:00 <cedk> jcm: oui | ||
| 2011-12-22 18:00 <cedk> sisalp: oui | ||
| 2011-12-22 18:02 <jcm> cedk: pour l'ajout du total de poids sur la vue vente, dois-je l'ajouter au bugtracker? | ||
| 2011-12-22 18:03 <jcm> et comment pourrait-on ajouter une ligne d'emballage avec un poids librement éditable ? | ||
| 2011-12-22 18:03 <cedk> jcm: une ligne? | ||
| 2011-12-22 18:03 <jcm> sinon il va falloir régulièrement retoucher le calcul du port qui ne tombera pas dans la bonne tranche de poids | ||
| 2011-12-22 18:04 <sisalp> dans le calcul du poids on a une tare, mais il ne faut pas faire apparaitre une ligne tare | ||
| 2011-12-22 18:06 <jcm> sisalp: les livres que nous vendons sont toujours répertoriés poids brut sans emballage, et l'emballage dépend des autres livres de la même commande | ||
| 2011-12-22 18:06 <jcm> il faut donc que le préparateur détermine l'emballage choisi et l'ajoute à la liste (pour la gestion du stock) | ||
| 2011-12-22 18:06 <jcm> la ligne entre dans le calcul du poids pour le port | ||
| 2011-12-22 18:07 <jcm> mais n'apparait pas sur la facture car nous ne refacturons pas l'emballage et informer le libraire de la marque de l'emballage n'a pas d'intérêt | ||
| 2011-12-22 18:07 <cedk> jcm: c'est un peu compliqué de faire cela car je fait en sort que le système puisse un jour supporter des parcels | ||
| 2011-12-22 18:07 <cedk> jcm: du coup, il n'y a pas necessairement 1 seul poid | ||
| 2011-12-22 18:08 <jcm> parcels = plusieurs colis par commande ? | ||
| 2011-12-22 18:08 <cedk> jcm: oui | ||
| 2011-12-22 18:08 <jcm> le multi colis, en ce qui nous concerne, représente 1 à 3% de nos expéds | ||
| 2011-12-22 18:09 <jcm> mais ce problème d'emballage à compter pour le poids mais à ne pas facturer est partagé par d'autres métiers, et en particuliers toutes les ventes web | ||
| 2011-12-22 18:10 <jcm> pour le multicolis, il y aura le problème du calcul du port : pour UPS le prix du port est global au poids du total, pour les autres transporteurs c'est calculé par colis | ||
| 2011-12-22 18:12 <jcm> on pourrait imaginer dans la vue ventes, d'insérer des lignes de sous-total terminant un colis, qui généreraient en-dessous d'elles le calcul du port par colis si une case Calculer par colis était cochée dans carrier | ||
| 2011-12-22 18:14 <sisalp> jcm: par un type de ligne spécialisé ? | ||
| 2011-12-22 18:17 <jcm> pourquoi pas ? | ||
| 2011-12-22 18:18 <jcm> enfin ça c'était une idée pour traiter ultérieurement le multicolis. | ||
| 2011-12-22 18:18 <jcm> Ajouter une ligne d'emballage avec option 'ne pas mettre sur la facture' serait pour l'instant le mieux | ||
| 2011-12-22 18:23 <cedk> jcm: si c'est juste ajouté un poid au calcul, il suffit d'un champ sur le formulaire | ||
| 2011-12-22 18:23 <jcm> sûrement mieux, car pour l'instant une ligne de vente avec prix à zéro est refusé$ | ||
| 2011-12-22 18:24 <jcm> donc on pourrait ajouter un champ éditable Poids emballage et un champ d'information non éditable Poids total | ||
| 2011-12-22 18:24 <jcm> seul défaut: on ne peut pas gérer les stocks d'emballages | ||
| 2011-12-22 18:29 <cedk> jcm: ben alors met une ligne d'emballage | ||
| 2011-12-22 18:29 <jcm> ou alors il faut que le préparateur ajoute un mouvement pour l'emballage lors du traitement de l'expédition ? | ||
| 2011-12-22 18:30 <cedk> jcm: ben oui puisque c'est lui qui le choisit | ||
| 2011-12-22 18:35 <jcm> ok, ça marchera comme ça | ||
| 2011-12-22 18:37 <jcm> je viens d'essayer: j'ai le message 'Le champ 'prix unitaire' de 'mouvement de stock' est requis' quand je tente de Faire l'expédition | ||
| 2011-12-22 18:38 <jcm> aucun champ de ce type dans les onglets de la vue expéditions client | ||
| 2011-12-22 18:45 <cedk> jcm: on prend le prix du produit | ||
| 2011-12-22 18:45 <cedk> jcm: est-ce qu'il en a un? | ||
| 2011-12-22 18:46 <jcm> non puisque je ne le revends pas, j'ai mis seulement un prix d'achat | ||
| 2011-12-22 18:47 <cedk> jcm: ben il en faut un | ||
| 2011-12-22 18:50 <jcm> ok, ça marche avec un prix | ||
| 2011-12-22 18:50 <jcm> ce workflow ne me satisfait pas : tant que le préparateur ne marque pas l'expéd comme faite, on ne peut pas valider la facture | ||
| 2011-12-22 18:50 <jcm> or la facture doit être le plus souvet mise dans le colis | ||
| 2011-12-22 18:51 <jcm> le responsable ventes qui fait les factures ne peut pas être derrirèe le préparateur à valider chaque facture | ||
| 2011-12-22 18:52 <jcm> actuellement on décide l'emballage au moment de faire la facture, et les factures sont finies avant le début de l'emballage | ||
| 2011-12-22 18:52 <jcm> parfois il y a des erreurs mineures de poids, on ne corrige pas | ||
| 2011-12-22 18:52 <jcm> et si l'eerreur est trop importante, on refait la facture | ||
| 2011-12-22 18:56 <cedk> https://bugs.tryton.org/issue2022 | ||
| 2011-12-22 18:57 <cedk> jcm: ben fait la facture à la confirmation de l'ordre | ||
| 2011-12-22 18:58 <jcm> cedk: si je passe en facturation à la commande au lieu de expédition, je n'ai pas de moyen d'avoir le poids d'emballage inclus dans le calcul du port | ||
| 2011-12-22 18:59 <jcm> donc il nous faut le champ pour ajouter un poids d'emballage dans la vue | ||
| 2011-12-22 18:59 <cedk> jcm: je comprend pas tu veux la facture avant l'emballage et en même temps le poid sur la facture, c'est pas possible | ||
| 2011-12-22 19:00 <jcm> c'est le problème : on facture le port et on doit mettre la facture dans le colis, et en plus c'est pas la même personne qui fait la facture et qui fait le colis :/ | ||
| 2011-12-22 19:01 <cedk> jcm: ben c'est un problème d'organisation pas de logiciel | ||
| 2011-12-22 19:02 <jcm> il faut choisir entre facturer le port exact et bien être à deux pour faire les commandes, ou bien estimer le port et découpler les deux ttâches | ||
| 2011-12-22 19:02 <cedk> c'est le problème de l'oeuf et de la poule | ||
| 2011-12-22 19:02 <jcm> dans ce dernier cas il faut un moyen d'ajouter une estimation de poids d'emballage à la facturation | ||
| 2011-12-22 19:02 <bechamel> cedk: jcm: c'est pas le role des pro-forma ? | ||
| 2011-12-22 19:02 <jcm> c'est comme ça que nous fonctionnons actuellement | ||
| 2011-12-22 19:03 <jcm> bechamel: proforma c'est quand on envoie une future copie de facture pour réglement avant envoi | ||
| 2011-12-22 19:03 <cedk> bechamel: ça change rien | ||
| 2011-12-22 19:05 <jcm> pour résumer : sur la vue vente, pourrait-on ajouter un champ éditable Poids emballage et un champ d'information non éditable Poids total ? | ||
| 2011-12-22 19:05 <jcm> le top étant que les lignes affichent aussi leur total de poids | ||
| 2011-12-22 19:05 <cedk> jcm: on peut tout faire | ||
| 2011-12-22 19:06 <cedk> jcm: mais je vois ce que ça va changer | ||
| 2011-12-22 19:06 <cedk> jcm: mais je ne vois pas ce que ça va changer | ||
| 2011-12-22 19:08 <cedk> il faut d'abord définir le flux de travail sinon on ne s'en sortira jamais | ||
| 2011-12-22 19:09 <jcm> sur la vue vente, le calcul des frais de port par carrier et carrier_weight marche bien, mais on ne voit pas le total de poids et donc on ne peut pas vérifier que le bon tarif est appliqué | ||
| 2011-12-22 19:10 <cedk> jcm: ben pq vérifier et comment? | ||
| 2011-12-22 19:10 <jcm> par ailleurs il faut pouvoir ajouter une 'tare' ou un poids supplémentaire à prendre en compte (l'emballage dnas notre cas) dans le calcul du transport | ||
| 2011-12-22 19:11 <jcm> cedk: je veux dire pour que l'opérateur puisse vérifier que le tarif appliqué est bien celui prévu, pouvoir faire des eessais en changeant de transporteur | ||
| 2011-12-22 19:11 <cedk> jcm: mais je vois pas ce qu'il peut vérifier sinon si c'est si simple de calculer, y avait pas besoin de la faire faire par le logiciel | ||
| 2011-12-22 19:12 <cedk> jcm: si on ne fait pas confiance au calcul de prix, pourquoi le faire au calcul du poid | ||
| 2011-12-22 19:12 <jcm> on a l'habitude et on sait si c'est bon ou pas, mais des fois il y a erreur sur le transporteur : entre France et Europe, ce n'est pas le même tarif; pour avoir une idée du tarif, il faut pouvoir lire le poids... | ||
| 2011-12-22 19:14 <cedk> jcm: si le tarif est faux pq le poid ne le serait pas | ||
| 2011-12-22 19:16 <jcm> je reformule car nous ne nous comprenons pas : le responsable ventes faisant sa facture a en tte les frais de port impliqués dans une vente, et il souhaite pouvoir les vérifier d'un coup d'oeil en voyant le trio poids/transporteur/prix. Surtout que dans les cas rares (gros colis) il va essayer d'autres transporteurs pour comparer. | ||
| 2011-12-22 19:17 <jcm> s/en tte/en tête/ | ||
| 2011-12-22 19:17 <cedk> jcm: ajoute le champs sur sale a le même problème que pour le shipment, c'est conçu pour les parcels | ||
| 2011-12-22 19:20 <jcm> avec du multicolis (= parcels) il y aura aussi le problème de prendre en compte le poids des emballages avant de les avoir choisis | ||
| 2011-12-22 19:22 <cedk> jcm: je trouve que cette manière de travailler est tordue | ||
| 2011-12-22 19:22 <jcm> dit autrement, carrier actuellement ne fonctionne que pour des sociétés vendant des produits déjà emballés. Emballer à la commande ne fonctionne pas puisque'on ne peut pas indiquer le poids de l'emballage | ||
| 2011-12-22 19:23 <jcm> cedk: désolé, je n'ai pas trouvé mieux mais je suis preneur | ||
| 2011-12-22 19:23 <cedk> jcm: envoyer la facture par apres | ||
| 2011-12-22 19:23 <jcm> cedk: ce n'est pas une option sur notre marché, les librairies exigent à 95% de recevoir la facture dans le colis... | ||
| 2011-12-22 19:24 <cedk> jcm: quoi y a des gens qui veulent recevoir les facture plutôt ? | ||
| 2011-12-22 19:25 <jcm> cedk: ils ont besoin de les recevoir parce qu'ils gèrent un stock immense (la librairie est une métier de stock) et qu'ils doivent en plus parfois refacturer des frais de port au client lorsqu'il s'agit d'une commande; ils ne peuvent pas le faire sans avoir la facture... mmême s'ils ne la payent que 1 à 3 mois après... | ||
| 2011-12-22 19:26 <jcm> commande = demande d'un client; réassort = demande de la librairie | ||
| 2011-12-22 19:26 <cedk> jcm: mais on peut mettre tout ces info sur la bon de livraison | ||
| 2011-12-22 19:26 <jcm> cedk: je veux bien en discuter mais on ne changera pas les usages de la profession :/ | ||
| 2011-12-22 19:28 <jcm> le problème est lié aux taxes aussi : je peux refacturer le port au prix exact et dans ce cas, j'applique la TVA du produit principal (taux réduit), sinon c'est un service (taux maxi) | ||
| 2011-12-22 19:29 <cedk> jcm: ça n'a rien avoir avec le fait de mettre la facture dans le colis | ||
| 2011-12-22 19:30 <jcm> c'est un peu lié: si c'était forafaitaire je pourrais le calculer sans tenir compte du poids de l'emballage ; or là je dois calculer le poids et le port précis (le plus possible) | ||
| 2011-12-22 19:31 <cedk> jcm: il n'y a qu'un manière correct de faire, c'est d'avoir le prix de la livraison et de le noter sur le shipment | ||
| 2011-12-22 19:31 <cedk> jcm: tout autre solution n'est qu'une approcimation | ||
| 2011-12-22 19:32 <jcm> cedk: dans ce cas il faut pouvoir mettre le bon emballage sans pour autant le facturer (donc bug du prix à 0) | ||
| 2011-12-22 19:33 <cedk> jcm: il ne sera pas facturé | ||
| 2011-12-22 19:36 <jcm> pour être sur de t'avoir bien compris: - pas de case pour ajouter du poids à la vente — ajout d'une ligne d'emballage avec poids et prix à zéro sur la vente | ||
| 2011-12-22 19:36 <sisalp> cedk : je suis d'accord. noter sur le shipment est la seule solution propre, mais ça doit déclencher la validation de la facture si on veut l'inclure au colis. | ||
| 2011-12-22 19:38 <cedk> sisalp: quand? | ||
| 2011-12-22 19:43 <sisalp> cedk: juste avant le scotch ;-) | ||
| 2011-12-22 19:43 <cedk> sisalp: ça ne peut se faire que quand le shipment est done car sinon dans les autres états on peut le remettre en draft | ||
| 2011-12-22 19:45 <sisalp> cedk: oui, je pense | ||
| 2011-12-22 19:47 <jcm> donc: facturation à la livraison, ajout de l'emballage dans le shipment, qui viendra modifier le total de frais de port, validation facture, impression facture, fermeture de l'emballage | ||
| 2011-12-22 19:47 <jcm> c'est bien ça ? | ||
| 2011-12-22 19:48 <jcm> le gros avantage de l'approximation est que dans 90% des cas, la facture n'est pas à retoucher après la préparation du colis et que du coup, il n'y a pas d'intervention sur la facture au moment del'emballage :/ | ||
| 2011-12-22 19:49 <sisalp> jcm: ben, c'est à toi qu'on le demande. | ||
| 2011-12-22 19:49 <jcm> clairement, ce n'est pas comme cela qu'on procède actuellement | ||
| 2011-12-22 19:50 <jcm> on préfère approximer le poids d'emballage (c'est meme une fonction à peu près linéaire du poids total de la commande) et se tromper de temps en temps | ||
| 2011-12-22 19:50 <sisalp> je pense qu'on devrait pouvoir prévoir sur le devis et corriger sur le shipment et valider la facture | ||
| 2011-12-22 19:50 <jcm> que devoir valider les factures une fois l'envoi préparé | ||
| 2011-12-22 19:51 <sisalp> dans le cas ou on accepte de ne pas pouvoir corriger, alors il n'y a rien à faire de particulier. | ||
| 2011-12-22 19:51 <jcm> si on voulait modéliser notre fonctionnemenbt, il faudrait une "réservation de poids pour emballage", qui pourrait êtrre une ligne de vente ne contenant que du poids | ||
| 2011-12-22 19:52 <jcm> sisalp: si la facture ne comprend pas le poids de l'emballage, on changera toujours de catégorie de tarif de transport lors de l'emballage | ||
| 2011-12-22 19:54 <sisalp> la facture ne comporte pas le poids, mais le prix qui est calculé après colisage dans mon esprit, sur une prévision de poids dans ton message précédent | ||
| 2011-12-22 19:56 <sisalp> pour un utilisateur, il est agréable de pouvoir prédire, puis, le moment venu de changer, et que le logiciel remette tout d'aplomd au dernier moment, enfin, je pense | ||
| 2011-12-22 19:56 <sisalp> b | ||
| 2011-12-22 19:56 <jcm> alors pour faire cela, ne pourrait-on avoir un % (ou mieux une liste genre liste de prix) pour calculer le poids emballage à réserver lors du devis/facture brouillon ? | ||
| 2011-12-22 19:57 <jcm> le poids réel tenant compte des emballages ajoutés au shipment serait calculé uniquement lors de la facture finale | ||
| 2011-12-22 19:57 <sisalp> c'est pour cela que le formulaire de calcul du prix d'expédition doit avoir un champ "tare" à mon avis | ||
| 2011-12-22 19:57 <jcm> cedk: est-ce un fonctionnement possible ? | ||
| 2011-12-22 19:58 <jcm> sisalp: "tare" pour toi est le supplément de poids à include au total ? | ||
| 2011-12-22 19:58 <sisalp> tare=poids_brut-poids_net | ||
| 2011-12-22 19:58 <jcm> sisalp: c'est donc similaire au champ Poids d'emballage dont je parlais plus haut... | ||
| 2011-12-22 19:59 <sisalp> absolument ;-), mais à l'école j'avais appris "tare", je sais pas pourquoi | ||
| 2011-12-22 20:00 <sisalp> ha oui, je me trompe, je crois que la tare et le poids qu'on pose sur la balance pour équilibréer l'emballage | ||
| 2011-12-22 20:00 <sisalp> est | ||
| 2011-12-22 20:00 <jcm> cedk: il reste un dernier problème sur la grille de prix attachée à carrier : il ne devrait pas etre possible d'utiliser le tarif lorsque le poids excède la plus haute entrée | ||
| 2011-12-22 20:01 <sisalp> sur les containers qu'on met sur les bateaux, on lit poids total, charge nette et tare | ||
| 2011-12-22 20:02 <jcm> sisalp: ok sur le vocabulaire, ce n'est que question de définition commune... | ||
| 2011-12-22 20:03 <sisalp> tare (nom féminin) | ||
| 2011-12-22 20:03 <sisalp> Poids de l'emballage vide que l'on doit défalquer du poids brut d'une marchandise pour obtenir le poids net. | ||
| 2011-12-22 20:03 <sisalp> Poids que l'on met dans l'un des plateaux d'une balance pour équilibrer la charge de l'autre plateau. | ||
| 2011-12-22 20:03 <sisalp> {sens figuré} Défaut. | ||
| 2011-12-22 20:04 <jcm> cedk, sisalp : désolé, je dois m'arrêter, je peux être de retour à 21 h 30 ou demain à partir de 14 h. | ||
| 2011-12-22 20:04 <jcm> Il restait à reparler de invoice : la mention obligatoire à faire figurer, le problème de la non traductibilité des factures | ||
| 2011-12-22 20:04 <jcm> et pour account_fr, les règles de taxes pour l'intracommunautaire | ||
| 2011-12-22 20:05 <sisalp> tu avais vu la discussion sur les factures par pays ? | ||
| 2011-12-22 20:05 <jcm> hier sur tryton ? oui | ||
| 2011-12-22 20:05 <sisalp> demain soir, je serai de nouveau sur la route | ||
| 2011-12-22 20:05 <jcm> le point est que légalement, une facture doit etre dans la langue de la company; les traductions ne peuvent petre que des copies non légales | ||
| 2011-12-22 20:06 <sisalp> je pense faire ma propre facture bilingue français/anglais sur un seul document | ||
| 2011-12-22 20:07 <jcm> cedk, sisalp : sans rancune, je vous ennuie de nouveau demain avec tout ce qui reste en suspens :-] | ||
| 2011-12-22 20:07 <jcm> à bientôt | ||
| 2011-12-22 20:07 <sisalp> à demain | ||
| 2011-12-22 20:09 <cedk> je comprend pas pourquoi générer la facture à l'avance est mieux | ||
| 2011-12-22 20:10 <cedk> pour moi, on fait le colis, on le passe en done et puis on imprime la facture et on la met dans le paquet | ||
| 2011-12-22 20:10 <cedk> je pense que tout le reste est de la complication pour rien | ||
| 2011-12-22 20:11 <cedk> parce qu'au final, la facture ne peut être validée qu'une fois le paquet fait | ||
| 2011-12-22 20:12 <sisalp> cedk: je suis d'accord mais c'est pas naturel avec les menus et les droits actuels | ||
| 2011-12-22 20:12 <cedk> le truc de la facture uniquement en français me parrait très bizard | ||
| 2011-12-22 20:12 <cedk> dans la compta de B2CK, il y a des factures dans plein de langue différentes | ||
| 2011-12-22 20:12 <sisalp> donc il faudrait que la facture soit vérifiée pour que le "coliseur" n'ai pas basoin d'être comptable | ||
| 2011-12-22 20:12 <sisalp> besoin | ||
| 2011-12-22 20:13 <cedk> sisalp: je n'en sais rien | ||
| 2011-12-22 20:13 <cedk> sisalp: mais dans une infrastructure ou il y a différent rôle, ce n'est surement pas la rôle du coliseur de mettre la facture dans le paquet | ||
| 2011-12-22 20:13 <cedk> sisalp: ici on est dans un cas de simplification des rôles | ||
| 2011-12-22 20:14 <cedk> d'ailleur, je n'ai toujours pas compris pq il faut absolument la facture dans le colis | ||
| 2011-12-22 20:15 <sisalp> la facture dans le paquet est monnaie courante. ce qui est particulier qu'est que ce n'est pas un forfait dans le cas de symétrie pour bénéficier d'un taux spécial de tva | ||
| 2011-12-22 20:16 <cedk> sisalp: il ne faut pas confondre facture et bon de livraison | ||
| 2011-12-22 20:16 <sisalp> je parle bien de facture | ||
| 2011-12-22 20:16 <cedk> sisalp: ce qu'il arrive souvent c'est que le bon de livraison fait office de facture | ||
| 2011-12-22 20:16 <sisalp> c'est pas possible | ||
| 2011-12-22 20:16 <cedk> sisalp: mais on fait quand même un facture par après avec les même info | ||
| 2011-12-22 20:17 <sisalp> il n'y a pas les pris pour les livraisons habituellement | ||
| 2011-12-22 20:17 <sisalp> x | ||
| 2011-12-22 20:17 <cedk> sisalp: ça dépend | ||
| 2011-12-22 20:18 <sisalp> ce que j'ai vu chez ldlc : si adresse facture=adresse livraison, facture dans le colis, sinon courrier séparé | ||
| 2011-12-22 20:19 <cedk> sisalp: je suppose que c'est le gars qui fait le colis qui l'imprime et la met | ||
| 2011-12-22 20:19 <cedk> sisalp: mais de tout manière ldlc il facture un forfait de livraison donc ils peuvent la générer à l'avance | ||
| 2011-12-22 20:19 <sisalp> l'imprimer n'est pas un souci si elle a déjà été validée | ||
| 2011-12-22 20:20 <cedk> sisalp: oui mais dans le cas de symétrie, la facture ne peut être validée que quand le colis est fait | ||
| 2011-12-22 20:20 <cedk> c'est le problème de l'oeuf et de la poule | ||
| 2011-12-22 20:20 <sisalp> et ldlc comme les autres ont toujours: "frais de traitement et d'expédition" fixé à la commande | ||
| 2011-12-22 20:21 <cedk> sisalp: et je pense pas que quelqu'un valide tout les factures chez ldlc, elles sont validée automatiquement | ||
| 2011-12-22 20:21 <sisalp> quant à amazone et d'autres qui vendent des livres comme symétrie, ils se débrouillent avec "frais de port offerts" | ||
| 2011-12-22 20:22 <sisalp> ldlc : elles sont même validées après paiement, et avant confirmation de la commande | ||
| 2011-12-22 20:23 <sisalp> ou en même temps | ||
| 2011-12-22 20:26 <sisalp> au fait qu'est ce que tu penses du bouton "actualiser le devis" qui mettrait à jour prix, poids, taxes etc.. ? | ||
| 2011-12-22 20:27 <cedk> sisalp: je vois pas l'interet | ||
| 2011-12-22 20:27 <cedk> sisalp: ni exactement ce que ça fait | ||
| 2011-12-22 20:27 <sisalp> comment fait on actuellement ? | ||
| 2011-12-22 20:27 <cedk> sisalp: faire quoi? | ||
| 2011-12-22 20:28 <sisalp> actualiser | ||
| 2011-12-22 20:29 <sisalp> le pb est le suivant : je crée un devis, et je constate que le bilan poids ou les prix sont abhérents | ||
| 2011-12-22 20:30 <sisalp> alors je corrige les produits, j'importe la mise à jour des prix du catalogue, etc... et je fais recalculer le devis | ||
| 2011-12-22 20:31 <cedk> sisalp: il suffit de supprimer la ligne de livraison pour qu'elle soit recalculée | ||
| 2011-12-22 20:32 <sisalp> je parlais pas de cette ligne, mais de toutes les lignes | ||
| 2011-12-22 20:33 <cedk> sisalp: mais tu veux recalculer quoi? | ||
| 2011-12-22 20:34 <sisalp> retomber sur le même résultat que si on faisait le devis à cet instant | ||
| 2011-12-22 20:35 <sisalp> nouveaux prix, nouveaux poids, nouveaux stocks etc... | ||
| 2011-12-22 20:37 <sisalp> ce qui arrive : je vous fais un devis valable 30j, deux mois plus tard, vous décidez d'acheter et vous demandez un devis actualisé | ||
| 2011-12-22 20:37 <sisalp> actuellement, je dois reprendre le devis ligne par ligne, il me semble | ||
| 2011-12-22 20:38 <cedk> sisalp: moauis c'est une idée de module | ||
| 2011-12-22 20:38 <cedk> sisalp: mais a priori, si le devis a une date d'expiration, il est mieux d'en faire un nouveau | ||
| 2011-12-22 20:41 <cedk> sisalp: en plus ça peut être très compliqué à faire car les on_change peuvent dépendre de l'ordre d'encodage | ||
| 2011-12-22 20:42 <sisalp> dupliquer puis actualiser ? c'est ce que je pense en effet, mais je crois qu'on ne gère pas les versions de devis | ||
| 2011-12-22 20:42 <sisalp> c'est juste une idée, pas un besoin | ||
| 2011-12-22 20:42 <cedk> ACTION bbl | ||
| 2011-12-22 21:42 <jcm> ACTION de retour |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!