Calculateur de délai moyen d'encaissement

Des ventes à crédit nulles ou négatives rendent le rapport indéfini, si bien que la tâche échoue avec invalid_input et n'est pas facturée.

Comment se calculent les jours de ventes en cours et le délai moyen d'encaissement

De façon équivalente, formez d'abord les ventes à crédit quotidiennes moyennes comme credit_sales divisé par days, puis divisez accounts_receivable par ce rythme quotidien ; les deux chemins sont algébriquement identiques et cette capacité utilise le premier. Une année bancaire de 360 jours ou un trimestre de 90 n'est qu'une autre valeur de days : la formule ne change pas. La rotation des créances, indiquée lorsque accounts_receivable est positif, est ventes à crédit divisées par créances, et le DSO est alors days divisé par cette rotation.

Contrat d'entrée, forme de la réponse et erreurs

Si days est fourni et n'est pas supérieur à zéro, la requête échoue. Ces échecs ne sont pas facturés. Exemple : quarante-cinq mille de créances face à trois cent soixante-cinq mille de ventes à crédit annuelles donnent un délai d'encaissement de quarante-cinq jours et mille de ventes à crédit quotidiennes moyennes. Adressez par POST un corps JSON avec deux nombres finis obligatoires et une durée de période facultative. accounts_receivable est le solde de créances ouvertes de la fenêtre (AR de clôture, ou AR moyen si c'est la convention que vous utilisez déjà en interne) ; les alias ar et receivables désignent le même champ. credit_sales désigne les ventes à crédit totales — nettes des retours si c'est ainsi que vous clôturez le livre — pour la même fenêtre ; les alias sales, total_credit_sales et net_credit_sales sont acceptés afin que les colonnes du grand livre gardent leur nom. days est le nombre de jours de cette fenêtre et vaut 365 lorsqu'il est omis ; les alias period_days et days_in_period sont acceptés. Chaque champ numérique peut arriver comme nombre JSON ou 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 credit_sales est nul ou négatif, le gestionnaire refuse la requête avec un message indiquant que les ventes à crédit ne peuvent être ni nulles ni négatives, car le DSO est alors indéfini. Si accounts_receivable est négatif, la requête échoue. En cas de succès, le corps répète accounts_receivable, credit_sales et days, puis indique average_daily_credit_sales, days_sales_outstanding et average_collection_period (les deux derniers sont le même chiffre arrondi, renvoyé sous les deux noms pour qu'un tableau de bord DSO et une feuille ACP partagent un contrat). Lorsque les créances sont positives, le corps inclut aussi receivables_turnover. Associez le JSON à vos propres tranches d'ancienneté si vous avez besoin du récit client par client ; ce point d'accès renvoie la moyenne de la période, pas un échéancier de factures.

Où un calculateur de délai moyen d'encaissement justifie sa place

Comme l'implémentation est parse pure de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant. Gardez credit_sales strictement positif, accounts_receivable non négatif, figez dans les tests le chiffre de jours arrondi, et vous obtenez des délais d'encaissement reproductibles pour les listes de clôture, les greffons LMS et les workers en périphérie sans monter un moteur de créances à vous.