Calculateur sacs mortier

La même fonction pure alimente l’outil gratuit du navigateur et l’API payante, de sorte qu’un devis téléphonique correspond à la ligne qu’un script publie ensuite. Un nombre de briques négatif ou une couverture non positive est rejeté avec un message clair invalid_input au lieu d’un total de sacs absurde.

Comment le nombre de sacs est calculé à partir des briques et de la couverture

Écrivez effective_bricks égal à brick_count multiplié par un plus waste_percent divisé par cent. Ensuite bags_exact égale effective_bricks divisé par coverage_per_bag, et bags est le plafond de ce quotient car les magasins vendent des sacs entiers, non des fractions. spare_bricks indique combien de places de briques supplémentaires le nombre de sacs arrondi peut couvrir au-delà du compte effectif, utile si vous voulez une petite marge sans inventer un second champ de perte. Le pipeline est une arithmétique flottante déterministe, sans graines aléatoires, sans horodatage d’horloge et sans appels réseau, de sorte que des entrées identiques produisent toujours le même JSON. Le nombre de briques ne doit pas être négatif: un compte négatif est rejeté avec invalid_input car une quantité négative n’est pas physique. Zéro brique est autorisé et donne zéro sac. coverage_per_bag doit être strictement positif pour que le rapport soit défini, et waste_percent le cas échéant doit se situer entre zéro et cent inclus.

Ce que vous envoyez et ce que vous recevez

Envoyez deux nombres finis obligatoires: brick_count pour le total de briques du mur ou du lot, et coverage_per_bag pour le nombre de briques qu’un sac de mélange couvre selon la pratique retenue. Envoyez éventuellement waste_percent comme pourcentage de marge sur le compte; si vous l’omettez la valeur par défaut zéro s’applique et waste_defaulted vaut true afin que les clients API voient qu’aucune marge n’a été supposée. Les champs obligatoires manquants, les chaînes non numériques, NaN et Infinity échouent avec invalid_input et ne sont pas facturés. Lorsque brick_count est négatif la requête échoue avec un message indiquant que le compte ne peut pas être négatif, pour que les clients corrigent le métré avant de réessayer plutôt que de recevoir un total de sacs négatif. Lorsque coverage_per_bag est nul ou négatif la requête échoue car la division par une couverture non positive n’est pas définie pour une estimation d’achat. En cas de succès la réponse renvoie les entrées nettoyées, effective_bricks après perte, bags_exact, bags entiers, spare_bricks, un unit_note rappelant que la couverture est en briques par sac et non en mètres cubes, et une courte chaîne formula pour la documentation. Contrôles classiques: cinq cents briques à quarante briques par sac sans perte: bags_exact vaut douze virgule cinq et bags monte à treize. Autre contrôle utile: mille briques à trente-cinq par sac avec dix pour cent de perte: les briques effectives deviennent mille cent, bags_exact est environ trente et un virgule quatre trois, et bags monte au sac entier suivant. Le tarif des appels API réussis est la base publiée de $0.002 par élément; les échecs de validation ne consomment pas le solde prépayé.

Où les estimations de sacs de mortier pour briques interviennent dans le travail réel

Les propriétaires qui construisent un mur de jardin, une jardinière ou un parement de briques ont besoin d’un nombre de sacs fiable avant d’aller en magasin, surtout lorsque les grands sacs sont lourds et difficiles à retourner une fois ouverts. Les fournisseurs impriment souvent la couverture en briques sur le flanc du sac; convertir le métré via ce taux rend la liste d’achats transparente plutôt qu’une règle empirique opaque. Si vous avez ensuite besoin du volume de mortier à partir de l’épaisseur de joint et du rendement cubique du sac, de la surface du mur à partir de la longueur et de la hauteur, ou du nombre de briques à partir des dimensions et des pertes, traitez-les comme des intentions de recherche et des landings distinctes plutôt que de surcharger cette page de calculateur par nombre de briques et couverture par sac. Les équipes de maçonnerie et d’aménagement paysager établissent des calendriers d’achat à partir des métrés de briques et du taux de couverture que l’équipe utilise pour le joint sur chantier; un seul endpoint déterministe qui plafonne les sacs réduit l’écart entre les tableurs de l’estimateur et de l’acheteur. Les gestionnaires immobiliers qui planifient plusieurs lots de cloisons ou d’aménagement envoient chaque paire brick_count et coverage_per_bag via l’API et joignent les sacs aux bons de commande pour que le surstock reste volontaire. Comme cette capacité est un moteur parse pur, le prix API est la base publiée de $0.002 par élément réussi et une validation échouée ne consomme pas le solde.