Calculateur de double remise

Une remise qui dépasse cent pour cent est rejetée comme invalid_input et n'est pas facturée.

Comment deux remises successives se composent réellement

L'identité qu'utilise ce calculateur est final_price égal à price fois un moins first_discount divisé par cent, fois un moins second_discount divisé par cent. La première ristourne produit un price_after_first intermédiaire, ensuite réduit par le second taux. L'économie totale est le prix d'origine moins ce final_price, ce qui équivaut à price fois le pourcentage combiné équivalent une fois que l'arrondi monétaire est appliqué à chaque étape pour que les parties continuent de reconstituer la liste. price est le montant d'origine dans une seule devise ; first_discount et second_discount sont les deux taux annoncés, saisis comme les bannières les impriment, de sorte que vingt signifie vingt pour cent, non vingt centièmes. Le seul pourcentage qui correspondrait au résultat empilé est aussi renvoyé comme equivalent_percent afin qu'une feuille de calcul conserve un nombre à côté des deux pourcentages que l'on tape. Une remise qui dépasse cent pour cent n'est pas une ristourne dans ce contrat et est rejetée comme invalid_input, car une bannière qui imprime cent vingt pour cent de remise est presque toujours une erreur de données, non un remboursement que vous entendiez modéliser.

Contrat d'entrée, forme de la réponse et comportement en cas d'erreur

Si price est négatif, le gestionnaire rejette la demande car un prix d'origine ne peut pas être négatif ; un échantillon gratuit de zéro est admis et produit un prix final nul et une économie nulle. Si l'une des remises est négative, le gestionnaire rejette avec un message clair indiquant qu'une remise successive négative n'est pas autorisée. Zéro pour cent à une étape est valide et laisse le montant de cette étape inchangé. Cent pour cent à une étape est valide et met le prix restant à zéro. Envoyez par POST un corps JSON avec trois nombres finis obligatoires. price est le montant d'origine dans une unité monétaire avant l'une ou l'autre des remises successives ; les alias original_price, list_price, original et amount pointent vers le même champ afin qu'un export de catalogue conserve les noms de colonnes. first_discount est le premier taux successif de remise appliqué au prix d'origine, non une fraction : vingt signifie vingt pour cent ; les alias first_percent, discount1, first et percent1 sont acceptés. second_discount est le second taux successif appliqué à ce qui reste après la première ristourne ; les alias second_percent, discount2, second et percent2 sont acceptés. Chaque champ numérique peut arriver comme nombre JSON ou comme chaîne numérique. Les champs manquants, les chaînes vides et les valeurs non finies échouent avec invalid_input en nommant le champ. Si l'une des remises dépasse cent, le gestionnaire rejette avec invalid_input en indiquant qu'une remise successive qui dépasse 100 pour cent n'est pas autorisée : ces échecs ne sont pas facturés. En cas de succès, le corps répète price arrondi à deux décimales, first_discount et second_discount, puis rapporte price_after_first comme le montant après la seule première ristourne, final_price comme le chiffre de paiement après les deux coupes arrondi à deux décimales, savings comme price moins final_price, equivalent_percent comme le seul pourcentage qui correspondrait au résultat empilé, et une chaîne formula qui réaffirme l'identité. Exemple : cent à vingt puis dix produit un price_after_first de quatre-vingts, un final_price de soixante-douze, un savings de vingt-huit et un equivalent_percent de vingt-huit. Associez le JSON à votre propre règle sur quels SKU partagent ces deux taux — magasin entier plus coupon, destockage plus extra d'employé, ou coupe du vendeur plus code du site — car ce point multiplie les trois nombres que vous envoyez ; il ne consulte pas un commerçant, n'applique pas un troisième coupon et ne convertit pas les devises. Gardez les requêtes petites, figez le final_price arrondi dans les tests, et vous obtenez un chiffre empilé reproductible pour feuilles, plugins LMS et workers de bord sans dresser un moteur de promotions à vous.

Où un calculateur de double remise gagne sa place

Les rédacteurs de sites d'offres déposent une liste publiée et les deux pourcentages annoncés, puis figent final_price et savings afin qu'une publication ne cite pas un trente pour cent inventé qui plus tard divergera du paiement. Comme l'implémentation est parse de rang A pur, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle et sans réseau sortant. Gardez les deux remises entre zéro et cent inclus, figez le final_price arrondi dans les tests, et vous obtenez un chiffre empilé reproductible pour teasers, paniers et workers de bord sans dresser un moteur de promotions à vous.