Verkaufsprovisions-Rechner

Die Identität ist total_commission gleich sale_amount mal commission_rate durch einhundert, plus bonus. Ein Verkaufsbetrag von null ist zulässig und ergibt nur die Prämie; ein negativer Verkaufsbetrag beschreibt keine Einnahme, daher scheitert er mit invalid_input statt eine Rückforderung zu drucken, die eine Gehaltsliste als schon gezahltes Geld behandeln könnte. Nutzen Sie ihn im Browser ohne Gebühr, oder rufen Sie die API zu $0.002 je erfolgreicher Anfrage auf.

Was die Identität der Verkaufsprovision abdeckt und was sie auslässt

Die Identität, die dieses Werkzeug nutzt, ist die, die jene Dokumente bereits andeuten: total_commission gleicht sale_amount mal commission_rate geteilt durch einhundert, plus bonus. Ein negativer Verkaufsbetrag beschreibt keinen geschlossenen Umsatz, daher scheitert er mit invalid_input statt eine Gutschrift zu drucken, die ein Formular als Bargeld behandeln könnte.

Eingabevertrag, Form der Antwort und Fehlerverhalten

Senden Sie per POST einen JSON-Körper, der sale_amount und commission_rate liefert, mit bonus optional. sale_amount ist der geschlossene oder erwartete Verkauf in einer einzigen Währungseinheit, eine endliche Zahl, die nicht negativ ist, mit Alias amount, sale, sales, price und revenue. Ein Verkaufsbetrag von null ist zulässig und ergibt nur die Prämie. commission_rate ist der Prozentanteil dieses Verkaufs, fünf für fünf Prozent, eine endliche Zahl, die nicht negativ sein darf, mit Alias rate, percent, percentage, commission_percent und commission_pct. bonus ist ein optionaler pauschaler Extra in derselben Währung, eine endliche Zahl, die nicht negativ sein darf, standardmäßig null wenn ausgelassen oder leer, mit Alias flat_bonus, extra und spiff. Jedes Zahlenfeld darf als JSON-Zahl oder als numerische Zeichenkette ankommen, die einem strengen Dezimalmuster folgt. Fehlendes sale_amount, fehlendes commission_rate, leere Zeichenketten, nicht endliche Werte, eine Größe über der erklärten Grenze, ein negativer Provisionssatz oder eine negative Prämie scheitern mit invalid_input unter Nennung des Feldes und werden nicht berechnet. Der kennzeichnende Fehler, den diese Landing fangen soll, ist ein negatives sale_amount: die Meldung nennt sale_amount, damit ein Formular genau dieses Steuerelement hervorhebt statt einer globalen Warnung, und stellt fest, dass ein negativer Verkauf keine Verkaufsprovision erzeugen kann. Bei Erfolg spiegelt der Körper sale_amount nach Rundung auf Cent, commission_rate, bonus, rate_decimal als den Prozentanteil geteilt durch einhundert, base_commission als die prozentuale Scheibe allein, total_commission als die zahlbare Summe und eine formula-Zeichenkette, die die Identität neu formuliert. Beispiel: sale_amount von zehntausend, commission_rate von fünf und bonus von zweihundertfünfzig ergibt base_commission fünfhundert und total_commission siebenhundertfünfzig. Verknüpfen Sie die Summe mit Ihren eigenen Steuer- und Vorschusstabellen; dieser endpoint berechnet nur die Provisionszeile.

Wo ein Verkaufsprovisions-Rechner seinen Platz verdient

Gehalts- und Finanzanwendungen, die variable Bezahlung schätzen, können total_commission als Abfluss speichern und dann Einbehalte, Vorschüsse und Rückforderungen darüberlegen, statt eine gemischte Abrechnung rückwärts zu bauen. Weil die Umsetzung reines parse der Stufe A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Grundpreis $0.002 ohne Modell-Token und ohne ausgehendes Netz. Halten Sie den Verkaufsbetrag nicht negativ, halten Sie Satz und Prämie nicht negativ, pinnen Sie die gerundeten Geldfelder in Tests, und Sie erhalten eine reproduzierbare Verkaufsprovision für Widgets, Kursmodule und Worker am Rand, ohne eine eigene Vergütungsengine aufzustellen.