IRC logs of #tryton-fr for Thursday, 2011-12-22

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/!