FR 2979449 A1 20130301 FR 1157683 A 20110831 De manière générale, la présente invention se rapporte au financement du commerce électronique. L'une ou plusieurs de ces applications préférées se rapportent à l'amélioration des systèmes et des méthodes de gestion financière de la chaîne d'approvisionnement permettant à toutes les parties d'une « chaîne d'approvisionnement » (acheteurs, fournisseur et institutions financières) de collaborer en vue de permettre à un fournisseur de vendre à l'institution financière une obligation, d'un acheteur à un vendeur et qui a une valeur liée aux comptes de l'acheteur et payable au fournisseur. Dans une application préférée, ceci permet de vendre l'obligation à l'institution financière avec un rabais par rapport à la valeur globale qui dépend de la date de maturité de l'obligation et de la vigueur financière de l'acheteur plutôt que de la vigueur financière ou du risque crédit du fournisseur. CONTEXTE DE LA PRÉSENTE INVENTION [2] Une chaîne d'approvisionnement décrit le réseau de vendeurs, fournisseurs, fabricants, sous-traitants, prestataires de service, opérations d'assemblage, centres de stockage et de distribution, utilisateurs finaux ou acheteurs et d'autres parties qui participent à la vente, à la production et la livraison d'un produit ou d'un service. De telles chaînes d'approvisionnement mettent l'accent sur la satisfaction des bons de commande de l'acheteur 1 par rapport à des biens ou services finis à des endroits bien choisis. De manière classique, chaque commande décrit les biens ou services souhaités, leur quantité, leur prix et la date de livraison souhaitée. Les institutions financières ou les prêteurs commerciaux s'impliquent souvent dans la chaîne d'approvisionnement pour fournir des fonds permettant de financer de telles transactions et de soutenir le flux de trésorerie des fournisseurs et des acheteurs. [3] Dans une transaction interentreprises classique, un acheteur place une commande de biens ou de services auprès d'un fournisseur. Ceci est généralement documenté dans un bon de commande. Après la réception du bon de commande par le fournisseur, ce dernier s'engage à respecter la commande en livrant les biens ou services requis. La livraison des biens ou services commandés peut requérir plusieurs étapes intermédiaires, telles que l'assemblage, le stockage, l'expédition directe et le transport local, tout ceci s'ajoute à la complexité de la chaîne de distribution et aux sommes à verser. [4] De manière générale, après la livraison d'un produit ou d'un service par le fournisseur, ce dernier créée une facture et la transmet à l'acheteur. La date portée sur la facture est généralement celle du jour de transmission, à partir des locaux du fournisseur, et cette date marque le début d'une période spécifique (c-à-d, la « période de grâce ») pendant laquelle aucun paiement n'est attendu ou requis de l'acheteur. Cette période de grâce crée, en effet, une ligne de crédit qui est établie par le fournisseur au nom de l'acheteur et qui est généralement offerte sans intérêt. Souvent, le fournisseur offre un rabais sur le montant à payer en cas règlement de la facture avant la fm de la période grâce. Après la fm de la période grâce, le paiement entier est dû. [5] Dans le commerce moderne, toutefois, les acheteurs rallongent souvent la période de grâce au-delà des conditions du fournisseur, telles que formulées dans la facture. Ceci est particulièrement le cas des détaillants à grande échelle qui peuvent retarder le paiement en vue de profiter de la valeur du capital dans le temps. Les fournisseurs qui sont généralement des entreprises plus petites que leurs acheteurs pourraient avoir besoin de financement intermédiaire pour satisfaire les besoins de flux de trésorerie. [6] Pour résoudre ces besoins, un fournisseur peut vendre ses créances ou utiliser celles-ci comme garantie pour un prêt permettant d'augmenter le capital de ses opérations ou pour d'autres buts. Le terme « affacturage » est utilisé pour décrire la vente ou la mise en garantie d'une créance. Le processus d'affacturage, toutefois, peut être long et ennuyeux. Par exemple, en principe, les fournisseurs doivent soumettre des données détaillées à l'affactureur et suivre à l'aide de documents tangibles et des preuves attestant de la validité de la facture avant l'obtention des fonds. Par ailleurs, l'affactureur dévalue généralement les créances du fournisseur à une certaine valeur, par exemple, à cause de la cote de solvabilité faible de certains débiteurs et/ou parce qu'il est prévu que les créances du fournisseur puissent être réduites par des retours et/ou d'autres types de frais de facturation interne découlant de la transaction sous-jacente. Pour ces raisons, l'affactureur ne prête généralement que jusqu'à 80% de la valeur réelle de la créance. En outre, les taux d'intérêt pratiqués dans l'affacturage sont généralement élevés (12% +), même pour les créances des acheteurs à « cote élevée de solvabilité ». Tous ces problèmes surviennent parce l'affacturage ne permet pas un accès en temps réel aux créances du fournisseur ou à la visibilité du processus des comptes à payer de l'acheteur. 3 [007] On connaît également les systèmes par lesquels un fournisseur peut vendre ses créances à une institution financière en fonction du niveau de solvabilité de l'acheteur. Dans de tels systèmes, une entité qui se trouve au centre des transactions de l'acheteur, du fournisseur et de l'institution financière dispose d'un système informatique et d'une ou de plusieurs interfaces au travers desquelles les trois parties interagissent à distance. L'acheteur transfère dans le système des données liées à ses créances, découlant des transactions commerciales entre lui et le fournisseur en dehors du système et/ou pour lesquelles le fournisseur a soumis une ou plusieurs factures à l'acheteur. En conformité avec les accords contractuels précédents entre l'acheteur et l'entité centralisatrice, le transfert des données de créance par l'acheteur vers l'entité centralisatrice établit une obligation contractuelle irrévocable pour celui-ci, à savoir qu'il paiera le montant total découlant l'obligation de transfert de données. Cette obligation irrévocable profite au fournisseur ou à ses délégataires, une telle personne n'étant par conséquent qu'un bénéficiaire tiers du contrat entre l'acheteur et l'entité centralisatrice. Le fournisseur qui peut accéder aux systèmes et visualiser les obligations transférées peut décider d'attendre et de recevoir le paiement complet des comptes à payer sous-jacents (créances au profit du fournisseur) ou pourrait décider de vendre ses créances correspondant à l'obligation transférée. Si le fournisseur décide de vendre ses créances, il en informe le système de l'entité centralisatrice à l'aide d'une notification via une interface. Cette notification peut être consultée par une institution financière lorsque cette dernière accède au système au travers d'une interface. L'offre de vente est un montant déduit du montant global de l'obligation de paiement. Le système de l'entité centralisatrice détermine automatiquement le montant déduit en fonction du délai entre la date de vente et la date de maturité de l'obligation de paiement et un taux de décompte précédemment entré par l'institution financière. La date de maturité de l'obligation de paiement est définie par les données d'obligation transférées. Ceci se déroule en dehors du système de l'entité centralisatrice. La date de maturité peut être la date d'échéance, ou en rapport avec celle-ci, des factures impliquées, mais elle peut être toute date que l'acheteur et le fournisseur se seraient fixé. L'institution financière fixe le taux d'actualisation de manière discrétionnaire et elle pourrait sélectionner plusieurs taux pour des créances issues d'acheteurs différents. En d'autres termes, l'escompte accepté par le fournisseur lors de la vente de ses créances dépend de la solvabilité de l'acheteur et non de la sienne. [8] Lorsqu'une institution financière décide d'accepter l'offre de vente, ensuite, en conformité avec des dispositions contractuelles précédentes entre l'institution financière et le fournisseur, celle-ci pourrait exécuter une acceptation commerciale via une notification au système de l'entité centralisatrice, transférant par la même à l'institution financière les droits de tiers du fournisseur prévus dans le cadre de l'obligation de paiement de l'acheteur. L'institution financière transfère ensuite le montant déduit au fournisseur et l'acheteur paie la totalité du montant à l'institution financière à la date de maturité. [9] Selon la Loi de Modernisation de l'Economie, en vigueur en France, lorsqu'un fournisseur en France délivre une facture à un acheteur en France, l'acheteur a l'obligation de régler le montant de la facture dans un délai de soixante jours, à compter de la date de réception. RÉSUMÉ DE L'INVENTION5 [0010] L'un ou plusieurs des aspects de la présente invention reconnaît et tient compte des considérations ci-dessus, et d'autres ou avant la construction et les méthodes de la conception. [0011] Dans un des aspects de la présente invention, un système électronique de financement de la chaîne d'approvisionnement utilisé par un acheteur, un fournisseur qui livre des biens et/ou des services à l'acheteur et une institution financière, chacun d'entre eux accède au système à l'aide d'une interface du réseau informatique, comprend un système informatique central, le système informatique de l'acheteur distant du système central, le système informatique d'une institution financière, distant du système informatique central et le système informatique du fournisseur, également distant du système informatique central. Le système informatique de l'acheteur dispose des données de créance issues des transactions entre l'acheteur et le fournisseur au cours desquelles le fournisseur fournit des biens et/ou des services à l'acheteur. Le système informatique de l'acheteur transfère les données de créance au système informatique central qui définit une obligation de paiement pour l'acheteur au profit du fournisseur correspondant à une transaction qui est liée à une date d'échéance à laquelle le paiement du montant correspondant à l'obligation de paiement est dû au fournisseur. Le système informatique central présente l'obligation de paiement vis-à-vis du fournisseur via le système informatique de ce dernier. Ensuite, il exécute des instructions visant le paiement du montant par l'institution financière au profit du fournisseur. Le système informatique central définit une durée de validité de l'offre pendant laquelle proposer l'offre de vendre l'obligation de paiement à une institution financière. La durée de validité de l'offre dépend étroitement de la date d'échéance au cours de laquelle l'institution financière dispose du temps d'accepter l'offre de vente de l'obligation de paiement, en fonction d'un temps d'acceptation commerciale prédéterminée en vue de permettre au système informatique central d'exécuter des instructions permettant de procéder au paiement du montant à la date d'échéance ou avant celle-ci. Le système informatique central présente automatiquement à l'institution financière, via son système informatique, pendant la durée de validité de l'offre ou avant celle-ci, l'offre de vente de l'obligation de paiement en lieu et place du fournisseur sur la base de modalités prédéterminées. Si le système informatique central reçoit de l'institution fmancière ou au nom de celle-ci une acceptation de l'offre de vente de l'obligation de paiement, il exécute les instructions ainsi reçues. [0012] Dans une autre forme particulière de réalisation de la présente invention, un système électronique de financement de la chaîne d'approvisionnement utilisé par un acheteur, un fournisseur qui livre des biens et/ou des services à l'acheteur et une institution financière, chacun d'entre eux accède au système à l'aide d'une interface du réseau informatique, comprend un support de données informatiques contenant des instructions informatiques et un processeur communiquant de manière opérationnelle avec le support de données informatiques et adapté à l'exécution d'instructions informatiques visant la mise en exécution d'une méthode. La méthode comprend l'étape de réception des données de créances envoyées par l'acheteur, qui définissent une obligation de paiement de l'acheteur au profit du fournisseur, correspondant à une ou à plusieurs transactions entre l'acheteur et le fournisseur qui sont liées à une date d'échéance à laquelle le paiement du montant correspondant à l'obligation de paiement est dû au fournisseur. L'obligation de paiement est présentée au fournisseur. Les instructions sont implémentées pour que soit exécuté le paiement du montant par l'institution financière au profit 7 du fournisseur. Une durée de validité de l'offre se définit comme la période pendant laquelle proposer l'offre de vendre l'obligation de paiement à une institution financière. La durée de validité de l'offre dépend étroitement de la date d'échéance au cours de laquelle l'institution financière dispose du temps d'accepter l'offre de vente de l'obligation de paiement, en fonction d'un temps d'acceptation commerciale prédéterminé en vue de permettre la modification des instructions permettant de procéder au paiement du montant à la date d'échéance ou avant celle-ci. L'offre de vente de l'obligation de paiement est automatiquement présentée à une institution financière par le fournisseur ou au nom de ce dernier. Si l'acceptation de l'offre par l'institution financière est reçue, les instructions sont exécutées. [0013] Dans une autre forme particulière de réalisation, une méthode de fourniture des financements à un fournisseur qui offre des biens et/ou des services à un acheteur comprend l'envoi par l'acheteur via un réseau informatique, vers un système informatique distant de l'acheteur, du fournisseur et d'une institution financière, des données de créance qui définissent une obligation de paiement de l'acheteur au profit du fournisseur, correspondant à une ou à plusieurs transactions entre l'acheteur et le fournisseur qui sont liées à une date d'échéance à laquelle le paiement du montant correspondant à l'obligation de paiement est dû au fournisseur. L'obligation de paiement est présentée au fournisseur via un système informatique. Les instructions sont exécutées, via le réseau informatique en vue d'effectuer le paiement du montant par l'institution financière au profit du fournisseur. La durée de validité de l'offre se définit comme le moment de faire une proposition de vente d'une obligation de paiement à une institution financière, où la durée de validité de l'offre dépend étroitement de la date d'échéance au cours de laquelle l'institution financière dispose du temps d'accepter l'offre de vente de l'obligation de paiement, en fonction d'un temps d'acceptation commerciale prédéterminé en vue de permettre au système informatique central d'exécuter des instructions permettant de procéder au paiement du montant à la date d'échéance. L'offre est présentée, via un réseau informatique, à une institution financière. Si une acceptation de l'offre de vente est reçue d'une institution financière ou de ses représentants, les instructions sont exécutées. [0014] Les dessins illustratifs, qui sont intégrés et partie prenante de ces explications illustrent une ou plusieurs formes particulières de réalisation de la présente invention. BRÈVE DESCRIPTION DES DESSINS [0015] Plusieurs aspects de l'invention peuvent être mieux compris à l'aide des dessins ci-dessous. Les composants apparaissant dans les dessins ne reflètent pas nécessairement leur échelle réelle. Une divulgation habilitante de la présente invention, y compris son meilleur mode, est énoncée dans la présente spécification qui renvoie aux dessins en annexe, dans lesquels : [0016] La figure lA est une vue schématique d'une méthode applicable à un système de financement d'une chaîne d'approvisionnement (SCF) correspondant à une forme particulière de réalisation de la présente invention ; [0017] La figure 1B est une représentation schématique des accords entre les parties du système SCF illustré à la figure. lA ; [0018] La figure 1C, 1D et 1E illustrent différentes fonctions du système SCF de la figure lA en fonction des différentes formes particulières de réalisation de la présente invention ; 9 [0019] La figure 2 illustre de manière schématique le transfert des données d'un animateur de communauté et d'un prestataire de services vers le programme d'un acheteur, ainsi que le processus de gestion du système de fmancement de la chaîne d'approvisionnement de la figure lA ; [0020] La figure illustre de manière schématique le transfert des données d'un animateur de communauté et d'un prestataire de services vers le programme d'un acheteur, ainsi que le processus de gestion du système de financement de la chaîne d'approvisionnement de la figure lA ; [0021] La figure 4 est un schéma des diverses fonctionnalités de la page Internet du programme d'animateur de communauté de l'acheteur de la figure 3 ; [0022] La figure 5 est un diagramme illustrant les fonctionnalités de l'interface Web du prestataire de services, accessible au programme de l'acheteur de la figure 3 ; [0023] La figure 6 est un diagramme illustrant les fonctionnalités de l'interface Web du prestataire de services, accessible au programme de l'acheteur de la figure 3 ; [0024] La figure 7 est un diagramme illustrant les fonctionnalités de l'interface Web du prestataire de services, accessible au programme de l'acheteur de la figure 3 ; [0025] La figure 8 illustre une impression d'écran d'une page de devis de financement au profit de l'entité du fournisseur de la figure 3 ; [0026] La figure 9 illustre une impression d'écran d'une page de devis de financement au profit de l'entité du fournisseur de la figure 3 ; [0027] La figure 10 illustre une impression d'écran d'une page de devis de financement au profit de l'entité du fournisseur de la figure 3 ; [0028] La figure 11 est une impression d'écran illustrant la fonctionnalité de note de crédit du système SCF illustré à la figure lA ; [0029] La figure 12 est une impression d'écran illustrant la fonctionnalité de note de crédit du système SCF illustré à la figure lA ; [0030] La figure 13 est une impression d'écran illustrant la fonctionnalité de note de crédit du système SCF illustré à la FIG. 11 ; [0031] La figure 14 est une impression d'écran illustrant la fonctionnalité de note de crédit du système SCF illustré à la figure lA ; [0032] La figure 15 est une impression d'écran illustrant la fonctionnalité de note de crédit du système SCF illustré à la figure lA ; [0033] La figure 16 est une impression d'écran illustrant la fonctionnalité de note de crédit du système SCF illustré à la figure lA ; [0034] La figure 17 est une impression d'écran illustrant la fonctionnalité de note de crédit du système SCF illustré à la figure lA ; [0035] La figure 18 est une impression d'écran illustrant la fonctionnalité de note de crédit du système SCF illustré à la figure lA ; [0036] La figure 19 est une impression d'écran illustrant la fonctionnalité de note de crédit du système SCF illustré à la figure lA ; [0037] Les figures 20 et 21 sont des impressions d'écran illustrant les fonctionnalités des critères de rapport du programme de l'acheteur de la figure 3 ; [0038] La figure 22 illustre une impression d'écran d'une page montrant une vue du programme de l'acheteur relative à la facturation de la figure 3 ; 11 [0039] La figure 23 illustre de manière schématique un système dans lequel une méthode tel qu'illustrée dans les figures 1A-1E est exécutée ; [0040] La figure 24 est une impression d'écran illustrant la vue partielle d'un programme de fournisseur en relation avec les obligations de paiement contenues dans le système dans la figure 1 A ; [0041] La figure 25 est une feuille de calcul illustrant le calcul de la réserve sur la base des informations illustrées à la figure 24 ; [0042] La figure 26 est une impression d'écran illustrant la vue partielle d'un programme de fournisseur en relation avec les obligations de paiement contenues dans le système dans la figure 1 A ; et [0043] La figure 27 est une feuille de calcul illustrant le calcul de la réserve sur la base des informations illustrées à la figure 26. [0044] L'utilisation répétée de caractères de référence dans la présente spécification et les dessins vise à représenter des fonctionnalités ou des éléments similaires ou analogues des formes particulières de réalisation de la présente invention. DESCRIPTION DETAILLÉE DES FORMES PARTICULIÈRES DE RÉALISATION PRÉFÉRÉES [0045] On mentionnera maintenant de manière détaillée les formes particulières de réalisation préférées de la présente invention, un ou plusieurs exemples de celle-ci seront illustrés dans les dessins illustratifs. Chaque exemple est fourni en vue d'expliquer l'invention et non comme une restriction de celle-ci. En fait, il est évident pour ceux qui ont l'expertise requise en la matière que les modifications et les variations peuvent être effectuées dans de tels exemples sans que leur cadre ni leur esprit ne soit dénaturé. Par exemple, les fonctionnalités illustrées ou décrites dans le cadre d'une forme particulière de réalisation peuvent être utilisées dans d'autres formes particulières de réalisation en vue de mettre à jour une autre forme particulière de réalisation. Par conséquent, l'intention est que la présente invention couvre de telles modifications et variations qui surviendraient dans le cadre des déclarations en annexe et leurs équivalents. [0046] La présente invention se rapporte, de manière générale, au financement du commerce électronique et, de manière spécifique, à l'amélioration de la gestion et des méthodes de financement de la chaîne d'approvisionnement. Système de financement de la chaine d'approvisionnement [0047] Le système de financement de la chaîne d'approvisionnement (SCF) de l'une ou plusieurs des formes particulières de réalisation actuellement présentées est un système financier sous forme de circuit fermé qui intègre, au sein de communautés définies, des acheteurs, des fournisseurs et des institutions financières apparentées. Nombre d'acheteurs, de fournisseurs et d'institutions financières interagissent avec le système et pourraient appartenir ou participer à l'une ou à plusieurs des communautés individuelles. Par exemple, une partie serait un acheteur dans une communauté de clients et un fournisseur dans une autre. Le système SCF vise à soutenir, dans le cadre des rapports existant dans une chaîne d'approvisionnement, les relations entre les acheteurs et leurs fournisseurs qui existent à l'extérieur du système SCF. [0048] Chaque partie d'une communauté dispose d'un accès, de préférence dans le cadre d'un environnement Web, à un lot commun et contrôlé d'informations financières et non 13 financières sur la chaîne d'approvisionnement. En particulier, le système SCF permet à un acheteur de transférer les données électroniques de son système de gestion des comptes à payer (A/P), contenant des informations approuvées, telles que le bénéficiaire, la date de paiement et le montant, etc. Les comptes à payer sont « approuvés » selon le fait que l'acheteur les a validés pour le paiement. Etant donné que, et conformément à l'accord établi entre l'acheteur et le système, le transfert d'une obligation de comptes à payer vers le système crée une obligation irrévocable pour l'acheteur pour qu'il paie une valeur d'obligation au fournisseur, le fonctionnement du système dans cette forme particulière de réalisation est basé sur l'hypothèse selon laquelle une obligation de comptes à payer transférée correspond à la valeur des comptes à payer que l'acheteur aurait préalablement approuvés pour le paiement. [0049] Dans les formes particulières de réalisation actuellement décrites, le fonctionnement du système SCF requiert au préalable que l'obligation de comptes à payer soit définie par les données qui peuplent le système comptes à payer de l'acheteur et, par conséquent, est censé correspondre aux factures que l'acheteur a reçues du fournisseur. Tel que mentionné dans la discussion ci-dessous, les contrats entre les parties pourraient supposer ou requérir une relation entre l'obligation de comptes à payer et les factures du fournisseur. Une telle association n'est pas obligatoirement requise pour que le système fonctionne ; toutefois, un acheteur pourrait simplement entrer des données de comptes à payer dans son système Comptes à payer pour les transférer au système SCF 10, ou entrer manuellement les données de comptes à payer dans le système 10 qui définit une obligation au profit du fournisseur mais sans créer de corrélation avec les factures du fournisseur. [0050] Les données spécifiques transférées du système de comptes à payer de l'acheteur qui définit l'obligation de comptes à payer pourrait varier à souhait et/ou en fonction de la structure et des informations disponibles dans le système Comptes à payer de l'acheteur ; cependant, dans une forme particulière de réalisation préférée, les données permettent suffisamment de définir une obligation de l'acheteur de payer le fournisseur un montant spécifique à une date donnée. Dans le présent document, « obligation » pourrait renvoyer à l'obligation irrévocable et contractuelle créée lorsqu'un acheteur transfère ses données de comptes à payer vers le système 10, mais, l'obligation de comptes à payer renvoie à une obligation contractée par l'acheteur vis-à-vis du fournisseur à l'extérieur du système 10. Pour chaque obligation de comptes à payer, les données Comptes à payer transférées vers le système 10 comprennent de préférence, au moins, le montant de l'obligation dont est redevable l'acheteur vis-à-vis du fournisseur, l'identité du fournisseur, la date d'échéance du montant dû au fournisseur (exemple, découlant d'une obligation contractuelle entre le fournisseur et l'acheteur ou une obligation statutaire prescrite dans le cadre de la juridiction de déroulement de la transaction), et une date à laquelle l'acheteur doit payer le montant à une entité possédant l'obligation. La première date est ci-désignée en tant que date de maturité pour l'acheteur. Dans les formes particulières de réalisation actuellement décrites, la date de maturité de l'acheteur suit toujours la date de maturité du fournisseur, et le système signale une erreur si cette condition n'est pas vraie pour toutes données transférées. Cette condition n'est pas nécessaire, toutefois, et dans une autre forme particulière de réalisation, la date de maturité de l'acheteur peut survenir avant la date de maturité du fournisseur. Lorsqu'une exigence statutaire oblige le paiement au profit du fournisseur dans un délai donné, sur la base de la date 15 sur la facture, les parties (c-à-d, l'acheteur et le fournisseur) peuvent décider que l'acheteur définira la date de maturité du fournisseur à la date de paiement prévue par les exigences statutaires ou avant celle-ci pour toute facture donnée. L'acheteur peut établir une obligation de comptes à payer sur la base d'une correspondance directe (un-égal-à-un) ou globale en établissant une obligation sur la base de plusieurs factures. Lorsqu'il existe une exigence statutaire relative à la date de paiement du fournisseur, l'acheteur, peut, par exemple, regrouper toutes les factures ayant la même date d'échéance en une seule obligation de comptes à payer, de telle sorte que la date de maturité du fournisseur corresponde à la période statutaire de toutes les factures. Dans une autre disposition, toutefois, l'acheteur peut établir la date de maturité du fournisseur relative à une obligation de comptes à payer correspondant à plusieurs factures ayant différentes dates d'échéance à la date d'échéance statutaire pour les factures du lot qui arrivent à échéance les premières. [0051] Tel que mentionné, l'obligation de comptes à payer ne doit pas nécessairement correspondre aux factures du fournisseur, mais, une obligation de comptes à payer sera cependant traditionnellement associée à des factures et le présent argumentaire se fonde sur ce principe. Dès lors, un système de base de données 452 (la figure 28) du système 10 comprend un enregistrement de chaque obligation de comptes à payer transférée qui contiendrait des informations relatives aux factures du fournisseur, données que pourrait fournir le système Comptes à payer de l'acheteur. Les données de facturation ou le contenu du membre sont accessoires dans ce sens qu'elles ne sont pas utilisées dans la transaction de financement exécutée via le système 10, mais sont mises à la disposition du fournisseur, tel que décrit ci-dessus, de telle sorte le fournisseur a la possibilité de rapprocher l'obligation de comptes à payer avec les données de facturation de son système de créances. Les données de facturation pourraient comprendre toutes les informations souhaitées par les parties, par exemple, le numéro de facture, la date de facture, le nom du fournisseur, le nom de l'acheteur, les données établissant le lien entre les factures et les obligations de comptes à payer, et éventuellement les codes indiquant les biens et/ou les services ayant fait l'objet de la facturation. Bien que le système présenté dans les formes particulières de réalisation actuellement décrites ne rapproche pas la date de maturité du fournisseur des dates de facturation issues du contenu du membre, dans un une autre forme particulière de réalisation, le système vérifie la date de maturité du fournisseur par rapport aux dates de facturation du contenu membre et confirme que la date maturité du fournisseur ne se situe pas au-delà de la date d'échéance statutaire des différentes factures faisant l'objet de l'obligation de comptes à payer associée à une date de maturité de fournisseur spécifique. [0052] De manière générale, le système Comptes à payer de l'acheteur peut être configuré pour qu'il crée, de manière automatique ou manuelle, les données de l'obligation de comptes à payer en regroupant les données relatives à une ou plusieurs factures du système Comptes à payer de l'acheteur, de telle sorte que le montant de l'obligation soit égal au total des différents montants des factures sélectionnées. La date de maturité de fournisseur peut être une date à laquelle le paiement des factures regroupées arrive à échéance conformément à une obligation contractuelle ou statutaire, et ainsi, dans une méthodologie préférée, les factures qui peuvent être regroupées dans une seule obligation de comptes à payer sont celles qui ont la même date de facturation, de telle sorte que la même date de maturité de fournisseur s'applique à toutes les factures de l'obligation. Des factures parallèles ne sont pas nécessaires, toutefois, 17 et l'acheteur et/ou son système Comptes à payer peut regrouper plusieurs factures ayant différentes dates de facturation, et par conséquent différentes dates d'échéance contractuelles ou statutaires, et choisir une date de maturité de fournisseur à appliquer à l'obligation de comptes à payer dans son ensemble, par exemple, sur la base de la première facture à arriver à échéance. La date de maturité de l'acheteur, à son tour, serait déterminée sur la base d'un accord entre l'acheteur et le fournisseur, et/ou entre l'acheteur et l'institution financière qui achètera l'obligation, conclue en dehors du système. [0053] Conformément à un accord entre l'acheteur et l'entité qui contrôle les paramètres régissant le fonctionnement du système SCF en relation avec les obligations de paiement (dans les formes particulières de réalisation actuellement décrites, l'animateur de communauté), au sein d'un groupe donné constitué d'un ou de plusieurs acheteurs, fournisseurs et institutions financières, lorsque l'acheteur transfère ses données d'obligation dans le système SCF, chaque obligation de comptes à payer se transforme en obligation de paiement irrévocable de l'acheteur au profit du fournisseur, tel que détaillé ci-dessous. Le montant de l'obligation irrévocable est égal au montant de l'obligation de comptes à payer, et les dates de maturité du fournisseur et de l'acheteur relevant de l'obligation irrévocable sont celles définies par les données d'obligation. [0054] Tel que décrit ci-dessous, la date maturité de fournisseur est une date à laquelle une obligation de paiement sera achetée par une institution financière et à laquelle le fournisseur sera payé, indépendamment du fait que le fournisseur ait initié ou non une transaction. Dans l'une des formes particulières de réalisation, et tel que décrit ci-dessous, la date maturité de fournisseur doit survenir un jour ouvrable valide. Les dates ouvrables valides sont définies dans la base de données du système et peuvent être convenues par les parties. Etant donné que la date de maturité de fournisseur peut être établie par un contrat et la législation, si une date de maturité de fournisseur survient un jour ouvrable non valide, le système de la présente forme particulière de réalisation repousse la date à la prochaine date ouvrable valide la plus avancée. Dans une autre forme particulière de réalisation, toutefois, une date de maturité de fournisseur survenant un jour ouvrable non valide est reportée à la prochaine date ouvrable valide. [0055] A tout moment, un fournisseur peut se connecter au système SCF et visualiser le montant, ainsi que les dates exactes de maturité de fournisseur et d'acheteur de chaque obligation de paiement irrévocable découlant d'une obligation générée par l'un de ses acheteurs. Le système SCF permet ensuite au fournisseur de vendre ses obligations de paiement avant leurs dates de maturité d'acheteur (et éventuellement avant les dates de maturité de fournisseur) à une valeur réduite. [0056] Les fournisseurs peuvent décider de recevoir des liquidités pour chaque (ou toutes les) obligation de paiement à tout moment jusqu'à une date limite configurable, juste avant la date de maturité d'acheteur ou la date de maturité de fournisseur de chaque obligation de paiement, quelque soit la première qui arrive à échéance. Conformément à un accord établi entre le fournisseur et l'entité de gestion du système SCF, les produits découlant de la vente des obligations de paiement correspondant aux créances du fournisseur équivalent à ces créances, résolvant ainsi la question de l'obligation externe créances/comptes à payer. Les fournisseurs ont ainsi la possibilité d'obtenir des liquidités et de fermer des créances 19 sélectionnées d'acheteurs spécifiques plutôt que de rechercher des emprunts sur la base de créances individuelles ou regroupées via une transaction d'affacturage. [0057] Dans le cadre du système SCF, le paiement peut être réduit à une période aussi courte que quarante-huit heures par rapport aux conditions actuelles, ce qui dans le cadre d'une obligation contractuelle ou statutaire discutée ci-dessus peut être considérée comme le temps entre la date de facturation et la date de maturité de fournisseur. Dans des formes particulières de réalisation, le système SCF est une connexion automatique et sécurisée qui pourrait être disponible via un réseau virtuel privé (VPN), une connexion Internet sécurisée ou un autre système approprié, éliminant ainsi les processus manuels et à forte intensité de main d'oeuvre. [0058] Le présent système SCF permet aux acheteurs de gérer les modalités de paiement tout en permettant parallèlement aux fournisseurs de fermer les créances correspondantes en retour pour des paiements avancés à des taux de financement bas qui sont préétablis par une institution financière. [0059] Le système SCF offre aux fournisseurs la visibilité des transactions et la certitude de paiement des créances approuvées par l'acheteur, réduisant ainsi les montants bloqués dans le cycle de commande-règlement de la facture. En recevant les paiements à la demande, les fournisseurs peuvent réduire les coûts et éliminer le besoin d'offrir aux acheteurs des escomptes pour des paiements avant échéance. Etant donné que le paiement avant échéance reçu par des fournisseurs d'institutions financières grâce à l'utilisation du système SCF ne constitue pas un emprunt, le paiement avant échéance permet de régler la facture sans endettement dans les comptes du fournisseur. [0060] Grâce à ce qui suit, nous disposons d'un aperçu logique du système SCF en détaillant le déroulement des opérations et en décrivant le rôle de chaque participant dans ce processus. La figure lA décrit les parties, composants, processus et le cheminent des informations au sein d'une seule communauté d'un système SCF 10. [0061] De préférence, le système SCF 10 est livré en tant que système informatique hébergé. En temps normal, il n'est pas nécessaire d'installer un logiciel dans le système informatique des participants (acheteur 106, fournisseur 108 ou institution financière 110). De préférence, par mesure de sécurité, toutes les communications entrantes et sortantes du système SCF 10 utilisent des transmissions codées sur l'Internet public de manière usuelle. Il convient de relever que le système SCF 10 permet d'effectuer des transactions transfrontalières sans avoir besoin d'utiliser des lettres de crédit. [0062] Le système SCF 10 fournit des services aux groupes d'entités impliqués dans la transaction de financement, chaque groupe étant connu comme une communauté de clients ou communauté. Une communauté de clients classique comprend un seul grand acheteur 106 de biens et services (et éventuellement ses succursales (c-à-d, plusieurs acheteurs apparentés) ; collectivement, « acheteur »), les fournisseurs 108 de cet acheteur 106 (« fournisseurs »), et les institutions financières 110 qui pourraient se décider à acquérir les obligations de paiement de l'acheteur 106 vis-à-vis du fournisseur 108 (« FI » ou « Institutions financières »). Une communauté de clients est un groupe d'acheteurs, de fournisseurs et d'institutions financières qui effectuent via le système des transactions 10 qui sont gérées par, et qui dépendent d'accords conclus avec, un animateur de communauté donné 120. Un seul animateur de communauté peut avoir la charge de plusieurs communautés de clients, mais une communauté 21 de clients donnée est gérée uniquement par un seul animateur de communauté (même lorsque l'animateur de communauté est représenté par plus d'une entité). L'animateur de communauté organise les différentes parties en communautés selon sa convenance. En principe, tel que mentionné, ci-dessus, une communauté sera constituée d'un seul acheteur ou d'un groupe d'acheteurs apparentés, par exemple, des filiales d'une même entreprise, mais le gestionnaire de communauté peut attribuer plusieurs acheteurs non apparentés (dans la présente forme particulière de réalisation, via le prestataire de services qui définit les acheteurs) à une communauté à sa convenance. Un animateur de communauté dispose d'un accès à toutes les données de sa communauté et pourrait ainsi les dupliquer si besoin est. Les autres parties, c-àd, les acheteurs, les fournisseurs et les institutions financières, ne jouissent d'aucun privilège ni d'aucune fonction au sein de la communauté. [0063] Le programme d'un acheteur est un ensemble de règles ou de paramètres qui régissent les transactions. Le programme d'un acheteur définit, par exemple, la monnaie, le fuseau horaire et les jours fériés. Un programme d'acheteur ne correspond qu'à un seul acheteur. Toutes les transactions effectuées dans un programme d'acheteur sont exécutées conformément aux règles du programme concerné. [0064] Comme cela sera discuté ci-dessous, un animateur de communauté 120 (la figure 1A) ou un prestataire de services d'un système ou opérateur 20, où le prestataire de service joue à la fois le rôle de fournisseur de services et d'animateur de communauté, pour une communauté spécifique, conclut un accord avec un acheteur 106, chaque fournisseur 108 et chaque institution financière 110, et où le fournisseur et l'institution financière conclut un accord entre eux pour régir les transactions effectuées via le système 10. Dans la présente forme particulière de réalisation, le prestataire de service maintient, exploite et héberge les ordinateurs et les systèmes informatiques susmentionnés, en s'assurant que les équipements physiques fonctionnent correctement et que les données sont transférées et stockées avec succès. L'animateur de communauté est chargé, pour une communauté de clients donnée, d'exploiter le système 10 selon une vision purement fonctionnelle, en interagissant via l'interface utilisateur du système avec le programme informatique qui fonctionne dans le système informatique pour définir les paramètres, en exécutant les fonctions décrites dans ce document, à un niveau purement administratif, ainsi qu'en entrant et en gérant les contrats entre les parties membres de la communauté de clients. Une seule entité peut fonctionner comme administrateur système et un ou plusieurs animateurs de communauté ; ou alors, différentes entités peuvent exécuter ces fonctions. [0065] Chacun de ces accords peut être défini entre l'animateur de communauté et une autre partie ou entre le fournisseur et l'institution financière, de telle sorte qu'il n'y a aucun accord tripartite ou quadripartite étant donné que de tels accords ne sont pas nécessaires. Par exemple, l'accord entre l'animateur de communauté/fournisseur et le fournisseur/institution financière peut être renforcé en un seul accord. [0066] Voici ci-dessous une liste des participants du système 10, ainsi qu'une description générale de leurs rôles : [0067] 1. L'animateur de communauté 120 est chargé de l'organisation des participants par rapport aux transactions effectuées via le système 10 et de la définition des paramètres régissant ces transactions. Tel que décrit ci-dessous, les transactions se déroulent dans les programmes des acheteurs, un ou plusieurs de ces programmes sont définis pour une 23 communauté donnée. Pour chaque programme d'acheteur, l'animateur de communauté pourrait définir : a. Les règles de restriction d'auto-avancement - c-à-d, des règles (applicables à tous les fournisseurs sur un programme d'acheteur) régissant la transaction automatique d'obligations chargées sur le système 10 par les acheteurs. Dans la forme particulière de réalisation actuellement décrite, ces règles sont utilisées pour initier une offre de vente automatique à obligation par un fournisseur à la date de maturité de fournisseur ou avant celle-ci. Dans une autre forme particulière de réalisation, l'offre de vente automatique basée sur la date de maturité de fournisseur survient indépendamment des règles d'auto-avancement, et le fournisseur peut par conséquent configurer que l'auto-avancement survienne indépendamment de la date de maturité de fournisseur. b. Les profils de facturation des institutions financières - c-à-d, les règles de facturation applicables aux transactions conduites via le programme d'acheteur par une institution financière donnée. Ceci est généralement défini en tant que deux taux d'intérêt appliqués à une valeur totale d'une obligation soumise à la vente par un fournisseur, desquels découlera une commission au profit de l'institution financière. Les institutions financières peuvent également ajouter leurs profils de facturation et éditer les profils de facturation qui leur sont applicables. c. Les frais de transaction de fournisseur - des frais facultatifs, ajoutés à la commission de l'institution financière (généralement en tant qu'honoraires fixes par transaction), donnant ainsi lieu à une commission partagée entre le prestataire de service et le gestionnaire de communauté. d. Les frais de transaction d'institution financière - des frais facultatifs, ajoutés à la commission de l'institution financière (généralement en tant qu'honoraires fixes par transaction), donnant ainsi lieu à une commission partagée entre le prestataire de service et le gestionnaire de communauté. e. Termes minimum et maximum. Le terme minimum est un nombre de jours minimum précédant la date de maturité d'acheteur relative à une obligation au cours desquels le système 10 permettra la vente de l'obligation. Au-delà de ce nombre de jours précédant la date de maturité d'acheteur, l'obligation ne pas peut être vendue. Le terme maximum est un nombre de jours maximum précédant la date de maturité à laquelle une obligation est susceptible d'être vendue. Dans les formes particulières de réalisation actuellement décrites, ces paramètres ne sont pas utilisés étant donné qu'une restriction sur la capacité du système à conduire une transaction sur une obligation pourrait créer un conflit avec la nécessité de vendre une obligation au plus tard à la date de maturité de fournisseur. Il est cependant possible d'utiliser ces paramètres, par exemple, lorsque des inquiétudes sur la possibilité d'effectuer des transactions au-delà des restrictions établies par les termes maximum et minimum priment sur la nécessité de vendre une obligation à la date de maturité de fournisseur. Par ailleurs, le système peut appliquer les termes maximum et minimum, mais 25 également les annuler lorsqu'il y a nécessité de vendre une obligation à la date de maturité de fournisseur. f. Réserves - valeur minimale des obligations transférées d'un programme d'acheteur, elle doit être présentée avant la conduite de toute transaction sur les obligations de l'acheteur. De manière générale, le système 10 exige que le montant de la réserve ne fasse pas l'objet de transaction ; par conséquent, aucune transaction d'obligations n'est autorisée pour des acheteurs qui verraient la valeur totale de leurs obligations non vendues chuter en-dessous du montant de la réserve. Comme avec les termes minimum et maximum, la fonctionnalité de réserve n'est de préférence pas utilisée pour des programmes d'acheteur ayant des exigences relatives aux dates de maturité de fournisseur, étant donné qu'il est souhaitable de vendre toutes les obligations (ayant des dates de maturité de fournisseur) avant ou à la date de maturité de fournisseur, même si la transaction pourrait affecter la réserve. Comme cela est également vrai pour les termes minimum et maximum, toutefois, il est cependant possible d'utiliser les réserves, par exemple, lorsque la nécessité de maintenir les réserves prime sur le besoin de vendre des obligations au plus tard à la date de maturité de fournisseur ou lorsque le système est configuré de manière à maintenir les réserves, mais également à autoriser les exceptions en tant que de besoin pour satisfaire les exigences relatives aux dates de maturité de fournisseur. g. Numéro de compte pour le paiement de l'acheteur (compensation de maturité) - le numéro d'un compte à partir duquel l'acheteur effectue ses paiements, et sur la base duquel l'animateur de communauté génère des instructions de paiement. h. Numéro de compte de l'animateur de communauté (marginal) - le numéro d'un compte vers lequel les commissions sont virées les commissions de l'animateur de communauté. i. Les montants d'offres de vente minimum et maximum - limites définies par l'animateur de communauté, de manière générale, sur la base d'un accord avec des institutions financières pour un programme d'acheteur spécifique. Ces restrictions, si implémentées, définissent des seuils élevés et bas sur la valeur de chaque transaction. Comme avec les termes minimum et maximum, ainsi qu'avec les réserves, la fonctionnalité d'offre de vente minimum et maximum n'est de préférence pas utilisée pour des programmes d'acheteur ayant des exigences relatives aux dates de maturité de fournisseur, étant donné qu'il est souhaitable de vendre toutes les obligations ayant des dates de maturité de fournisseur au plus tard à la date de maturité, même si de telles transactions pourraient violer les restrictions sur les montants de vente d'offre. Comme cela est également vrai pour ces autres restrictions, toutefois, il est cependant possible d'utiliser les montants de vente limites, par exemple, lorsque la nécessité de restreindre les transactions sur cette base prime sur le besoin de vendre des obligations au plus tard à la date de maturité de fournisseur ou lorsque le système est configuré de manière à appliquer les restrictions relatives 27 aux montants des offres de vente, excepté lorsqu'une transaction est requise pour satisfaire les exigences relatives aux dates de maturité de fournisseur. j. Institutions financières. L'animateur de communauté peut attribuer à un programme d'acheteur d'une communauté de clients donnée toute institution financière de cette communauté. Un acheteur peut également être une institution financière et dans ce cas, une entité peut être à la fois un acheteur et une institution financière. k. Attribution des profils de facturation. L'animateur de communauté attribue des profils de facturation à des institutions financières de telle sorte que le profil attribué s'applique aux transactions de l'institution financière concernée. 1. Règles de sélection des institutions financières. Lorsqu'un programme d'acheteur dispose de plusieurs institutions financières, l'animateur de communauté peut définir les règles régissant la sélection des institutions financières pour les transactions exécutées dans ce programme, tel que décrit ci-dessous. m. Fournisseurs. L'animateur de communauté peut définir des fournisseurs et attribuer à un programme d'acheteurs d'une communauté de clients donnée tout fournisseur de cette communauté. [0068] 2. Le prestataire de service 20 est chargé du maintien et de l'exploitation des ordinateurs et des bases de données du système SCF, ainsi que du maintien des codes informatiques qui pilotent le système. Le prestataire de service valide tous les comptes bancaires entrés par les parties et fournit le support et la maintenance de connexion au système. Pour un programme d'acheteur donné, le prestataire de services définit : a. Les plans de facturation des prestataires de services - c-à-d, les règles de facturation applicables aux transactions conduites via le programme d'acheteur. Ceci se définit en principe, en tant que pourcentage appliqué à une valeur totale d'une obligation soumise à la vente par un fournisseur, d'où sera prélevée une commission au profit du prestataire de service. b. Règles de traitement des paiements. Pour chaque communauté, le prestataire de services définit une méthode (par exemple, SWIFT, T2 ou EDI) par laquelle les paiements décrits dans ce document sont effectués. c. Pays, monnaie et fuseau horaire. Ces paramètres permettent, par exemple, de définir la monnaie utilisée par le programme d'acheteur pour ses transactions, ainsi que le fuseau horaire qui régit les déclencheurs chronologiques. d. Fermeture et ouverture des fenêtres d'offres de vente - heures de la journée entre lesquelles les offres de vente peuvent être acceptées. Lorsqu'un programme d'acheteur dispose de restrictions relatives à la date de maturité de fournisseur, ces paramètres sont de préférence, mais pas nécessairement, définis pour permettre l'acceptation pendant la journée entière. e. Acheteurs. Le prestataire de services définit les acheteurs d'une communauté de clients et peut leur assigner un programme spécifique. f. Mise en place initiale d'une communauté. 29 g. Fournisseurs. Le prestataire de services, ainsi que l'animateur de communauté, peuvent définir des fournisseurs et leur attribuer des programmes d'acheteur. h. Groupes d'acheteurs. Le prestataire de services peut mettre en place un groupe d'acheteurs à partir de plusieurs acheteurs relevant d'un même programme d'acheteurs, permettant ainsi un rapport de groupe. i. Données des profils bancaires. j. Institutions financières. Le prestataire de services définit les institutions fmancières de son système et leur attribue des communautés. [0069] 3. Acheteurs : Les acheteurs 106 soumettent par voie électronique les obligations de comptes à payer au système SCF 10. Les acheteurs 106 fournissent également les informations de leurs comptes bancaires et d'autres données d'entreprise, en tant que de besoin, en vue de permettre le règlement des obligations à l'obligataire (FI ou fournisseur), définies par le système 10 à la date d'échéance acheteur. [0070] 4. Fournisseurs : Les fournisseurs 108 soumettent des offres visant la vente d'obligations définies par le système et initiées par les acheteurs 106, en tant que transactions permettant d'obtenir des financements. Les fournisseurs 106 reçoivent la valeur des obligations lorsqu'ils participent à une transaction, après la déduction des frais applicables. Les fournisseurs 106 peuvent soumettre des groupes d'obligations à vendre qui sont ensuite présentés aux institutions financières 110 sous forme d'offres de vente. [0071] 5. Institutions financières : Les institutions financières 110 fournissent des liquidités aux programmes d'acheteur auxquels elles appartiennent. Les institutions financières sont des utilisateurs du système 10 qui acceptent des offres de vente faites par les fournisseurs 8. Lorsqu'une institution financière 110 accepte une offre de vente, elle est contractuellement astreinte à verser au fournisseur 108 la valeur de la transaction telle que mentionnée dans l'offre de vente au moment de l'acceptation, conformément à l'accord conclu entre l'institution financière et l'animateur de communauté. Dès l'acceptation d'une offre de vente, le système tient compte de la transaction qui se déroule en conformité avec les dispositions contractuelles. Les obligations SCF sont payées, à leur valeur réelle, à l'institution financière 110 par les acheteurs 106 à la date de maturité d'acheteur. [0072] 6. Banques : Les banques 18 sont des institutions monétaires qui exécutent le transfert réel des fonds et la notification du transfert des fonds au système SCF 10. Une fois notifié, le système 10 suit tous les paiements et envoie toutes les notifications aux différentes parties du système 10, y compris la tenue des données d'historique. Contrats [0073] Le système SCF 10 est implémenté sur la base de quatre accords fondamentaux : l'accord avec le client (« CA »), l'accord avec l'institution financière (« FIA »), l'accord avec le fournisseur (« SA ») et l'accord d'achat des créances (« RPA »). Les parties de ces accords sont illustrés à la figure 1B. L'animateur 120 conclut des accords avec chaque acheteur 106 (pour chaque acheteur, un CSA), chaque fournisseur 108 (pour chaque fournisseur, un SA) et chaque institution financière 110 (pour chaque institution financière, un FIA). Les fournisseurs et les institutions financières qui acceptent de commercer sur des obligations de fournisseur concluent des RPA. Une description plus détaillée des contrats est fournie ci-dessous. 31 [0074] Le CA est un accord conclu entre un acheteur et l'animateur d'une communauté. L'accord (dans une forme particulière de réalisation) contient les modalités générales ci-dessous pertinentes pour la présente description : - « La date de maturité de l'acheteur », concernant l'obligation de paiement et la créance associée, transférés par le fournisseur à une institution en vertu d'une transaction achevée, est la date à laquelle l'acheteur paie le montant certifié au cessionnaire ; cette date étant la date publiée par l'acheteur comme « date de maturité d'acheteur » lorsqu'il publie une obligation de paiement relative à cette créance. Cette date ne dépasse pas le nombre de jours (à décider par les parties), de la fin du mois au cours duquel la facture est délivrée, ou, si cette date n'est pas un jour ouvrable, le jour ouvrable suivant. - Une « obligation de paiement » est, en relation avec une créance, l'obligation d'un acheteur de payer le montant certifié correspondant à la date de maturité applicable, telle que publiée par l'acheteur, ainsi que l'obligation de l'acheteur de payer tout intérêt découlant d'un retard de paiement du montant certifié, que ce soit en vertu des modalités d'une relation sous-jacente entre l'acheteur et un fournisseur auquel une créance est liée ou impliquée conformément à la loi. - Une « date de maturité de fournisseur » est, par rapport à une obligation de paiement et une créance associée, la date de règlement de l'obligation de paiement concernée et de la créance associée, telle que définie dans la relation sous-jacente conclue entre l'acheteur et le fournisseur et telle que publiée sur le système en tant que « date de maturité de fournisseur » lorsque l'acheteur publie une obligation de paiement, ou, si une telle date n'est pas un jour ouvrable, le prochain jour ouvrable. - La date de maturité est la date de maturité de fournisseur ou, si l'obligation de paiement a été transférée, la date de maturité d'acheteur. - L'acheteur accepte qu'en soumettant une obligation de paiement au système SCF, il initie une obligation légale, valide, transférable, contraignante et irrévocable de payer au fournisseur ou cessionnaire applicable le montant certifié correspondant à la date de maturité spécifiée. L'acheteur ne peut publier une obligation de paiement qui fait l'objet d'une opposition ou qui constitue une opposition à une obligation de paiement et à la créance associée, excepté en vertu d'une note de crédit. L'acheteur peut publier une ou plusieurs notes de crédit, de temps à autre, en vue réduire le montant brut d'une obligation de paiement et de la créance associée, jusqu'à la fin de la fenêtre de transfert de cette obligation de paiement et de la créance associée. Si une note de crédit est publiée à la fm de la fenêtre de transfert de l'obligation de paiement et de la créance associée applicables, elle s'appliquera à toute autre obligation existante ou future et créance associée du fournisseur concerné, en vertu de laquelle la fenêtre de transfert ne s'est pas fermée. - L'acheteur reconnaît et accepte qu'un (A) fournisseur pourrait de manière involontaire faire une offre irrévocable sur une obligation de paiement à tout moment, avant la date de maturité de fournisseur ; (B) le système SCF sera paramétré afin de générer une offre de transfert irrévocable de l'obligation un (1) jour avant la date de maturité de fournisseur pour chaque obligation de paiement et chaque créance associée qui n'ont pas été transférées avant une telle date ; et (C) tandis que le paiement d'un montant certifié au profit d'un fournisseur ou cessionnaire, si besoin est, réduira l'obligation de l'acheteur à payer l'obligation et la créance associées au profit d'un tel fournisseur ou d'un tel cessionnaire selon le montant certifié, tous les autres montants dus en vertu d'une relation sous-jacente entre l'acheteur et le fournisseur restent non payés. - L'acceptation de l'acheteur de fournir à l'animateur de communauté ses informations bancaires, ainsi que d'autres informations, telles que requises par l'animateur de communauté pour lui permettre d'effectuer un règlement via un transfert électronique des obligations de paiement au fournisseur ou au cessionnaire à la date de maturité applicable. L'acheteur exécute et fournit de tels documents et coordonnées ou autres, en tant que de besoin ou raisonnablement requis par l'animateur de communauté, pour des besoins de règlement des obligations de paiement par transfert électronique. L'acheteur accepte et autorise l'animateur de communauté à effectuer un transfert électronique des fonds, de son compte de paiement à la date de maturité applicable au fournisseur concerné ou, dans le cas où l'obligation de paiement a été transféré à une institution financière, à l'institution financière ayant acquis l'obligation. L'acheteur accepte d'entretenir et de créditer son compte de paiement client, aussi longtemps qu'il existe des obligations de paiement ou des traites de banque en attente. - Toutes les obligations de paiement, les montants des notes de crédit, les transferts, les paiements, les débits et les crédits effectués par les acheteurs, les fournisseurs et les institutions financières via le système SCF, sont libellés dans la monnaie de l'obligation concernée. 33 - L'acheteur est lié par ses obligations de paiement, ses notes de crédit, ses choix irrévocables, ses transferts, ses notifications de transfert, ses offres, ses acceptations, ses choix et autres communications via le système SCF, même si de tels documents sont électroniques et non imprimés. [0075] L'accord avec l'institution financière est conclu entre l'institution financière et l'animateur de communauté. Voici ses dispositions générales : - Une « obligation de paiement » est, en relation avec une créance, l'obligation d'un acheteur de payer le montant certifié correspondant à la date de maturité applicable, telle que publiée par l'acheteur, ainsi que l'obligation de l'acheteur de payer tout intérêt découlant d'un retard de paiement du montant certifié, que ce soit en vertu des modalités d'une relation sous-jacente entre l'acheteur et un fournisseur auquelle une créance est liée ou impliquée conformément à la loi. - Pour chaque fournisseur, le système SCF a la responsabilité, dès réception de l'accord d'achat de créances entièrement exécutées entre un fournisseur et une institution financière et de la notification que le fournisseur remplit les conditions requises par l'institution financière, de désigner l'institution financière en tant que personne qui peut acheter les obligations de paiement et les créances associées du fournisseur sur le système SCF, en conformité avec les règles applicables à la communauté de clients, à l'accord avec le fournisseur, à l'accord avec le client et à l'accord d'achat de créances. L'institution financière reconnaît et accepte que lorsqu'une communauté de clients comprend plus d'une institution financière, le système SCF autorise le choix irrévocable qu'une obligation de paiement soit visualisée et proposée à la vente à une seule et unique institution financière au même moment. - Le système SCF autorise une personne à agir en qualité d'institution fmancière en conformité avec cet accord uniquement après qu'elle ait été approuvée par l'acheteur. - L'acheteur pourrait, mais n'est pas contraint de, publier ses obligations de paiement sur le système SCF. L'institution financière reconnaît à chaque acheteur les accords de paiement suivants : (A) qu'en publiant une obligation de paiement, l'acheteur initie une obligation légale, valide, transférable, contraignante et irrévocable de payer au fournisseur applicable le montant certifié à la date de maturité spécifiée ou, en cas d'un ou de plusieurs transferts, au cessionnaire applicable. (B) que l'obligation de payer le montant certifié à la date de maturité d'acheteur, tel que défini dans la phrase précédente, ne fera l'objet d'aucune opposition ; (C) que ni le fournisseur ni le cessionnaire n'engage ou ne saurait engager sa responsabilité, de manière contingente ou autrement, vis-à-vis de l'acheteur en vertu de la création d'une obligation de paiement, de l'émission d'une note de crédit, de la publication d'un choix irrévocable de vendre une obligation de paiement, de la publication d'une acceptation d'un choix irrévocable, du transfert d'une obligation de paiement et de la créance associée ou de la réception d'un montant certifié ; (D) que l'acheteur accepte de renoncer à toute opposition ou réclamation (contingente ou autrement) par rapport à une obligation de paiement ou à un montant certifié. - L'institution financière reconnaît que, au cas où l'acheteur formulerait une opposition de quelque nature que ce soit en rapport à une relation sous-jacente entre l'acheteur et le fournisseur ou en rapport à une obligation de paiement et de la créance associée, l'acheteur pourrait, mais n'est pas contraint de, publier une note de crédit en conformité avec les modalités du présent accord. - Dès la publication d'une obligation de paiement par l'acheteur et en conformité avec l'accord d'achat de créance applicable, le fournisseur pourrait, à sa seule discrétion, publier un choix irrévocable de transférer une ou plusieurs obligations de paiement et les créances associées à une institution financière. L'institution financière reconnaît l'accord du fournisseur selon lequel, dès publication d'un choix irrévocable, le fournisseur ne saurait vendre, offrir de vendre, transférer, promettre ou proposer en tant que garantie à une personne quelconque ou consentir à une charge sur de telles obligations de paiement et les créances associées. - Sauf dans le cas d'une exigence prescrite dans un accord d'achat de créance visant l'achat de toutes les obligations qui remplissent les conditions requises par une institution financière, après la publication d'un choix irrévocable par un fournisseur, en conformité avec l'accord d'achat de créance et les règles régissant la communauté de clients concernée, une institution financière pourrait, à sa seule discrétion, opter d'acheter l'obligation concernée et la créance associée en publiant une acceptation de choix irrévocable, à condition que l'obligation concernée remplisse les conditions. 35 - En conformité avec l'accord d'achat de créance, le prix d'achat d'une ou de plusieurs obligations est la somme de tous les Montants nets de le FI versés par une institution financière pour telles obligations. - En conformité avec l'accord d'achat de créance, l'institution financière s'assure de la disponibilité, le même jour ouvrable que celui de la publication d'une acceptation de choix irrévocable par une institution fmancière (ou le jour ouvrable suivant si l'acceptation survient après l'horaire défini par les règles de fonctionnement de la communauté de clients), du Montant net de le FI dans le Compte de paiement de le FI pour le transfert électronique des fonds. En conformité avec l'accord d'achat de créance, au moment auquel tout ce qui suit survient, une transaction est réputée être « une Transaction achevée » si : (i) l'institution financière s'est assurée de la disponibilité du Montant net FI dans le Compte de paiement FI ; (ii) l'institution financière a publié son acceptation du choix irrévocable du fournisseur ; (iii) l'obligation de paiement pertinente et la créance associée remplissent les critères requis par l'institution financière ; et (iv) l'acheteur a reçu une notification de transfert d'une telle transaction. - Dès l'occurrence d'une Transaction achevée et en conformité avec l'accord d'achat de créance, tous les droits, titres et intérêts liés à l'obligation de paiement sont vendus, attribués et transférés à l'institution financière acquéreuse, sans autre forme d'action ou documentation de la part du fournisseur, de l'acheteur ou de l'institution financière. - Si la Transaction achevée survient avant la période du programme de financement, le système SCF émettra des instructions EFT le même jour ouvrable en vue de transférer le Montant net de fournisseur, du Compte de paiement FI vers le Compte de réception de fournisseur. Si la Transaction achevée survient après la période du programme de financement, le Montant net FI s'affichant aura la valeur du jour ouvrable suivant et le système SCF émettra des instructions EFT à implémenter le jour ouvrable suivant en vue de transférer le Montant net de fournisseur, du Compte de paiement FI vers le Compte de réception de fournisseur. - En principe, les instructions EFT sont envoyées par le système SCF après les heures de travail de tels jours ouvrables, en conformité avec toutes les exigences relatives aux règles applicables à la communauté de clients concernée. En dépit de ce qui précède, dans le cas où la banque qui héberge le Compte de paiement FI ou le Compte de réception de fournisseur est fermée lors d'un tel jour ouvrable ou dans le cas où les systèmes de transfert électronique ne fonctionnent pas, alors le système SCF pourrait exécuter des transferts de fonds électroniques le prochain jour ouvrable lorsque de telles banques sont ouvertes et les systèmes de transfert électronique fonctionnent. - À la date de maturité d'acheteur de chaque obligation de paiement transféré et en conformité avec le présent accord et d'autres applicables, le système SCF émettra des instructions EFT permettant le transfert du montant certifié, du compte de paiement de l'acheteur vers le Compte de réception FI, en conformité avec les règles régissant la communauté de clients. - Sauf en cas de disposition contraire dans l'accord d'achat de créance, le système SCF reconnaît que l'institution financière n'est pas tenue d'accepter le choix irrévocable de transférer une quelconque obligation de paiement, et la décision prise par l'institution financière d'accepter ou de refuser tout choix irrévocable quelconque relève de la seule discrétion de l'institution financière. L'institution financière reconnaît qu'aucun fournisseur n'est obligé de soumettre des choix irrévocables pour transférer des obligations de paiement et les créances associées à une institution financière et la décision d'un fournisseur de soumettre des choix irrévocables pour des transferts dépend de sa seule discrétion. - L'institution financière accepte de publier des informations des Comptes de paiement FI et des Comptes de réception FI sur le système SCF, en tant que de besoin, en vue de permettre le règlement électronique des obligations de paiement et des créances associées dès la fin du transfert et à la date de maturité spécifiée. L'institution financière exécutera et émettra de tels documents et instruments et d'autres, nécessaires ou raisonnablement requis, pour le système SCF et les banques participantes fourniront des instructions EFT précises permettant le règlement, via le transfert électronique des fonds, des obligations et des créances y relatives transférées par le fournisseur, la réception des paiements de l'acheteur et le paiement de tout frais requis par le système SCF par le fournisseur. L'institution financière autorise par la présente le système SCF à émettre des instructions EFT permettant aux banques concernées d'effectuer un virement électronique des fonds : (A) du Compte de paiement FI ; et (B) vers le Compte de réception FI, tout deux en accord avec les dispositions du présent accord. - Le système SCF accepte que l'institution financière puisse exercer ses droits dans le cadre des dispositions de l'accord avec le client et de l'accord avec le fournisseur selon lesquelles l'institution financière est constituée bénéficiaire tiers, à son nom propre, sans l'approbation du système SCF, et sans jonction du système SCF dans aucune procédure. 37 - Toutes les obligations de paiement, les montants des notes de crédit, les transferts, les paiements, les débits et les crédits effectués par les membres de la communauté via le système SCF en fonction des différentes obligations de paiement, y compris, et les paiements de et vers les Compte de paiement Client, Compte de réception Fournisseur, Compte de réception FI et Compte de paiement FI, seront libellés dans la monnaie de l'obligation de paiement. - Le consentement des parties pour la création, la communication et l'émission des obligations de paiement, des notes de crédit, des choix irrévocables, des acceptations des offres irrévocables, des transferts, des notifications de transfert, des offres, des acceptations et d'autres communications, ainsi que la création de contrats contraignants via le système SCF, même si de telles actions sont menées par voie électronique et non sur document imprimé. Les parties acceptent que de telles actions sont des obligations valides et contraignantes des membres de la communauté concernée, comme si de telles actions avaient été menées sur la base de document papier. [0076] L'accord Fournisseur est conclu entre le fournisseur et l'animateur de communauté. Les dispositions pertinentes sont : - « Un jour ouvrable » est un jour où les banques et les marchés de commerce international sont ouverts pour les activités commerciales générales, au moins dans les pays où l'acheteur et l'institution financière sont basés et qui n'est pas un samedi, un dimanche ou un jour férié dans de tels pays. - « Le montant certifié », s'agissant de toute obligation de paiement, est le montant brut de l'obligation de paiement moins la somme de tous les montants des notes de crédit imputables au fournisseur qui : (A) n'ont pas été appliqués au titre des obligations de paiement précédents ; et (B) sont publiés avant la date et l'heure auxquelles une offre irrévocable est publiée ou un choix irrévocable est effectuée par le système SCF. - Le montant certifié est fixé avant : (1) la date et l'heure auxquelles ce fournisseur publie une offre irrévocable ou le système SCF effectue un choix irrévocable de transférer l'obligation de paiement et la créance associée ; ou (2) la fermeture de la fenêtre du transfert. Si le fournisseur en vigueur a déjà publié un choix irrévocable lorsqu'une note de crédit est publiée, le montant de la note de crédit est porté en diminution, et diminuera, d'autres obligations de paiement et créances existantes ou futures de l'acheteur au profit du fournisseur, le cas échéant, pour lequel un choix irrévocable n'a pas encore été publié. - « La date de maturité de l'acheteur », concernant l'obligation de paiement et la créance associée, transférées par le fournisseur à une institution en vertu d'une transaction achevée, est la date à laquelle l'acheteur paie le montant certifié au cessionnaire ; cette date étant la date publiée par l'acheteur comme « date de maturité d'acheteur » lorsqu'il publie une obligation de paiement relative à cette créance. Cette date ne dépasse pas le nombre de jours (à décider par les parties), de la fin du mois au cours duquel la facture est délivrée, ou, si cette date n'est pas un jour ouvrable, le jour ouvrable suivant. - Les « conditions de transfert FI » sont, les règles relatives aux limites de liquidité publiées sur le système SCF par l'institution financière, de temps à autre, auxquelles doit se conformer une obligation de paiement pour que la créance à laquelle l'obligation de paiement est associée soit éligible à l'achat par une institution financière. - La « documentation du programme de financement » est, la documentation pertinente qui définit les paramètres et les règles régissant une communauté de clients particulière. - Le « choix irrévocable » renvoie à la publication automatique par le système SCF d'une offre irrévocable de transférer toutes les obligations de paiement et créances associées qui ont été publiées sur le système par un acheteur, franc et quitte de toute opposition non spécifiée dans une note de crédit, un jour ouvrable avant la date de maturité de fournisseur pour chaque créance qui n'a pas été transférée avant une telle date. - L'« offre irrévocable » renvoie à une offre irrévocable publiée par un fournisseur de transférer une ou plusieurs obligations de paiement et créances associées qui ont été publiées sur le système SCF par un acheteur, franc et quitte de toute opposition non spécifiée dans une note de crédit, une telle offre irrévocable ne reste effective que jusque : (A) à l'achat de telles obligations de paiement et créances associées par une institution financière ; ou à la fermeture de la fenêtre de transfert. - La « date de maturité » est, en rapport à une obligation de paiement, sa date de règlement, ou si une telle date n'est pas un jour ouvrable, le jour ouvrable précédent (s'il s'agit d'une date de maturité de fournisseur) ou le jour ouvrable suivant (s'il s'agit d'une date de maturité d'acheteur). La date de maturité se définit soit comme la date de maturité de fournisseur ou, lorsque l'obligation de paiement et la créance associée ont été transférées, en conformité avec l'accord Client et l'accord d'achat 39 de créance, à une institution financière, soit comme la date de maturité d'acheteur. - « L'obligation de paiement » est, concernant une créance, l'obligation de l'acheteur de payer le montant certifié approprié à la date d'échéance en vigueur, publiée dans le système SCF. Elle désigne également l'obligation de l'acheteur de payer tout intérêt de retard de paiement du montant certifié, que ce soit conformément aux modalités d'un accord sous-jacent par lesquels cette créance est liée ou en vertu de la loi. - « La date de maturité de fournisseur », concernant une obligation de paiement et la créance associée, désigne la date à laquelle une obligation et la créance associée doivent être payées, tel que prévu dans l'accord sous-jacent et le système SCF en tant que « date de maturité du fournisseur » au cours de laquelle l'acheteur publie une obligation de paiement en rapport avec la créance associée, ou signifie la date du jour ouvrable précédent lorsque cette date ne correspond pas à un jour ouvrable. - La « fenêtre de transfert » est, en relation avec une obligation de paiement et la créance associée, la période allant de la date de publication de l'obligation de paiement jusqu'au jour précédent : (A) la date à laquelle le fournisseur publie une offre irrévocable ; (B) la date à laquelle un fournisseur cesse d'avoir le droit de transférer cette obligation de paiement et de la créance associée à l'institution financière (en préparation à la date de maturité de fournisseur de l'obligation de paiement concernée), comme convenu par l'institution financière et le système SCF (agissant ensemble), de temps à autre ; ou (C) un (1) jour ouvrable avant la date de maturité de fournisseur qui correspond à la date à laquelle le système SCF effectue un choix irrévocable. - La « relation sous-jacente » est une relation d'affaires entre un acheteur et un fournisseur. - Au regard d'une obligation de paiement quelconque qu'un acheteur publie sur le système SCF, les parties : (A) reconnaissent que l'acheteur a une obligation légale, valide, transférable, contraignante et irrévocable de payer le montant certifié à la date de maturité de fournisseur et où un ou plusieurs transferts sont survenus, à la date de maturité d'acheteur vers le cessionnaire applicable ; (B) reconnaissent que le fournisseur peut volontairement effectuer une offre irrévocable à tout moment avant la date de maturité de fournisseur ; (C) reconnaissent que le système SCF est configuré de manière à effectuer automatiquement un choix irrévocable un (1) jour ouvrable avant la date de maturité de fournisseur pour chaque créance qui n'a pas été transférée avant cette date ; (D) reconnaissent que l'obligation de l'acheteur de payer le montant certifié à la date de maturité d'acheteur ne doit pas faire l'objet d'une opposition ; (E) acceptent que ni le fournisseur ni le cessionnaire n'aient ou n'assume de responsabilité, contingente ou autrement, vis-à-vis de l'acheteur en vertu de la création d'une obligation de paiement, de l'émission d'une note de crédit, de la publication d'une offre irrévocable, de la génération d'un choix irrévocable par le système SCF, de la publication d'une acceptation d'une offre irrévocable par une institution financière ou de l'acceptation d'un choix irrévocable (le cas échéant), le transfert d'une créance ou la réception d'un montant certifié ; (F) reconnaissent que, sous réserve des clauses ci-dessous, l'acheteur renonce à toute opposition ou réclamation (contingente ou autrement) par rapport à l'obligation de paiement ou au montant certifié ; et (G) reconnaissent que si l'acheteur fait une opposition quelconque en relation avec une relation sous-jacente à une obligation de paiement, il pourrait, mais n'est pas obligé de, publier une note de crédit. - Le paiement d'un montant certifié à un acheteur ou à un cessionnaire, tel que prévu dans le présent accord, est utilisé pour réduire l'obligation de l'acheteur à payer au fournisseur la créance correspondante dans la valeur du montant certifié. Toutes les autres sommes dont est redevable (i) l'acheteur en vertu de la ou suite aux réclamations liées à la créance applicable (y compris toutes les notes de crédit qui réduisent une quelconque obligation de paiement), ou (ii) le fournisseur en vertu d'une opposition quelconque, demeurent en vigueur et exécutoires, et ne sont pas affectées par la publication d'une obligation de paiement, la publication d'une offre irrévocable ou la génération d'un choix irrévocable par le système SCF, le transfert de créances, le paiement de montants certifiés, ou autrement en vertu du présent accord, excepté dans la mesure où elles sont appliquées pour calculer le montant certifié. - Le fournisseur renonce par la présente à toute réclamation ou défense qu'il pourrait avoir que la publication d'une obligation de paiement, la publication d'une offre irrévocable, la génération par le système SCF d'un choix irrévocable, le transfert de créances, le paiement de montant certifié, ou tout autre droit ou obligation, tel que prévu dans le présent accord, constitue une renonciation, un compromis ou un règlement d'une opposition quelconque. - Le fournisseur ne saurait vendre, offrir de vendre, transférer, promettre ou proposer en tant que garantie à une personne quelconque ou consentir à une charge sur de une créance qui fait l'objet d'une offre irrévocable ou d'un choix irrévocable. 41 - Le fournisseur est lié par ses déterminations de montants certifiés, ses notes de crédit, ses offres irrévocables, ses choix irrévocables, ses transferts, ses notifications de transfert, ses offres, ses acceptations, ses choix et autres communications via le système SCF, même si de tels documents sont électroniques et non imprimés. Le fournisseur renonce par la présente à toute réclamation ou défense, autre que ce qui est prévu dans le calcul du montant certifié par le système SCF, que de tels actes ne sont pas contraignants ou applicables, ou n'ont pas leur effet visé comme un résultat de la communication électronique. - Le fournisseur signe un accord d'achat de créance avec une institution financière qui a conclu un accord d'Institution financière avec le système SCF en qualité d'institution financière dans le cadre du présent accord. Dès réception de l'accord d'achat de créance dûment signé entre le fournisseur et une telle institution financière, le système SCF désigne l'institution financière applicable en tant que personne ayant le droit d'acheter des créances sur le système SCF. - En conformité avec les dispositions, et sous réserve de celles-ci, de l'accord d'achat de créance applicable : (A) lorsqu'une obligation de paiement est publiée, le fournisseur, peut à sa seule discrétion, publier, sur la fenêtre de transfert, une offre irrévocable de vendre l'obligation de paiement et la créance associée ; (B) si le fournisseur publie une offre irrévocable pour une obligation de paiement et la créance associée ou si le système SCF généré un choix irrévocable, l'institution financière publiera une acceptation et achètera une telle obligation et la créance associée conformément à la présente clause, à condition que l'obligation de paiement remplisse les critères de transfert FI ; (C) le même jour ouvrable au cours duquel un acheteur reçoit une notification de transfert par rapport à une obligation de paiement et à la créance associée qu'une institution financière aurait achetée (ou le jour ouvrable suivant si la notification est reçue après l'heure conclue pour le programme de financement), l'institution fmancière s'assure que le Montant net FI (le montant certifié, moins la commission de l'institution financière) est disponible dans le Compte de paiement FI (une compte bancaire spécifique créé et entretenu par une institution financière) et émet des instructions pour le paiement du Montant net Fournisseur (le montant certifié, moins la somme des commissions de l'institution financière et du gestionnaire de communauté) dans le Compte de réception Fournisseur ; (D) lorsque au regard d'une offre irrévocable ou un choix irrévocable : (1) une institution financière a acheté l'obligation de paiement et la créance associée pour laquelle il existe une telle offre irrévocable ou un choix irrévocable, en conformité avec les dispositions de l'accord d'achat de créance applicable ; et (2) l'institution financière s'est assuré de la disponibilité du Montant net FI dans le Compte de paiement FI, en association avec la possibilité pour, en fonction du seul choix de l'institution financière : (i) le système SCF d'envoyer un fichier de données à l'institution financière pour qu'elle puisse émettre des instructions EFT, sur la base des données contenues dans le fichier de données généré par le système SCF ; (ii) le système SCF d'émettre des instructions EFT pour que le paiement soit effectué dans la banque du fournisseur le jour ouvrable suivant ; (3) l'obligation de paiement concernée est conforme aux critères de transfert FI ; et (4) l'acheteur a reçu une notification de transfert pertinente, tous les droits, titres et intérêts greffés à une telle obligation de paiement et à la créance associée sont vendus, attribués et transférés à l'institution financière, sans nécessité d'une autre action ou documentation de la part du fournisseur, de l'acheteur ou de l'institution financière, sous réserve de l'exécution de l'engagement de l'institution financière à payer le Montant net FI en conformité avec l'accord d'achat de créance (« transaction achevée »). - Toutes les obligations de paiement, les montants des notes de crédit, les transferts, les paiements, les débits et les crédits effectués par les membres d'une communauté, via le système SCF par rapport à une obligation de paiement quelconque, aux paiements mentionnés sur les notes de crédit, et aux paiements au profit et en provenance du Compte de paiement Client (un compte bancaire créé et entretenu par un acheteur en son nom, utilisé pour le paiement des montants certifiés à la date de maturité d'acheteur), du Compte de réception Fournisseur (un compte bancaire créé et entretenu par un fournisseur en son nom, utilisé pour la réception des montants nets payés en sa faveur), du Compte de réception FI (compte bancaire créé et entretenu par une institution financière, utilisé pour le dépôt des fonds payables à l'institution financière) et du Compte de paiement FI, sont libellés dans la monnaie de l'obligation de paiement concernée. Le fournisseur ne saurait publier une offre irrévocable et le système ne saurait générer un choix irrévocable dans une monnaie qui n'est pas prise en charge par le système SCF. - Sous réserve des dispositions du présent accord relatif aux comptes fermés, si la transaction achevée survient : (A) avant l'heure du programme de financement, le système SCF émet des instructions EFT le même jour ouvrable au cours duquel la transaction achevée est survenue pour le transfert du Montant net Fournisseur du Compte de paiement FI vers le Compte de réception Fournisseur, avec mise à disposition des fonds dans la banque du fournisseur le jour ouvrable suivant ; (B) après l'heure du programme de fmancement, le Montant net FI est ajusté pour refléter la valeur du Montant net FI le jour ouvrable suivant et le système SCF émettra des instructions EFT qui seront exécutées le jour ouvrable suivant pour le transfert du Montant net Fournisseur du Compte de paiement FI vers le Compte de réception 43 Fournisseur, avec mise à disposition des fonds dans la banque du fournisseur le jour ouvrable suivant. - Si, à la fermeture de la fenêtre de transfert, une obligation de paiement n'a pas encore fait l'objet d'une transaction achevée, le système SCF génère automatiquement un choix irrévocable et dès l'acceptation d'une institution financière d'un tel choix irrévocable, le système SCF émet, au plus tard un (1) jour ouvrable avant la date de maturité de fournisseur, les instructions EFT de transfert du Montant net Fournisseur du Compte de paiement FI vers le Compte de réception Fournisseur. Par conséquent, au plus tard un (1) jour ouvrable avant la date de maturité d'acheteur, le système émet des instructions EFT pour transférer le montant certifié vers le Compte de réception FI. - Si, le jour ouvrable au cours duquel les instructions EFT doivent être envoyées en conformité avec le présent accord, la banque qui héberge le Compte de paiement Client ou le Compte de paiement FI (selon le cas) ou le Compte de réception Fournisseur, est fermée ou dans le cas où les systèmes de transfert électronique ne fonctionnent pas, le système SCF pourrait envoyer les instructions EFT le prochain jour ouvrable lorsque de telles banques sont ouvertes et les systèmes bancaires de paiement fonctionnent. - Le fournisseur fournit au système SCF des données relatives au Compte de réception Fournisseur et de telles données, que le système SCF requiert de manière raisonnable pour qu'elle puisse émettre les instructions EFT en vue du règlement des montants certifiés relatifs à l'obligation de paiement et à la créance associée dès le transfert et à la date de maturité de fournisseur. - Le fournisseur signe et envoie tout document et/ou instrument raisonnablement requis par le système SCF pour le règlement des transferts avec le fournisseur, la réception des paiements effectués par l'acheteur et le paiement des commissions du système SCF. - Le fournisseur autorise le système SCF à émettre des instructions EFT permettant le transfert du Montant net Fournisseur vers le Compte de réception Fournisseur. - Pour chaque transfert effectué par le fournisseur, une commission est prélevée pour le système SCF et pour l'institution financière (FI), et par conséquent, le fournisseur reçoit, dès le transfert de toute obligation de paiement et de la créance associée, le Montant net Fournisseur. Les commissions du système SCF et FI sont calculées en tant qu'escompte sur la base du nombre de jours précédent la date de maturité d'acheteur à laquelle le fournisseur reçoit le paiement, que ce soit à la suite d'une offre irrévocable ou d'un choix irrévocable, et le taux d'intérêt greffé, tel que décrit dans les calculs des commissions du système SCF et de l'institution financière, et défini ci-dessous. Dans le cas où un choix irrévocable est généré par le système SCF, l'escompte est calculé sur le nombre de jours entre la date de maturité d'acheteur et la date de maturité de fournisseur. La somme de la commission prévue du système SCF (commission de l'animateur de communauté) et de la commission FI (frais de l'institution financière), ainsi que le Montant net Fournisseur prévu pour chaque obligation de paiement prête à transférer sont affichées sur le système SCF en différents endroits, et peuvent être visualisés par le fournisseur à sa guise, à condition que ledit fournisseur dispose des droits d'accès appropriés au système SCF. - La commission du système SCF est calculée, comme suit : (La commission du système SCF en points de base)*(nombre de jours avant la date de maturité d'acheteur)*(valeur de la facture)/(nombre de jours de l'année) - Le fournisseur autorise le système SCF à émettre des instructions EFT par rapport au Compte de paiement FI applicable en vue de payer la commission du système SCF dès ou après l'émission desdites instructions pour transférer le Montant net Fournisseur du Compte de paiement FI vers le Compte de réception Fournisseur. La commission FI est calculée, comme suit : Commission FI : (La commission FI en points de base + taux d'intérêt de base)*(nombre de jours avant la date de maturité *(valeur de la facture)/ (nombre de jours de l'année) - Le nombre de jours dans l'année est généralement soit 360 soit 365, selon la décision de l'institution financière. - Le taux de base est le taux de change interbancaire de la devise (TIBEUR, TIOL en GBP, TIOL en USD, etc.) En général, il s'agit du taux de change interbancaire de la divise de 2 ou de 3 mois (TIBEUR de 3 mois, TIOL en GBP de 3 mois, par exemple). [0077] La Convention d'achat des créances s'effectue entre le fournisseur et l'institution financière. 45 - « Un jour ouvrable » est un jour pendant lequel les banques et les marchés de changes sont ouverts pour le déroulement des activités commerciales générales, à tout le moins, dans les pays où se trouvent l'acheteur et l'institution financière, qui est un jour différent du samedi, du dimanche et ou d'un jour férié dans ces pays. - « Le montant certifié », s'agissant de toute obligation de paiement, est le montant brut de l'obligation de paiement moins la somme de tous les montants des notes de crédit imputables au fournisseur qui : (A) n'ont pas été appliqués au titre des obligations de paiement précédents ; et (B) sont publiés avant la date et l'heure auxquelles une offre irrévocable est publiée ou un choix irrévocable est effectuée par le système SCF. - Le montant certifié est fixé avant : (1) la date et l'heure auxquelles ce fournisseur publie une offre irrévocable ou le système SCF effectue un choix irrévocable de transférer l'obligation de paiement et la créance associée ; ou (2) la fermeture de la fenêtre du transfert. Si le fournisseur en vigueur a déjà publié un choix irrévocable lorsqu'une note de crédit est publiée, le montant de la note de crédit est porté en diminution, et diminuera, d'autres obligations de paiement et créances existantes ou futures de l'acheteur au profit du fournisseur, le cas échéant, pour lequel un choix irrévocable n'a pas encore été publié. - « La date de maturité de l'acheteur », concernant l'obligation de paiement et la créance associée, transférées par le fournisseur à une institution en vertu d'une transaction achevée, est la date à laquelle l'acheteur paie le montant certifié au cessionnaire ; cette date étant la date publiée par l'acheteur comme « date de maturité d'acheteur » lorsqu'il publie une obligation de paiement relative à cette créance. Cette date ne dépasse pas le nombre de jours (à décider par les parties), de la fin du mois au cours duquel la facture est délivrée, ou, si cette date n'est pas un jour ouvrable, le jour ouvrable suivant. - « Heure en vigueur », désigne, lorsque le fournisseur publie une offre irrévocable en rapport avec une obligation de paiement et la créance associée : (A) l'heure de fermeture de la fenêtre commerciale du jour ouvrable suivant, dans le cas où le fournisseur publie une offre irrévocable relative à une obligation de paiement et à la créance associée au cour d'un jour non ouvrable, à l'heure ou après l'heure prévue pour le programme de financement (une heure prédéterminée dans un jour ouvrable) ; (B) ou l'heure de fermeture de la fenêtre commerciale durant ce jour ouvrable, avant l'heure prévue pour le programme de financement - « Les modalités de transfert FI » sont des règles relatives aux limites de liquidés publiées, de temps à autre, par l'institution financière au système SCF, auxquelles une obligation de paiement doit se conformer si l'on veut que la créance à laquelle l'obligation de paiement est liée soit éligible à l'achat par l'institution financière. Il est entendu que lorsque le fournisseur rejoint la communauté des clients, les seuils de liquidités de l'institution financière doivent être suffisants afin de satisfaire les besoins de fmancement du fournisseur. Dans le cas où l'institution financière se trouve obligée de limiter son seuil de liquidités dans la mesure où sa capacité de fmancement ne répond plus aux besoins de fmancement du fournisseur, elle peut résilier ce contrat. - « La documentation relative au programme de financement » est une documentation appropriée qui définit les paramètres et les règles pour une communauté de clients donnée. - Le « choix irrévocable » renvoie à la publication automatique par le système SCF d'une offre irrévocable de transférer toutes les obligations de paiement et créances associées qui ont été publiées sur le système par un acheteur, franc et quitte de toute opposition non spécifiée dans une note de crédit, un jour ouvrable avant la date de maturité de fournisseur pour chaque créance qui n'a pas été transférée avant une telle date. - « Une offre irrévocable » est une offre publiée par le fournisseur en vue du transfert d'une ou de plusieurs obligations et des créances publiées sur le système SCF par l'acheteur, qui est exempte de toute opposition non spécifiée dans un avis de crédit. Cette telle offre d'élection irrévocable entre en vigueur aussitôt que : (A) l'institution financière achète ces obligations de paiement et créances ; ou (B) à la fermeture de la fenêtre de transfert. - « La date d'échéance », concernant une obligation de paiement, est la date exacte à laquelle cette obligation de paiement doit être payée. Ou lorsque cette date n'est pas un jour ouvrable, le jour ouvrable suivant. La date de maturité est la date d'échéance du fournisseur ou, la date d'échéance de l'acheteur lorsque l'obligation de paiement et les créances y étant relatives ont été transférées à l'institution fmancière, conformément à l'accord du fournisseur et à la présente convention d'achat de créances. - « L'obligation de paiement » est, concernant une créance, l'obligation de l'acheteur de payer le montant certifié approprié à la date d'échéance en vigueur, publiée dans le système SCF. Elle désigne également l'obligation de l'acheteur de payer tout intérêt de retard de paiement du 47 montant certifié, que ce soit conformément aux modalités d'un accord sous-jacent par lesquels cette créance est liée ou en vertu de la loi. - « La date de maturité de fournisseur », concernant une obligation de paiement et la créance associée, désigne la date à laquelle une obligation et la créance associée doivent être payées, tel que prévu dans l'accord sous-jacent et le système SCF en tant que « date de maturité du fournisseur » au cours de laquelle l'acheteur publie une obligation de paiement en rapport avec la créance associée, ou signifie la date du jour ouvrable précédent lorsque cette date ne correspond pas à un jour ouvrable. - La « fenêtre de transfert » est, en relation avec une obligation de paiement et la créance associée, la période allant de la date de publication de l'obligation de paiement jusqu'au jour précédent : (A) la date à laquelle le fournisseur publie une offre irrévocable ; (B) la date à laquelle un fournisseur cesse d'avoir le droit de transférer cette obligation de paiement et de la créance associée à l'institution financière (en préparation à la date de maturité de fournisseur de l'obligation de paiement concernée), comme convenu par l'institution financière et le système SCF (agissant ensemble), de temps à autre ; ou (C) un (1) jour ouvrable avant la date de maturité de fournisseur qui correspond à la date à laquelle le système SCF effectue un choix irrévocable. - « La relation sous-jacente» est une relation d'affaires entre l'acheteur et le fournisseur. - La publication d'une offre irrévocable au système SCF ou l'opération d'un choix irrévocable par le système SCF est considérée comme une décision du fournisseur de vendre l'obligation de paiement et la créance associée à l'institution financière. - L'institution financière achète l'obligation de paiement et la créance associée, qui, dès l'heure en vigueur : (A) a été publiée sur le système SCF par l'acheteur ; (B) a été l'objet de la publication d'une offre irrévocable ou d'un choix irrévocable par le système SCF ; et (C) répond aux conditions de transfert FI. - L'institution financière informe le fournisseur via le système SCF : (A) si l'obligation de paiement est non conforme aux conditions de transfert FI ; ou (B) de son achat de l'obligation de paiement concerné et de la créance associée. - La transaction est considérée comme « achevée », lorsque tous les cas suivants sont observables, notamment lorsque : (A) le fournisseur a publié une offre irrévocable sur le système SCF ; (B) l'institution financière a rendu le montant net de le FI disponible dans le Compte de l'FI et a fourni des instructions pour le paiement du Montant net Fournisseur dans son Compte de réception ; (C) l'obligation de paiement concernée est conforme aux conditions de transfert de le FI ; et (D) le Client a reçu la notification d'un transfert en vigueur de cette transaction. - Une fois une transaction achevée, tous les droits, titres et intérêts du fournisseur vis-à-vis de l'obligation de paiement seront vendus, affectés et transférés à l'institution financière, sans aucune autre forme de procédure ou de documentation de la part du fournisseur, de l'acheteur ou de l'institution financière. - En considération du montant net du fournisseur et des actions prises par l'institution financière spécifiées dans le présent accord, le fournisseur, par la présente, transfert immédiatement à l'institution financière, dès l'heure en vigueur, avec toute la garantie des titres, franc et quitte de tout privilège et droits des tiers, tous ses droits, titre et intérêt : (A) chaque obligation de paiement et créance à la date en vigueur, est conforme ; (B) aux clauses relatives à l'accord des clients qui confèrent un bénéfice au fournisseur, en rapport avec l'obligation de paiement et la créance relative attribuée à l'institution par le fournisseur. - Le fournisseur, par la présente, désigne irrévocablement l'institution, agent du fournisseur, pour exécuter et fournir au nom du fournisseur, ces faits, accords et documents, afin d'achever ou d'endosser ces chèques ou d'autres instruments, d'engager une procédure et d'accomplir ces autres actes jugés nécessaires par l'institution financière afin de garantir toute obligation de paiement du fournisseur, conformément au présent accord, dont l'ordre de parfaire le droit de l'institution financière à une obligation de paiement et à la créance associée. - Durant le même jour ouvrable que celui du paiement du Montant net FI au fournisseur en conformité avec cet accord, l'institution financière exécute et envoie, au nom du fournisseur, un avis d'attribution de chaque obligation de paiement achetée et la créance associée à l'acheteur, via le système SCF auquel le Montant net FI est lié. - Selon le fournisseur et l'institution financière, chaque transfert constitue et est traité comme une vente réelle effectuée par le fournisseur à l'institution financière de l'obligation de paiement et la créance associée, objet de ce transfert. Ainsi, si l'intention du fournisseur et de 49 l'institution financière ne prend pas effet et si aucun transfert n'est traité comme une vente réelle, ou si, pour toute raison, un titre équitable et juridique et le droit de propriété de toute obligation de paiement et la créance associée ne sont pas transférés à l'institution financière, le fournisseur, par la présente, accepte, s'engage et concède à l'institution financière, à ses successeurs, un premier intérêt de sécurité prioritaire amélioré, actuel et continu de cette obligation de paiement et de la créance associée prévues pour être vendues à l'institution financière, afin de garantir les obligations des fournisseurs vis-à-vis de l'institution financière conformément aux documents de transaction. - Le fournisseur paie, pour chaque transfert, les commissions du système SCF et les commissions de le FI et reçoit, par conséquent, au titre du transfert de toute obligation de paiement et de la créance relative, le Montant net Fournisseur. Les commissions du système SCF et FI sont calculées en tant qu'escompte sur la base du nombre de jours précédent la date de maturité d'acheteur à laquelle le fournisseur reçoit le paiement, que ce soit à la suite d'une offre irrévocable ou d'un choix irrévocable, et le taux d'intérêt greffé, tel que décrit dans les calculs des commissions du système SCF et de l'institution financière, et défini ci-dessous. Dans le cas où un choix irrévocable est généré par le système SCF, l'escompte est calculé sur le nombre de jours entre la date de maturité d'acheteur et la date de maturité de fournisseur. - La commission du système SCF est calculée, comme suit : (La commission du système SCF en points de base)*(nombre de jours avant la date de maturité d'acheteur)*(valeur de la facture)/ (nombre de jours de l'année) - Le fournisseur autorise le système SCF à émettre des instructions EFT par rapport au Compte de paiement FI applicable en vue de payer la commission du système SCF dès ou après l'émission desdites instructions pour transférer le Montant net Fournisseur du Compte de paiement FI vers le Compte de réception Fournisseur. - Frais FI : (La commission FI en points de base + taux d'intérêt de base)*(nombre de jours avant la date de maturité d'acheteur)*(valeur de la facture)/ (nombre de jours de l'année) (le Nombre de jours dans l'année est généralement soit 360 ou 365 jours, selon l'institution financière.) - Le taux de base est le taux de change interbancaire de la devise (TIBEUR, TIOL en GBP, TIOL en USD, etc.) En général, il s'agit du taux de change interbancaire de la divise de 2 ou de 3 mois (TIBEUR de 3 mois, TIOL en GBP de 3 mois, par exemple). - L'institution financière paie, ou effectue le paiement du Montant net FI pour chaque obligation de paiement et créance associée qui, au même moment, sont conformes au présent accord. - Tous les paiements prévus par le présent accord sont effectués dans la devise de l'obligation de paiement concernée dans des fonds libérés au code matériel du compte bancaire du fournisseur/ numéro de compte fourni par le fournisseur. Si un paiement du Montant net Fournisseur au profit du Compte de Réception Fournisseur vient à échéance un jour non ouvrable, ce paiement est effectué le jour ouvrable précédent ; le montant de ce paiement ne peut être, par conséquent, ajusté. - Le fournisseur accepte que l'institution financière puisse exercer ses droits conformément aux modalités de l'accord du fournisseur pour lesquelles l'institution financière est un tiers bénéficiaire, au nom propre de l'institution financière, sans le consentement du fournisseur, et sans jonction du fournisseur dans toute procédure. Ces droits sont irrévocables et restent en vigueur après la date d'expiration ou de résiliation du présent accord. Par ailleurs, l'institution financière accepte que l'acheteur est un tiers bénéficiaire (i) des engagements pris par l'institution financière d'acheter les obligations de paiement et les créances, associées, conformément à la présente convention d'achat de créances ; et (ii) de l'accord de l'institution financière qui, dès le transfert d'une obligation de paiement, prévoit le prolongement de la date maturité du fournisseur à la date de maturité de l'acheteur. Processus [0078] Les processus associés au système SCF 10 se présentent comme suit. [0079] 1. Traitement des obligations de paiement [0080] a. Le traitement des obligations 12 commence généralement lorsque le système 10 reçoit les données d'obligation A/P pour une communauté de clients du Système SCF 10. Les données A/P sont reçues directement d'un acheteur 106 dans un format électronique, de préférence, à partir d'un système des comptes créditeurs. Conformément au CA, le reçu des 51 données d'obligation A/P du système établit une obligation de paiement (« Bon de commande » d'une valeur égale à la valeur de l'obligation A/P téléchargée (peut être inférieure au montant imputable aux notes de crédit) et une date de maturité qui est soit la date de maturité du fournisseur, soit les dates de maturité de l'acheteur à partir des données d'obligation téléchargées, selon le cas. L'acheteur 106 est tenu par l'obligation contractuelle de payer au fournisseur ou au cessionnaire, la totalité de la valeur de l'obligation de paiement, à la date d'échéance en vigueur ; c'est-à-dire que le bon commande est défini en termes de date et de valeur, et dans la plupart des cas, l'acheteur 106 ne peut changer ces paramètres une fois le bon de commande établi dans le système SCF 10. Bien que non nécessaire au fonctionnement du système, la transaction conclue entre les parties suppose que le Bon de commande soit associé aux créances du fournisseur qui correspondent au compte créditeur de l'acheteur, et comme susmentionné, les données d'obligation A/P peuvent identifier les factures du fournisseur qui sous-tendent l'obligation A/P afin que le fournisseur puisse rapprocher l'obligation de paiement du système SCF à sa créance. De plus, les créances sous-jacentes sont censées être associées à la date de maturité du fournisseur en ce sens que la date de maturité du fournisseur est une période de temps requis par contrat ou statut après la date de la facture ou des factures, incluant la créance [0081] b. Le système 10 associe le bon de commande à un fournisseur 108. Lorsque le prestataire de services introduit l'acheteur dans le système 10, le système 10 attribut un numéro d'identification à l'acheteur. L'acheteur, en retour, introduit ce numéro d'identification dans chaque obligation A/P qu'il télécharge sur le système 10. Dès la réception d'une obligation A/P, le système procède d'abord à une vérification afin de s'assurer que le numéro d'identification correspond à l'acheteur enregistré dans le système. Si tel est le cas, ceci définit la communauté des clients, dans une application préférée (bien que ceci ne soit pas une disposition nécessaire), un acheteur ne peut appartenir qu'à une seule communauté de clients. Parallèlement, le système 10 vérifie si le fournisseur identifié dans l'obligation téléchargée est un fournisseur enregistré dans le système 10 pour cette communauté. Les fournisseurs reçoivent également des numéros d'identification lorsque l'animateur de la communauté les introduit dans le système 10. Cependant, les acheteurs attribuent aussi les numéros d'identification aux fournisseurs et les fournissent au système 10. Tel que mentionné dans la présente, un acheteur peut disposer de plusieurs programmes d'acheteurs au sein d'une communauté donnée, et un fournisseur peut appartenir à plusieurs programmes d'acheteurs. Ainsi, étant donné qu'il est possible au même acheteur et au même fournisseur d'effecteur des transactions commerciales dans le cadre de plusieurs programmes, le système (dans cette application et non nécessairement dans toutes les applications) exige que le fournisseur attribue un numéro d'identification différent pour chaque fournisseur et selon chaque programme d'acheteurs au sein duquel l'acheteur et le fournisseur effectuent des transactions commerciales. À titre d'exemple, si l'acheteur et le fournisseur effectuent des transactions commerciales dans le cadre de deux programmes d'acheteurs, l'acheteur attribue au fournisseur deux numéros d'identification. L'acheteur introduit le numéro d'identification respectif du fournisseur dans les données d'obligation A/P téléchargées pour les obligations à ce fournisseur, et la combinaison du numéro d'identification de l'acheteur et de celui du fournisseur permet au système d'identifier le programme d'acheteurs auquel une obligation téléchargée donnée appartient. Dans le même temps, le système peut permettre à un acheteur 53 d'avoir plusieurs programmes d'acheteurs avec le même fournisseur, en utilisant le même numéro d'identification, lorsque les programmes d'acheteurs diffèrent en devise. Dans une telle application, la combinaison ID de l'acheteur, ID du fournisseur et devise identifie le programme d'acheteurs. Si le paiement ne correspond pas un acheteur ou à un fournisseur, ou s'il y a un problème dans le format d'enregistrement ou les champs de données, une exception est créée et soumise à l'animateur de communauté et/ou à l'acheteur 106 pour une évaluation approfondie. [0082] 2. Traitement des transactions commerciales [0083] Une transaction commerciale comprend une ou plusieurs obligations. Une transaction commerciale commence comme une offre de vente du fournisseur et se présente comme une offre de l'acheteur à l'institution financière (pour les besoins de convenance, cette réflexion peut décrire l'offre comme « l'offre de vente », quelle soit initiée par le fournisseur ou l'institution financière). Le but d'une transaction commerciale est de transférer à l'institution financière une ou plusieurs obligations ayant des dates de paiement ultérieures à un taux réduit afin de permettre au fournisseur d'avoir immédiatement accès aux fonds. Une transaction commerciale comprend une offre de vente et une acceptation de cette offre. [0084] a. Le traitement des transactions commerciales 14 s'opère au quotidien, pour les obligations téléchargées. Le système 10 cherche à vérifier si le fournisseur 108 dispose des critères d'auto-avancement fixés pour l'acheteur 106 en rapport avec les obligations de paiement sous-jacentes. Si les règles d'auto-avancement sont fixées, une offre de vente est créée et soumise automatiquement à travers le système 10. Autrement dit, ou en plus des offres d'auto-avancement, le fournisseur 108 crée manuellement une offre de vente, à l'aide de la fonctionnalité du système 10. Le fournisseur 108 initie les offres de vente, susceptibles de contenir une ou plusieurs obligations que l'acheteur 106 doit au fournisseur. À supposer, cependant, que le programme d'acheteurs concerné est défini pour l'auto-avancement et que l'option de la « date d'échéance » (traitée ci-dessous) est en vigueur, si une obligation de paiement a été créée dans le système 10 et que le fournisseur ne l'a pas offerte à la vente à la fin du deuxième jour ouvrable avant la date de maturité du paiement de l'obligation du fournisseur, le système crée automatiquement une offre de vente pour cette obligation de paiement et présente une offre d'achat correspondante à l'institution financière un jour avant la date de maturité de l'obligation du fournisseur (ou, si ce jour n'est pas un jour ouvrable, le premier jour ouvrable suivant), sans attendre aucune autre action du fournisseur. Ainsi, toutes les obligations de paiement qui demeurent non commercialisées et impayées, un jour avant (ou, dans le cas où il ne s'agit pas d'un jour ouvrable, le premier jour ouvrable suivant) leurs dates de maturité respectives sont offertes à la vente, indépendamment de toute action du fournisseur. [0085] Dans un paramétrage, si l'échéance du fournisseur n'est pas un jour ouvrable valable défini par le système (dans le pays de l'acheteur ou de l'institution financière, ou dans un autre paramétrage, également le pays du fournisseur), le système modifie automatiquement l'échéance vers le jour ouvrable valable suivant le plus proche. Selon cette échéance du fournisseur, le système définit initialement l'heure de l'offre comme une heure du jour précédant l'échéance du fournisseur, plus tôt qu'une heure limite journalière prédéfmie. 55 Toutefois, si la date de l'offre initialement définie tombe sur un jour qui n'est pas un jour ouvrable valable dans le pays de l'acheteur ou le pays de l'institution financière (ou, dans un autre paramétrage, également le pays du fournisseur), le système modifie automatiquement la date de l'offre vers une date qui est un jour ouvrable valable dans ces pays. L'heure de l'offre à cette date reste la même. Dans un paramétrage encore plus avancé, le système vérifie la date de l'offre uniquement vis-à-vis des jours ouvrables valables dans le pays de l'institution financière, et en cas de conflit, modifie la date de l'offre vers un jour qui est un jour ouvrable valable dans le pays de l'institution financière. En conséquence, dans ces paramétrages, le système déplace soit la date d'échéance du fournisseur soit la date de l'offre si l'une d'elles tombe sur un jour qui n'est pas un jour ouvrable valable et déplace les deux dates si elles tombent toutes deux sur de tels jours. En fonction de la Convention d'achat de créances, l'institution financière accepte d'acheter de telles obligations. [0086] L'heure de l'offre, c'est-à-dire l'heure après laquelle le système crée et fait automatiquement une offre de vente pour de telles obligations de paiement, est reliée à la date d'échéance du fournisseur de l'obligation de telle sorte que le marché puisse avoir lieu, et que le paiement soit effectué au fournisseur avant la fin de la journée ouvrable le jour même de l'échéance du fournisseur. L'heure à laquelle il faut effectuer l'offre de vente (qui peut être une période de temps, p. ex. un jour ou un intervalle de jours donnés dans le calendrier, ou une limite d'heure précise dans un jour donné) que le système sélectionne antérieurement à la date d'échéance du fournisseur peut être considérée comme l'heure de l'offre. La relation entre l'heure de l'offre et l'échéance du fournisseur (c'est-à-dire la période prédéterminée) est telle que le système 10 effectue l'offre de vendre l'obligation de paiement à l'institution financière suffisamment tôt pour permettre à l'institution financière d'accepter l'offre selon un délai prédéterminé d'acceptation pour permettre ainsi au système 10 d'exécuter les instructions afin de payer le montant du fournisseur net suffisamment tôt pour que les instructions effectuent le paiement du montant du fournisseur net avant la fin de la journée ouvrable de l'échéance du fournisseur, ou avant l'échéance du fournisseur. Dans le paramétrage actuellement décrit, on suppose que l'institution financière va accepter une offre le même jour que l'offre a été faite et, dans un paramétrage, on s'attend à ce qu'elle l'accepte entre trois et six heures après avoir fait l'offre. De plus, on peut supposer que l'accord de paiement du montant du fournisseur net peut avoir lieu pendant la nuit dans de nombreux pays. Ainsi, dans ce paramétrage, si une obligation de paiement n'est pas offerte à la vente avant le jour précédant l'échéance du fournisseur (on suppose que ce jour est un jour ouvrable valable, et si ce n'est pas le cas, le prochain jour ouvrable valable), le système propose alors automatiquement de vendre l'obligation de paiement à l'institution financière plus tôt ce jour-là, dans un des paramétrages environ trois à six heures précédant l'heure avant laquelle il faudrait soumettre des instructions de paiement à un système de traitement de paiement afin de régler le paiement au fournisseur avant la fin de la journée ouvrable suivante (p.ex. l'échéance du fournisseur). Dans l'un des paramétrages, le système est configuré de telle sorte que si une obligation de paiement n'est pas offerte à la vente avant la fin de la journée ouvrable deux jours avant l'échéance de son fournisseur, elle est automatiquement offerte à la vente pendant une période de temps entre 7:00 et 7:30 le matin du jour suivant (de nouveau, en supposant que le jour est un jour ouvrable valable, sinon les jours sont déplacés vers les prochains jours ouvrables valables). Ainsi, pour un réglage à 7:00 du matin, l'heure de l'offre est 7:00 du matin le jour ouvrable 57 valable précédant l'échéance du fournisseur. Le système exécute les instructions de paiement, par exemple, dans une période de temps approximativement comprise entre 11:00 et 15:00 le même jour. En supposant un exemple de 15:00, l'heure avant laquelle on suppose que les institutions fmancières accepteront les offres faites à l'heure de l'offre est 15:00, c'est-à-dire le délai d'acceptation. Toutefois, il convient de préciser que les heures spécifiques sélectionnées peuvent varier en fonction des usages bancaires et de règlement locaux, et que dans les paramétrages actuellement décrits, les institutions financières peuvent définir les délais d'acceptation. [0087] Il convient également de préciser que, d'une manière générale, ces délais peuvent varier. Par exemple, pour permettre la possibilité à l'institution financière d'accepter une offre au-delà de l'heure limite journalière du jour de l'offre, le délai présumé pour que l'institution financière accepte l'offre pourrait être étendu afin d'expirer à l'heure limite journalière du jour suivant le jour où l'offre est effectuée. En supposant que l'heure prédéterminée pour que le système 10 exécute les instructions de paiement fasse toujours parti du même jour que celui où l'offre est faite (bien qu'il convienne de préciser que ceci peut varier, p. ex. vers le jour suivant le jour d'acceptation), l'heure de l'offre pourrait être considérée à n'importe quelle heure du jour deux jours avant l'échéance du fournisseur. [0088] À l'inverse, lorsque les paiements peuvent être réglés le même jour (p.ex. par virement bancaire ou dans les pays dans lesquels les instructions de paiement électronique normales sont réglées le même jour), le système peut être configuré de telle sorte que les offres sont auto-proposées aux institutions financières au début de la date d'échéance (dans ce cas, la date d'échéance du fournisseur). Le système suppose que les institutions financières vont probablement accepter les offres rapidement, et qu'elles le feront avant l'heure limite journalière le jour où l'offre est faite, pour autant que l'offre soit faite suffisamment tôt dans la journée pour accorder une confiance à la probabilité que l'institution financière acceptera l'offre avant l'heure limite journalière de ce jour, et pour autant que l'heure limite journalière soit établie suffisamment tôt dans la journée pour permettre au règlement du paiement au fournisseur (p.ex. pour permettre au paiement d'être reçu par le compte bancaire du fournisseur) d'avoir lieu ce même jour. Dans cet exemple, si une obligation de paiement a été créé dans le cadre de système 10, mais que le fournisseur ne l'a pas offerte à la vente avant la fin de la journée ouvrable précédant la date d'échéance du fournisseur, le système présente alors automatiquement l'obligation de paiement à l'institution financière à la date d'échéance du fournisseur, p.ex. approximativement à 9:00 du matin. Pour toutes les obligations de paiement ayant des offres acceptées avant 15:00 à la date d'échéance du fournisseur, le système exécute les instructions appropriées pour effectuer le paiement au fournisseur avant la fin de la journée ouvrable de l'échéance du fournisseur. Ainsi, dans ce paramétrage, l'heure de l'offre est 9:00 du matin, et le délai d'acceptation est 15:00, le jour de l'échéance du fournisseur. [0089] L'hypothèse concernant la séparation entre l'heure de l'offre et le délai d'acceptation peut être faite comme partie intégrante de la programmation du système 10, de telle sorte que système 10 détermine toujours l'heure de l'offre dans la même relation (p.ex. un jour ouvrable avant, ou à une heure donnée du jour ouvrable précédent) à l'échéance du fournisseur, ou ces hypothèses peuvent être faites sur une base de programme acheteur de telle 59 sorte que la relation heure de l'offre/date d'échéance du fournisseur puisse être établie dans un programme acheteur par la base du programme acheteur. [0090] Une offre de vente est l'état initial du marché. Elle peut comprendre plusieurs obligations de paiement avec des échéances variées. Pour les obligations de paiement ayant des échéances de fournisseur et d'acheteur, l'échéance de l'offre de vente (et de l'obligation de paiement transférée en résultant) est l'échéance de l'acheteur. Si les obligations de paiement multiples sont échangées un jour précis parce qu'elles arrivent à leurs échéances de fournisseur (et auront par conséquent typiquement la même échéance d'acheteur), le système 10 crée une offre de vente unique qui comprend ces multiples obligations de paiement. Dans le paramétrage actuellement décrit, les obligations de paiement proposées manuellement à la vente ne sont pas regroupées avec les obligations de paiement proposées automatiquement mais, dans un autre paramétrage, les obligations de paiement proposées manuellement et automatiquement sont regroupées. De plus, les obligations de paiement pourraient être proposées individuellement, chacune correspondant à une offre de vente respective. L'offre de vente indique le montant que le fournisseur 108 recevra pour le paiement de l'obligation, ainsi que les commissions et les frais associés au marché. La soumission d'une offre de vente a pour résultat la création d'une offre d'achat qui devient ensuite visible pour l'institution financière associée. [0091] b. Après la création d'une offre de vente, le SCF système 10 distribue l'offre de vente en tant qu'offre d'achat à (aux) institution(s) fmancière(s) appropriée(s) 110, comme décrit plus bas, pour une acceptation sur la base d'une méthode sélectionnée préalablement pour ce programme acheteur de l'acheteur (tel que décrit de manière plus détaillée par la suite). Lorsque les offres d'achat sont créées, elles ont le statut de « demandé ». Lorsque l'offre d'achat est acceptée par l'institution financière, le statut devient « accepté automatiquement » ou « accepté manuellement », en fonction de la méthode selon laquelle l'acceptation a lieu, et lorsque toutes les obligations de paiement du marché ont été payées, le statut devient « échu ». L'acceptation du marché a lieu lorsque 1' offre d'achat a été acceptée par 1' institution financière. L'acceptation de l'offre d'achat peut être un processus manuel ou automatisé en fonction des règles d'acceptation automatique et d'autres facteurs, tels que la limite de crédit disponible/ouverte de l'institution financière. Dans un autre paramétrage, si l'une des offres d'achat envers une institution financière est une offre automatique basée sur des obligations de paiement arrivées à leur échéance de fournisseur, le système accepte automatiquement ces offres d'achat le même jour que leur proposition, en vertu de la Convention de l'institution financière et de la Convention d'achat de créances. Ainsi, dans un tel paramétrage, toutes les offres de vente sont acceptées par les institutions financières auxquelles elles sont soumises ou avant le jour précédant l'échéance du fournisseur, soit par une acceptation manuelle de l'institution financière, une fonction d'acceptation automatique définie pour l'institution fmancière ou automatiquement pour le compte de l'institution financière afin de garantir le paiement du fournisseur à l'échéance du fournisseur. [0092] c. L'échéance de l'acheteur pour chaque obligation de paiement de l'offre de marché initie le paiement au bénéficiaire (institution financière 110, si l'offre est acceptée, ou fournisseur 108, si l'offre n'est pas acceptée ou si l'échéance de l'acheteur arrive avant que l'obligation de paiement ne soit échangée) par l'acheteur 106 pour l'ensemble du montant de l'obligation de paiement. Les paiements de l'acheteur 106 au bénéficiaire (soit à l'institution 61 financière 110 par l'acheteur 106, soit au fournisseur 108 par l'institution financière 110 ou l'acheteur 106) sont groupées et réglées à la fin de chaque jour ouvrable. Puisque les institutions financières acceptent généralement (mais pas nécessairement) les offres de l'acheteur le même jour que leur proposition, et puisque, dans ce paramétrage, le système 10 génère automatiquement des offres d'achat le jour précédant l'échéance du fournisseur d'une obligation de paiement, cela signifie que le fournisseur est payé à la date d'échéance du fournisseur. Comme mentionné plus haut, les informations nécessaires sont traitées à travers le compte de compensation bancaire du programme acheteur pour faciliter le paiement. [0093] d. Lorsqu'une banque 18 effectue un paiement pour le compte d'un quelconque participant au SCF système 10, la banque émet des notifications d'avis de paiement au SCF système 10 concernant les détails de paiement. Les notifications d'avis de paiement sont composées à partir de l'ANSI 820s et ANSI 824, ou de formats similaires, qui sont retransmis au SCF système 10, où elles sont enregistrées et communiquées aux parties concernées. [0094] e. Une fois qu'une institution financière accepte une offre de vente, le fournisseur 108 reçoit une notification selon laquelle l'offre de vente a été acceptée, et le statut des offres d'achat et de vente est devenu accepté. Suite à l'acceptation, l'institution financière est tenue de payer au fournisseur le montant de la valeur du marché contenu dans l'offre de vente. [0095] 3. Traiter le paiement [0096] a. Le traitement des paiements 16 a lieu une fois que l'institution financière a accepté l'offre de vente. À ce stade, l'institution fmancière 110 est tenue contractuellement par la Convention d'achat de créances à payer au fournisseur 108 le montant de la valeur de l'offre du marché. Comme spécifié ici, et comme l'apprécieront les hommes du métier, l'acte qui constitue une « acceptation » peut être différent pour différentes institutions financières et ce qui a été convenu par les parties dans la Convention FI et le RPA. L'acceptation de l'offre d'achat initie le paiement au fournisseur 108 et le transfert de l'obligation, pour que l'acheteur 106 paie à l'institution financière l'ensemble de la valeur de toutes les obligations de paiement de l'offre d'achat. [0097] b. Le SCF système 10 fournit les informations nécessaires de l'institution financière 110, du fournisseur 108, du fournisseur de service et du compte de la communauté aux banques 18 pour effectuer les transactions financières nécessaires afin de conclure le marché. Le fournisseur 108 reçoit la valeur du marché de l'offre d'achat et le compte bancaire spécifié de l'institution financière 110 est débité de la valeur du marché, ainsi que tous les frais associés au marché, tels que décrits ici. Le fournisseur de service 20 et le gestionnaire de communauté 120 reçoivent également un paiement pour les frais évalués, s'il y a lieu. Les comptes de compensation sont utilisés pour transférer tous les fonds. Des frais additionnels peuvent également être payés aux autres partenaires financiers tels que le courtier ou les codistributeurs (il s'agit d'exemples non exhaustifs). [0098] c. L'échéance de l'acheteur pour chaque obligation de paiement du marché initie le paiement à l'institution financière 110 de l'intégralité du montant de l'obligation. Comme décrit plus haut, les informations nécessaires sont transmises aux banques 18 pour faciliter le paiement. [0099] d. Lorsque les paiements sont faits par la banque 18 pour le compte de l'un des participants au SCF système 10, la banque envoie des notifications d'avis de paiement au SCF 63 système 10 concernant les détails du paiement. Les notifications d'avis de paiement ANSI 820s et ANSI 824, ou un format similaire, sont retransmises au SCF système 10, où elles sont enregistrées et communiquées aux parties concernées. [00100] e. Les fournisseurs 108 qui ne choisissent pas d'échanger leurs obligations de paiement, lorsque l'échéance de l'acheteur pour de telles obligations a lieu avant l'échéance du fournisseur de l'obligation, sont également payés par le SCF système 10. Dans de tels cas, le transfert des fonds a lieu exactement comme spécifié plus haut, et le fournisseur 108 reçoit l'intégralité du montant de l'obligation de paiement par le compte bancaire de l'acheteur désigné à l'échéance de l'acheteur. Un compte de compensation est utilisé pour transférer ou payer tous les fonds. Comme décrit plus haut et dans ce qui suit, le concept de paiement des fonds inclut le versement effectif ou le transfert des fonds ou la transmission des instructions ou d'une requête à l'institution financière ou à la banque concernée pour verser ou transférer des fonds à partir d'un compte spécifique vers un autre pour un montant spécifique et à une date/heure spécifique. [00101] La figure 1C illustre le fonctionnement du SCF système 10 en relation avec une transaction non fondée entre l'acheteur 106 et le fournisseur 108. À l'étape 1, le fournisseur 108 fournit des biens ou des services après demande de l'acheteur 106, typiquement à travers l'émission par l'acheteur d'un bon de commande. À l'étape 2, après avoir reçu un bon de commande, le fournisseur 108 accepte le bon de commande et fournit les biens ou les services demandés. Après avoir fourni les biens, le fournisseur 108 génère et délivre une facture à l'acheteur 106. Ces étapes ont lieu à l'extérieur du SCF système 10. Elles ne s'effectuent pas obligatoirement dans cet ordre. Elles n'incluent pas nécessairement des bons de commande ou des factures. [00102] L'étape 3 fait référence au téléchargement des informations de comptes créditeurs à partir du système de comptes créditeurs de l'acheteur 106 vers le SCF système 10. Comme relevé plus haut, une obligation de paiement dans le système A/P de l'acheteur est une facture du fournisseur approuvée de l'acheteur 106 qui a été entrée dans le système de comptes créditeurs de l'acheteur. Une fois que les biens ont été fournis ou qu'ils sont en chemin, l'acheteur 106 peut choisir de télécharger des données correspondant à une obligation de paiement au SCF système 10. Le téléchargement d'obligations de paiement est volontaire ; l'acheteur 106 n'est soumis à aucune obligation de saisir une obligation de paiement. Également, comme mentionné plus haut, le téléchargement de données sur les obligations de paiement crée une obligation de paiement irrévocable, en vertu de la CA pour cette somme d'argent que l'acheteur 106 accepte de payer au fournisseur 108 ou son cessionnaire à l'échéance de l'acheteur. L'acheteur 106, conformément à la CA, accepte que l'obligation de paiement ne puisse pas changer avec le temps, excepté avec l'émission de notes de crédit. Si l'acheteur 106 a une raison de réduire le montant dû au fournisseur 108, l'acheteur peut introduire des notes de crédit dans le SCF système 10, en précisant le montant (le montant de la note de crédit) qui devrait être réduit du montant de l'obligation de paiement, avec une exception importante, en relation avec les notes de crédit reçues après la vente de l'obligation de paiement, comme discuté ci-dessous. [00103] Dans un paramétrage préféré, les comptes créditeurs peuvent être téléchargés depuis le système ERP de l'acheteur, avec une ou plusieurs déductions. Ainsi, par exemple, 65 supposons que le système A/P de l'acheteur a une facture de $100 dollars venant d'un fournisseur mais qu'avant de télécharger les données sur le système 10, l'acheteur est conscient que le montant de la facture devrait être réduit de $5. L'acheteur pourrait mentionner les $5 comme une déduction sur le montant de $100, et lorsque les données sont téléchargées sur le système 10, celui-ci définit une obligation de paiement d'un montant net de $95. Les déductions ne peuvent pas être introduites après téléchargement des données A/P, pour une obligation de paiement donnée. Les déductions peuvent également être introduites pour des notes de crédit. Ainsi, par exemple, une note de crédit de $100 peut être téléchargée avec une déduction de $5, ce qui aura pour résultat une note de crédit de $95. [00104] Fondamentalement, l'obligation de paiement créée suivant la CA lorsque l'acheteur publie une obligation de paiement suivant le SCF système n'est pas un compte débiteur. L'obligation de paiement crée une obligation pour l'acheteur 106 de payer une certaine somme (le montant certifié) à une certaine date (l'échéance de l'acheteur). L'acheteur 106 a une obligation irrévocable et contraignante de payer le montant certifié au fournisseur 108 ou au cessionnaire concerné à l'échéance de l'acheteur. L'acheteur 106 accepte que sa soumission des données de l'obligation de paiement au SCF système 10 constitue l'accord irrévocable de l'acheteur de payer le montant certifié au fournisseur 108 ou à toute personne à qui l'obligation de paiement a été vendue, s'il y a lieu, à l'échéance de l'acheteur. L'acheteur 106 convient également avec le gestionnaire de communauté 120 que le montant certifié peut être viré par le gestionnaire à partir d'un compte de paiement de l'acheteur 40 à l'échéance de l'acheteur, sans approbation supplémentaire de l'acheteur. Ces accords par l'acheteur 106 sont fait avec le gestionnaire de communauté 120, et non pas le fournisseur 108, mais les droits de paiement sont exécutoires par le fournisseur 108 ou l'institution financière 110, s'il y a lieu. De tels droits de tierce partie n'existent pas dans les comptes débiteurs. De plus, l'acheteur 106 a, généralement, la possibilité de lancer des réclamations contre un compte débiteur, mais l'acheteur 106 ne dispose pas d'un tel droit en relation avec le paiement du montant certifié à moins d'être crée indépendamment, comme discuté ci-dessous. Finalement, le montant de l'obligation de paiement n'est pas nécessairement le montant du compte débiteur effectif sous-jacent mais il est, de préférence, égal au compte débiteur. [00105] Dans les paramétrages décrits actuellement, une obligation de paiement créée en suivant la CA avec le téléchargement des données A/P par l'acheteur est une obligation pour l'acheteur 106 séparée de l'obligation des comptes créditeurs (comptes débiteurs pour le fournisseur) découlant de la transaction entre l'acheteur et le fournisseur à l'extérieur du SCF système. Lors de la création de l'obligation de paiement, et suivant la Convention du fournisseur, le fournisseur 108 accepte que la création et le paiement de l'obligation de paiement ou le brouillon soit une compensation (du montant de la somme certifiée) sur le compte débiteur à laquelle elle se réfère. Le fournisseur 108 accepte expressément, suivant la Convention du fournisseur, que la création et le paiement d'une obligation de paiement ne supprime aucun des droits de l'acheteur 106 contre le fournisseur dans la transaction sous-jacente. Finalement, l'acheteur 106 accepte expressément dans la CA que le fournisseur 108 ne supprime aucun des droits à être payé des montants du compte débiteur sous-jacent à hauteur du montant certifié. [00106] Le montant certifié dans le cadre de l'obligation de paiement découlant d'une obligation d'acheteur originellement publiée par l'acheteur 106 est le montant brut de 67 l'obligation de paiement moins la somme de tous les montants de déduction et de notes de crédit attribuables au fournisseur 108 qui (i) n'ont pas été appliqués sur de telles obligations de paiement précédentes (ii) sont publiées avant la date et l'heure auxquelles un fournisseur publie (manuellement ou automatiquement) une offre irrévocable pour financer l'obligation de paiement concernée. Ainsi, le montant certifié est déterminé au plus tôt (a) par la date et l'heure à laquelle le fournisseur 108 publie une offre irrévocable pour financer l'obligation de paiement ou (b) l'échéance de l'acheteur. Si le fournisseur 108 a déjà publié une offre irrévocable lorsque la note de crédit est publiée, le montant de la note de crédit concernée sera appliqué à d'autres obligations de paiement existantes ou futures, s'il y a lieu, pour lesquelles une offre irrévocable n'a pas été publiée. [00107] Suivant la Convention du fournisseur et le RPA, le fournisseur 108 peut faire une offre irrévocable pour vendre à l'institution financière 110 tous les droits, titres et intérêts du fournisseur relatifs à une ou plusieurs obligations de paiement qui sont publiées sur le SCF système 10, libre et quitte de toute réclamation adverse pour qu'une telle offre irrévocable demeure en vigueur jusqu'à la première des éventualités suivantes (i) l'institution financière 110 exerce son droit à acheter l'obligation de paiement (manuellement, via acceptation automatique ou (dans un autre paramétrage) automatiquement par le système le jour précédant l'échéance du fournisseur), (ii) l'échéance de l'acheteur, ou (iii) une date et une heure spécifiées dans le document fourni par le gestionnaire de communauté 120 pour le SCF système 10 (ce paramètre peut être désactivé ou simplement pas utilisé dans un paramétrage où il est souhaité que toutes les obligations de paiement soient négociables avant l'échéance du fournisseur). Le système définit également un paramètre de durée limite pour les créances commerciales. L'institution financière définit, généralement, ce paramètre comme un nombre d'heures après avoir fait l'offre au cours duquel l'institution financière peut accepter l'offre. Si l'institution financière n'accepte pas l'offre pendant cet intervalle de temps, l' (les) obligation(s) de paiement sous-jacente(s) à l'offre est (sont) à nouveau disponible pour un marché. À nouveau, dans un paramétrage, ce paramètre peut être désactivé ou non utilisé lorsqu'il est souhaité que toutes les obligations de paiement soient négociables avant l'échéance du fournisseur. [00108] Dans les paramétrages décrits actuellement, les obligations de paiement affichées dans le SCF système 10 découlent des données A/P de l'acheteur qui sont automatiquement téléchargées en groupe sans intervention manuelle. Dans la plupart des situations, une obligation de paiement commence comme une sortie depuis le système de comptes créditeurs de l'acheteur 106 et est traduite directement dans un format qui peut être téléchargé dans le SCF système 10. Il convient d'interpréter que le système A/P de l'acheteur est probablement un système de planification de ressource d'entreprise (ERP) qui peut avoir certaines capacités à générer des données depuis le système. Pour chaque obligation de paiement de l'acheteur, le système 10 nécessite que le système ERP de l'acheteur identifie au moins l'acheteur (par numéro d'ID), le montant total de l'obligation, le fournisseur (par numéro d'ID) et les échéances du fournisseur et de l'acheteur. Comme observé ci-dessus, les données A/P de l'acheteur peuvent inclure des données décrivant des factures qui comprennent l'obligation de paiement de l'acheteur. Le système SCF n'utilise pas de données de facture spécifiques pour effectuer les transactions, mais le système acquiert et fournit de telles données en tant que contenu posté par les membres pour permettre au fournisseur de concilier les 69 obligations de paiement avec les factures dans le système ERP de comptes débiteurs du fournisseur. Les données particulières comprises dans les données de la facture peuvent par conséquent varier, bien qu'elles comprennent généralement le numéro de facture du fournisseur, la date d'émission de la facture et l'échéance de la facture. Toutefois, indépendamment du contenu des données particulières du système ERP de l'acheteur, le système ERP de l'acheteur peut être configuré pour collecter les données d'obligation de l'acheteur d'une manière prédéterminée, par exemple après une sélection manuelle de l'acheteur lorsque celui-ci fait fonctionner son système ERP, ou automatiquement lors d'un événement donné comme la réception d'une facture d'un fournisseur et l'approbation de la facture dans le système ERP. Le système ERP peut être configuré pour collecter les données nécessaires et optionnelles à partir d'une ou plusieurs factures et placer les données dans un dossier pour un téléchargement groupé vers le système 10. Par exemple, lorsque le paiement au fournisseur est requis par contrat ou statut dans un certain intervalle de temps à partir de la date de la facture, le système ERP de l'acheteur peut être configuré pour déterminer l'échéance de l'acheteur à partir de la date de la facture sur la base d'un accord entre l'acheteur et le fournisseur. Avec un format connu de données ERP, l'opérateur du système 10 peut configure le système 10 pour recevoir les données et les mettre en corrélation avec les informations d'obligation de paiement décrites ici. Les données peuvent être échangées par divers moyens possibles, par exemple un protocole de transfert de fichier vers ou en provenance de serveurs FTP du système 10 ou de l'acheteur, respectivement. Une fois que le SCF système reçoit les données A/P définissant une obligation de paiement, la base de données du système crée un rapport de base de données respectif pour chaque obligation contenant les informations, y compris le contenu posté par les membres, de l'obligation. [00109] Le SCF système 10 est destiné à avoir que peu d'effet possible sur la relation existant entre l'acheteur 106 et le fournisseur 108. Toutefois, l'introduction d'une obligation de paiement change la relation existante entre l'acheteur 106 et le fournisseur 108 de deux manières. La CA permet spécifiquement au fournisseur 108 et au cessionnaire (c'est-à-dire, l'institution financière 110) de compter sur les deux exigences énoncées ci-dessous. [00110] Premièrement, en introduisant une obligation de paiement, l'acheteur 106 accepte (suivant la CA) de payer une somme d'argent spécifiée, uniquement soumise à une limitation qui pourrait être énoncée dans la CA et indépendante de réclamations ou de défenses qui pourraient sinon être à disposition de l'acheteur eu égard à une obligation de comptes créditeurs. Excepté pour ce qui a été énoncé dans une note de crédit (telle que fournie dans la CA), l'acheteur 106 accepte avec le gestionnaire de communauté 120 que l'argent doit être payé. Parce que l'introduction de notes de crédit après le transfert d'une obligation de paiement n'affecte pas l'obligation de payer cette obligation en particulier, et parce que de telles transactions ont normalement lieu rapidement après introduction de l'obligation de paiement, l'acheteur 106 ne sera fréquemment pas en mesure de lancer une réclamation de note de crédit contre l'obligation de paiement à laquelle se réfère la plainte. Toutefois, le SCF système 10 permet aux notes de crédit de lancer de futures obligations de paiement. Ceci signifie que le SCF système 10 peut être utilisé efficacement avec des notes de crédit en particulier lorsque l'acheteur 106 et le fournisseur 108 ont une relation continue entre eux, de telle sorte que les paiements futurs seront dus au fournisseur. Les accords ne sont pas censés 71 affecter les droits sous-jacents de l'acheteur 106 et du fournisseur 108 en lien avec la fourniture de biens et de services. Tous droits ou obligations entre ces parties associés à une mauvaise exécution, des droits de garantie et ainsi de suite restent, plutôt, intacts. [00111] Deuxièmement, en introduisant une obligation de paiement, l'acheteur 106 paiera le montant de l'obligation de paiement (moins les montants de note de crédit) à une date spécifique : l'échéance de l'acheteur. Ceci empêche l'acheteur 106 de reporter des paiements au-delà de leur date d'échéance, comme il a été convenu de manière indépendante entre l'acheteur et le fournisseur. Comme observé ci-dessus, les échéances de l'acheteur et du fournisseur de l'obligation de paiement A/P téléchargée vers le système 10 sont de préférence établies automatiquement par le système ERP de l'acheteur en devenir, ou à baser sur la date d'une ou plusieurs factures comprenant l'obligation de paiement A/P. Toutefois, comme il a également été observé ci-dessus, l'établissement de l'échéance de paiement d'obligation de l'acheteur, et plus généralement l'acceptation par le système ERP de l'acheteur, a lieu en dehors du système 10, et le système 10 n'essaie pas de confirmer la validité de l'échéance. Par conséquent, les données téléchargées depuis le système ERP de l'acheteur comprennent de préférence le contenu posté par les membres qui inclut les factures sous-jacentes, de telle sorte que le fournisseur peut examiner l'obligation de paiement et confirmer qu'elle est conforme aux attentes du fournisseur. [00112] À l'étape 4, une fois qu'une obligation de paiement a été introduite dans le SCF système 10, le système présente cette obligation de paiement au fournisseur 108. Dans un paramétrage, la présentation a lieu lorsque le fournisseur se connecte au système en rendant l'obligation de paiement visible par le fournisseur via l'interface utilisateur du fournisseur du système. Toutefois, il ne s'agit pas des seuls moyens avec lesquels la présentation peut avoir lieu. En général, une présentation fait référence au fait de rendre une information accessible, par exemple, par des écrans visuels ou d'autres moyens électroniques. Lorsqu'une fonctionnalité d'avance automatique génère automatiquement des offres, p.ex. sur la base d'une règle de date d'échéance, le fournisseur peut ne pas avoir la possibilité de voir ou d'accéder à l'obligation de paiement avant qu'une offre à une institution financière ne soit faite, mais l'obligation de paiement est pourtant présentée au fournisseur parce que l'obligation de paiement est rendue accessible au fournisseur. [00113] À l'étape 5, à l'échéance de l'acheteur ou avant cette date, l'acheteur 106 s'assure qu'il y ait assez d'argent sur le compte 40 de l'acheteur pour couvrir l'obligation de paiement. Un acheteur a la possibilité d'utiliser un « compte soldé » pour le compte de paiement 40 de l'acheteur qui transfère automatiquement les fonds vers le compte 40 à hauteur du montant certifié et lorsque cela est nécessaire. [00114] À l'étape 6, le jour de l'échéance de l'acheteur (lorsque l'échéance de l'acheteur est antérieur à celle du fournisseur), le SCF système 10 génère automatiquement une instruction de transfert électronique de fonds à la banque de l'acheteur 106, ordonnant à la banque de transférer le montant certifié (le montant brut de l'obligation de paiement moins les montants de notes de crédit applicables) à partir du compte de paiement 40 de l'acheteur vers un compte de rentrées 42 du fournisseur. L'instruction de transfert électronique de fonds est normalement émise le soir précédant l'échéance de l'acheteur, mais elle peut l'être plus d'un jour auparavant, de telle sorte que les fonds sont réglés pendant la nuit et sont disponibles le 73 jour de l'échéance de l'acheteur. La banque de l'acheteur est prédéterminée lorsque l'acheteur est configuré dans le système 10. [00115] À l'étape 7, au moment de la réception de l'instruction de transfert électronique des fonds, la banque de l'acheteur 106 transfère le montant certifié sur le compte de rentrées 42 du fournisseur. Le gestionnaire de communauté 120 ne prend réelle possession d'aucuns fonds, et il n'y a aucune interaction avec l'institution financière 110 à cette étape. [00116] La figure 1D illustre le fonctionnement du SCF système pour une transaction financée, c'est-à-dire lorsqu'une obligation de paiement est transférée à l'institution financière 110 depuis le fournisseur 108. Les étapes 1 à 4 de la figure 1D sont similaires aux étapes 1 à 4 décrites plus haut pour la figure 1C et, par conséquent, ne sont pas décrites pour la figure 1D. Parce que les événements décrits pour la figure 1D ont lieu avant l'échéance de l'acheteur, une étape correspondant à l'étape 5 décrite plus haut pour la figure 1C n'est pas montrée. Les étapes 6 et 7 décrites plus haut dans le cadre de la figure 1C n'ont pas lieu dans cette situation. [00117] À l'étape 5, l'obligation de paiement téléchargée à partir de l'acheteur 106 s'affiche pour le fournisseur 108 via l'interface utilisateur sous forme de rapport indiquant le montant de l'obligation de paiement, les échéances de l'acheteur et du fournisseur, l'acheteur et la date de la facture. Comme mentionné ci-dessus, le fournisseur peut également voir le contenu posté par les membres pour confirmer les factures sous-jacentes. Après avoir rendue visible l'obligation de paiement au fournisseur 108, le fournisseur peut proposer de vendre l'obligation de paiement à l'institution financière 110 en introduisant une offre irrévocable de vente de l'obligation de paiement dans le SCF système 10. Comme décrit de manière plus détaillée ci-dessous, le fournisseur peut soumettre une offre de vente manuellement par le biais d'une interface du SCF système en visualisant une obligation de paiement et en activant un bouton dans la page de l'interface utilisateur qui permet de soumettre l'offre. Dans ce cas, le SCF système associe l'offre de vente à l'obligation de paiement reliée à la page de l'interface utilisateur depuis laquelle l'offre de vente a été faite. Dans un mode d'avance automatique, le système soumet automatiquement les offres de vente après création des obligations de paiement. [00118] Comme nous en discuterons plus en détail ci-dessous, en mode manuel, le système permet au fournisseur 108 de sélectionner plusieurs obligations de paiement qu'il proposera à la vente dans une offre de vente unique. Si le fournisseur sélectionne plusieurs obligations, le SCF système associe l'offre de vente à toutes les obligations de paiement sélectionnées. En mode d'avance automatique, le SCF système préfère regrouper automatiquement toutes les obligations de paiement qui répondent aux règles d'avance automatique lorsque le processus d'avance automatique est en marche. Dans les paramétrages décrits actuellement, le système ne supporte qu'une seule règle d'avance automatique à la fois, c'est-à-dire que si la configuration choisie est l'avance automatique, de telle sorte que les obligations de paiement sont proposées automatiquement à la vente la veille de l'échéance du fournisseur si elles n'avaient pas été préalablement proposées à la vente, aucune autre règle d'avance automatique n'est définie. Ainsi, dans de tels paramétrages, l'avance automatique est utilisée uniquement pour réaliser des transactions déclenchées par l'échéance du fournisseur, et le fournisseur réalise toutes les autres transactions manuellement. Toutefois, dans un autre paramétrage, le système supporte plusieurs règles actives d'avance automatique à la fois, et le 75 fournisseur peut définir ou faire définir une ou plusieurs règles d'avance automatique en plus de l'échéance du fournisseur. Même dans les paramétrages actuellement décrits, dans lesquels l'échéance du fournisseur est la seule règle qui puisse être active à la fois, une autre règle d'avance automatique peut être appliquée, à condition qu'elle se déclenche avant l'échéance du fournisseur. [00119] L'offre de vente est ensuite présentée à l'institution financière 110 (l'étape 5 a deux flèches dans le tableau). Comme discuté ci-dessus, en ce qui concerne la présentation des obligations de paiement au fournisseur, l'offre de vente est présentée à l'institution financière dans le sens où elle est rendue accessible à l'institution financière, que l'institution financière accède à l'information ou non. Dans un paramétrage, l'offre est rendue visible à l'institution financière lorsque l'institution financière se connecte au système. Généralement, l'offre irrévocable reste en vigueur jusqu'à ce qu'elle soit acceptée par l'institution financière 110 ou jusqu'à une limite journalière, configurable pour l'institution financière, selon la première de ces éventualités. Dans les paramétrages actuellement décrits, même si ce n'est pas nécessaire, le paramètre de limite journalière est désactivé ou n'est pas utilisé, lorsqu'il est souhaité que toutes les obligations de paiement soient négociées avant l'échéance de leur fournisseur. [00120] À l'étape 6, si l'institution financière 110 choisit d'accepter l'offre de vente, elle introduit alors son acceptation dans le SCF système 10 par le biais de l'interface utilisateur. Alternativement, si l'institution financière n'accepte pas l'offre de vente avant l'échéance du fournisseur, le système peut être configuré pour entrer automatiquement l'acceptation ce jour-là. Le SCF système 10 peut être configuré pour acheter toutes les obligations proposées par un fournisseur 108 spécifique (cette acceptation peut donc également avoir lieu automatiquement par ce mécanisme), quelques obligations proposées selon certains critères (de nouveau, automatiquement), ou seulement manuellement par l'institution financière 110 par le biais d'une interface utilisateur du système 10 (en plus de la fonction automatique d'échéance du fournisseur, si elle est disponible et utilisée). Bien que, dans le paramétrage décrit actuellement, les fournisseurs négocient généralement avec une seule institution financière, le SCF système 10 peut également être configuré pour laisser plus d'une institution financière 110 participer avec un fournisseur donné. Comme indiqué ci-dessus, l'institution financière 110 peut, par exemple, choisir d'acheter jusqu'à un montant total spécifique en dollars et, ensuite, une deuxième institution financière 110 pourrait entrer, ou une institution financière pourrait être sélectionnée à partir de plusieurs institutions financières possibles sur la base de limites de crédit disponibles. Toutefois, dans les paramétrages décrits ici, deux institutions financières n'ont pas accès à la même offre irrévocable en même temps. [00121] Une fois qu'une offre de vente irrévocable est acceptée, les étapes 7 à 13 ont alors lieu dans une succession rapide. Du fait de la Convention du fournisseur et de la RPA, le fournisseur 108 accepte que l'ensemble de ses droits, titres et intérêts relatifs aux obligations soit vendu, assigné et transféré à l'institution financière 110, sans aucune action ou documentation supplémentaire de la part du fournisseur 108, de l'acheteur 106 ou de l'institution financière 110. Dans le cadre de la CA, l'acheteur 106 accepte que toute obligation transférée par le fournisseur 108 soit reconnue par l'acheteur comme ayant été valablement vendue et assignée au cessionnaire correspondant. À l'étape 7, l'institution financière 110 dépose le montant net de l'institution financière sur un compte de paiement 44 de l'institution financière. L'institution financière 110 peut également utiliser un « compte 77 soldé » à cet effet. Une fois l'enregistrement de l'acceptation effectuée dans SCF système 10 et déposition du montant net de l'institution financière sur le compte de paiement 44 de l'institution financière, l'achat de l'obligation est considéré par les parties comme étant conclu, dans le cadre de la fonction des contrats. Le titre de l'obligation se transmet du fournisseur 108 à l'institution financière 110. [00122] Le montant net de l'institution financière est le montant de l'obligation moins la commission de l'institution financière et tout frais de transaction du fournisseur et/ou frais de transaction de l'institution financière. Un « prix total du fournisseur » est la somme de quatre composantes : (a) le taux de base FI, (b) la marge FI, (c) le taux du fournisseur de services et (d) le taux du gestionnaire de communauté. Le taux de base FI et la marge FI sont définis dans le profil tarifaire de l'institution financière. Le taux du fournisseur de services est défini dans le profil tarifaire du fournisseur de service. Le taux du gestionnaire de communauté est défini par le gestionnaire de communauté dans le programme acheteur, comme la marge de communauté nette. Ces quatre taux sont de préférence définis comme des points de base qui sont appliqués sur la valeur totale de l'obligation de paiement et appliqués pour le nombre de jours entre l'acceptation de l'offre et l'échéance de l'acheteur. Toutefois, dans un paramétrage alternatif, ils peuvent être définis comme points de base appliqués sur le montant de l'obligation sans considérer le temps. Le taux de base FI est généralement une fonction du taux d'intérêt de base, comme le LIBOR. La marge FI est un taux d'intérêt ajouté pour le risque et le rendement de l'institution financière. Le taux du fournisseur de services détermine la commission de base du fournisseur de services, et le taux du gestionnaire de communauté détermine la commission de base du gestionnaire de communauté. [00123] Comme discuté ci-dessus, le gestionnaire de communauté peut, optionnellement, définir des frais de transaction du fournisseur et des frais de transaction de l'institution financière. Si de tel frais sont définis, le montant total fourni au fournisseur est alors le montant total de l'obligation de paiement (moins tous les montants de note de crédit applicables), moins la somme des prix totaux des fournisseurs, les frais de transaction du fournisseur et les frais de transaction de l'institution financière. Lorsque ces deux derniers frais ne sont pas appliqués, le montant net du fournisseur est le montant net de l'obligation moins les prix totaux des fournisseurs. Puisque les montants pouvant être déduits du montant de l'obligation sont connus, calculables ou prévisibles dans le cadre du fonctionnement du système, selon l'accord entre les parties, on peut considérer que le montant net du fournisseur correspond au montant de l'obligation de paiement. [00124] Cette étape du processus diffère des accords d'affacturage types. L'institution financière 110 prend le titre de la créance commerciale, et pas seulement un privilège sur celle-ci. Les mécanismes de transfert formel du titre peuvent varier en fonction de la juridiction. Par exemple, le titre d'une obligation de paiement transférée peut être considéré comme étant transféré lorsqu'une institution financière cessionnaire fournit un avis écrit à l'acheteur de l'obligation de paiement. Une formalité particulière peut être arrangée à l'intérieur du système 10 ou en dehors du système 10, entre les parties, avec ou sans conditions requises par les contrats. Si, pour une quelconque raison, l'acheteur 106 ne réussit pas à payer l'obligation de créance commerciale, l'institution financière 110 n'a aucun droit de revendre la créance au fournisseur 108 ou d'avoir aucun autre recours contre le fournisseur en l'absence d'une fraude du fournisseur. L'institution financière 110 compte par conséquent sur la force financière de 79 l'acheteur 106 lorsqu'elle achète la créance commerciale. Comme la solvabilité de l'acheteur est susceptible d'être meilleure que celle du fournisseur 108, l'institution financière 110 peut soit offrir de meilleurs taux (à cause du risque réduit) soit recevoir de meilleurs rendements (à cause du risque réduit, tel que créances douteuses), ou les deux. [00125] Normalement, tant que l'acceptation a lieu avant une heure limite spécifique pendant la journée, une instruction de transfert électronique de fonds est émise le soir de la journée où l'obligation est acceptée, à l'étape 8. Dans l'un des exemples du système, l'heure limite est fixée à une heure antérieure à la fin de la journée ouvrable, de telle sorte que si une institution financière n'accepte pas une offre, le système peut contacter l'institution financière et confirmer si l'institution financière souhaite l'accepter. Le SCF système 10 exécutera l'instruction de paiement dans ce paramétrage, ce qui signifie que le système émettra l'instruction de transfert électronique des fonds pour transférer le montant net du fournisseur du compte de paiement 44 de l'institution financière vers le compte de rentrées 42 du fournisseur, à l'étape 9. Étant donné que les parties peuvent compter sur les processus et systèmes de règlement de paiement existants, cela effectue le paiement du montant net du fournisseur de l'institution financière vers le fournisseur. Le gestionnaire de communauté 120 ne prend possession d'aucune portion du montant net de l'institution financière, hormis la commission du gestionnaire de communauté. [00126] Parallèlement aux étapes 8 et 9, le gestionnaire de communauté 120 émet à l'étape 10 une deuxième instruction de transfert électronique de fonds pour transférer la commission du gestionnaire de communauté, et une troisième instruction de transfert électronique de fonds pour transférer la commission du fournisseur de services, du compte de paiement 44 de l'institution financière vers un compte de rentrées CM 48 à l'étape 11. [00127] La figure 1E illustre les étapes déclenchées à l'échéance de l'acheteur. Une fois qu'une obligation a été vendue à l'institution financière 110, les flux d'argent à l'échéance de l'acheteur sont différents de ceux indiqués dans la figure 1C. Comme dans la figure 1C, le soir précédant l'échéance de l'acheteur, l'acheteur 106 dépose le montant de l'obligation de paiement sur un compte de paiement 40 de l'acheteur, à l'étape 1. [00128] Habituellement, le soir précédant l'échéance de l'acheteur, ou quelques jours avant, le gestionnaire de communauté 120 émet à l'étape 2 une instruction de transfert électronique de fonds pour transférer le montant de l'obligation de paiement du compte de paiement 40 de l'acheteur vers le compte de rentrées 46 de l'institution financière, à l'étape 3, lors de l'échéance de l'acheteur. Configuration du système [00129] Le système 10 peut être utilisé selon une ou plusieurs configurations électroniques appropriées. Comme l'illustre la figure 23, le système 10 est principalement effectué dans un emplacement informatique primaire 450. Comme discuté précédemment, le système peut inclure un système informatique secondaire de reflet 451. Comme la configuration de l'informatique et de la base de donnée du système primaire 450 et du système secondaire 451 sont les mêmes, seul l'arrangement du système primaire 450 est décrit ici, même s'il convient de préciser que ces explications s'appliquent aux deux systèmes. Ainsi, en référence au système primaire 450, le système 10 comprend un dispositif informatisé 450 approprié pour effectuer les paramétrages décrits ici. Le dispositif informatique 450 peut 81 prendre plusieurs formes, y compris, mais sans s'y limiter, un ou plusieurs ordinateur, station de travail, serveur, ordinateur réseau, ordinateur quantique, ordinateur optique, dispositif internet, appareil mobile, dispositif de traitement propre à une application, un serveur de base de données, etc. Des mises en oeuvre alternatives du dispositif informatisé 450 peuvent avoir moins de composants, plus de composants, ou des composants qui sont dans une configuration qui diffère de la configuration spécifique décrite ici. Les composants du système 450 peuvent être mis en oeuvre dans une logique basée sur le hardware, le software, et/ou une logique combinant le hardware et le software (par exemple, une logique hybride) ; par conséquent, les composants du système 400 ne se limitent pas à un type spécifique de logique. [00130] Dans le paramétrage décrit actuellement, le système 450 comprend un processeur ayant un ou plusieurs noyaux et mémoires. Le processeur peut inclure une logique basée sur le hardware ou sur le software pour exécuter les instructions pour le compte du dispositif informatisé 450. Dans une des mises en oeuvre, le processeur peut inclure un ou plusieurs processeurs distincts, tel qu'un microprocesseur. Dans une des mises en oeuvre, le processeur peut inclure du hardware, comme un processeur de signal numérique (DSP), une matrice de portes programmables par l'utilisateur (FPGA), une unité de traitement graphique (GPU), un circuit intégré propre à une application (ASIC), un processeur polyvalent (GPP), etc., sur lequel au moins un ou plusieurs composants du système 450 peut être exécuté. Dans une autre mise en oeuvre, le(s) noyau(x) peut (peuvent) être configuré(s) pour exécuter un software stocké dans la mémoire ou d'autres programmes pour contrôler le système informatique 450. [00131] Le système informatique 450 peut inclure un ou plusieurs supports de stockage tangible non transitoire lisible par informatique pour stocker une ou plusieurs instructions exécutables par informatique ou un software pour mettre en oeuvre des paramétrages exemplaires. Le système informatique 450 peut inclure un ou plusieurs supports de stockage tangible non transitoire lisible par informatique pour stocker une ou plusieurs instructions exécutables par informatique ou un software pour mettre en oeuvre des paramétrages exemplaires. La mémoire peut inclure une mémoire de système informatique ou une mémoire vive (RAM), telle que RAM dynamique (DRAM), RAM statique (SRAM), RAM de données étendues (EDO RAM), EEPROM, CD-ROM, DVD ou autre types de supports de stockage optique ou appareils de stockage magnétique ou périphérique de stockage amovible non volatile, etc., ou une combinaison de ceux-ci. [00132] Dans une des mises en oeuvre, un processeur de système 450 peut inclure une machine virtuelle (« VM ») pour exécuter les instructions situées dans la mémoire informatique. La machine virtuelle peut être mise en oeuvre pour gérer un processus exécuté sur plusieurs processeurs, de telle sorte que le processus donnera l'impression d'utiliser une seule ressource informatique au lieu de plusieurs. Il convient de préciser que la machine virtuelle peut être configurée pour recouvrir plusieurs appareils électroniques similaires au système informatique 450. La virtualisation peut être employée dans le système électronique 450 de telle sorte que l'infrastructure et les ressources au sein de l'appareil électronique puissent être partagées de manière dynamique. Plusieurs machines virtuelles peuvent résider dans le processeur du système 450. 83 [00133] Le système informatique 450 peut également comprendre un accélérateur matériel, tel que mis en oeuvre dans un ASIC, FGPA et ainsi de suite, afin d'accélérer le taux global de traitement du système informatique. [00134] En outre, le système informatique 450 peut comprendre une interface réseau pour créer une interface vers un réseau local ou étendu, tel que l'Internet, par une variété de connexions, y compris, mais sans s'y limiter, les lignes de téléphone standard, liens de réseau local ou étendu (par exemple, Ti, T3, 56kb, X.25), connexions haut débit (par exemple, réseau numérique à intégration de services (« ISDN »), relais de trames, mode de transfert asynchrone (« ATM »), connexions sans fil (par exemple, 802.11), interconnexions haut-débit (par exemple, Infini Band, gigabit, Ethernet, Myrinet) ou toute combinaison de ceux-ci. L'interface réseau peut comprendre un adaptateur réseau intégré, une carte d'interface réseau, une carte réseau d'association internationale de cartes mémoire d'ordinateurs individuels (« PCMCIA »), un adaptateur de carte réseau de bus, un adaptateur de réseau sans fil, un adaptateur universel de série réseau de bus (« USB »), un modem ou tout autre appareil approprié pour créer une interface entre le système informatique 450 et n'importe quel autre type de réseau capable de communiquer et d'effectuer les opérations décrites ici. [00135] Le système informatique 450 peut comprendre un ou plusieurs périphériques d'entrée/sortie (I/O) tel que clavier, interface multi-touch, outil de pointage, par exemple une souris, ou une combinaison de ceux-ci pour recevoir les instructions d'un utilisateur. Le dispositif informatisé 450 peut inclure d'autre périphériques I/O appropriés, comme le comprendront les spécialistes du domaine. [00136] Le dispositif informatisé 450 peut également comprendre un ou plusieurs dispositifs d'affichage visuel connectés de manière opérative avec les périphériques d'entrée. Une interface utilisateur graphique (« GUI ») peut être affichée dans le dispositif d'affichage afin de la présenter à un utilisateur. [00137] Un dispositif de stockage, indiqué à 452, peut également être associé au système informatique 450. Le dispositif de stockage 452 peut, par exemple, être un disque dur, CD-ROM ou DVD, lecteur zip, lecteur de bande, mémoire flash, clé USB ou autre support de stockage tangible lisible par informatique capable de stocker les informations, y compris un dispositif de stockage accessible par ordinateur et/ou processeurs de système informatique 450 par le biais de l'interface réseau. Le dispositif de stockage 452 peut être utile pour stocker les programmes de software d'une application, des moteurs de règles, des dépôts de données, une ou plusieurs bases de données et un système d'exploitation. Il convient de préciser que le stockage 452 peut être segmenté en plusieurs dispositifs de stockage, de telle sorte que, par exemple, chacune des applications puisse résider dans un dispositif de stockage séparé. Les bases de données peuvent être gérées par un logiciel de base de données, tel que (mais sans s'y limiter) Oracle Database, IBM DB 2, serveur mySQL et serveur Microsoft SQL. [00138] Lorsque les informations sont transférées ou fournies par le biais d'un réseau ou d'une autre connexion de communication (soit câblée, sans fil, ou une combinaison de câblée et sans fil) à un ordinateur, l'ordinateur voit correctement la connexion en tant que support lisible par informatique. Ainsi, toute connexion de ce type est convenablement nommée et considérée comme un support lisible par informatique. Les combinaisons des éléments mentionnés ci-dessus devraient également être comprises dans le champ des supports lisibles 85 par informatique. Les instructions exécutables par informatique comprennent, par exemple, les instructions et données qui amènent un ordinateur générique, un ordinateur spécialisé ou un dispositif de traitement spécialisé tel que processeur d'appareil mobile à exécuter une fonction spécifique ou un groupe de fonctions. [00139] Les spécialistes de la branche comprendront les fonctionnalités et les aspects d'un environnement informatique approprié dans lequel les aspects de l'invention peuvent être mis en oeuvre. Bien que cela ne soit pas requis, quelques-unes des inventions sont décrites dans le contexte général des instructions exécutables par informatique, tels que les modules du programme, qui sont exécutées par les ordinateurs dans les environnements en réseau. De tels modules du programme sont souvent conçus et représentés par des organigrammes, diagrammes de séquence, affichages d'écran exemplaires et autres techniques utilisés par les spécialistes du domaine pour communiquer comment fabriquer et utiliser de tels modules du programme. Généralement, les modules du programme comprennent des routines, programmes, objets, structures de données, etc. qui exécutent des tâches spécifiques ou mettent en oeuvre des types de données abstraites spécifiques au sein de l'ordinateur. Les instructions exécutables par informatique, structures de données associées et modules du programme constituent des exemples du code du programme pour exécuter les étapes des méthodes présentées ici. La séquence spécifique de telles instructions exécutables ou les structures de données associées constituent des exemples d'actes correspondants pour mettre en oeuvre les fonctions décrites dans de telles étapes. [00140] Le code du programme informatique qui met en oeuvre la plupart des fonctionnalités décrites ici comprend traditionnellement un ou plusieurs modules du programme qui peuvent être stockés sur le disque dur ou sur un autre support de stockage. Ce code du programme, comme les spécialistes du domaine le savent, inclut d'habitude un système d'exploitation, un ou plusieurs programmes d'application, d'autres modules du programme et des données du programme. Un utilisateur peut entrer des commandes et des informations dans l'ordinateur grâce au clavier, au dispositif de pointage ou à un autre périphérique d'entrée (pas affiché), tel que microphone, appareil mobile, dispositif portatif, ordinateur tablette, scanner et ainsi de suite. Ces périphériques d'entrée, entre autres, sont souvent connectés à l'unité de traitement par des connexions électriques, optiques ou sans fil connues. [00141] Le système du système d'exploitation peut être n'importe quel système d'exploitation approprié, tel que toute version des systèmes du système d'exploitation Windows Microsoft, les différentes versions des systèmes d'exploitation Unix et Linux utilisant le Linux Kernel, toute version de MACOS pour des dispositifs informatisés fournis par Apple Inc. de Cupertino, Californie, tout système d'exploitation intégré, tout système d'exploitation en temps réel, tout système d'opération open source, tout système d'exploitation propriétaire, tout système d'exploitation pour appareil mobile électronique, ou tout autre système d'exploitation capable d'être exécuté par le système 450 et effectuant les opérations décrites ici. Le système d'exploitation peut tourner en mode natif ou émulé. [00142] Des paramétrages exemplaires peuvent être fournis dans un ou plusieurs programmes lisibles par appareil électronique paramétrés sur un ou plusieurs supports, tel que le support de stockage non transitoire lisible par appareil électronique. Les supports peuvent être, mais ne s'y limitent pas, un disque dur, disque compact, disque digital versatile, carte 87 mémoire flash, mémoire morte programmable (PROM), mémoire vive (RAM), mémoire morte (ROM), mémoire vive magnétorésistante (MRAM) ou bande magnétique. [00143] En général, le programme lisible par un appareil électronique peut être mis en oeuvre dans n'importe quel langage de programmation. Quelques exemples de langages qui peuvent être utilisés comprennent Python, C, C+ +, C#, JAVA, JAVASCRIPT, un langage de description du matériel (HDL), UML, PLC, etc. Il convient de préciser que différents composants du système 450 peuvent être mis en oeuvre dans différents et/ou multiples langages de programmation. En outre, les programmes lisibles par informatique peuvent être mis en oeuvre dans un langage de description du matériel ou tout autre langage qui permet de recommander des calculs. Les programmes de logiciel peuvent être stockés sur un ou plusieurs supports comme code objet. Les instructions dans les langages de programmation peuvent être exécutées par un ou plusieurs processeurs pour mettre en oeuvre le programme lisible par informatique décrit dans les langages de programmation, ou, alternativement, les instructions peuvent être mises en oeuvre directement par des composants matériel autres qu'un processeur. [00144] La figure 23 illustre une mise en oeuvre distribuée de manière exemplaire adaptée à une utilisation avec les paramétrages exemplaires décrits ici. Un système peut comprendre le système informatique 450, un réseau 454, un fournisseur de service 456, un système informatique de l'acheteur 106, un système informatique de l'institution financière 110 et un système informatique du fournisseur 108, bien il convienne de préciser que d'autres paramétrages peuvent inclure plus d'appareils, moins d'appareils ou des appareils connaissant des arrangements qui diffèrent de ceux de la figure 23 sans s'éloigner du domaine des paramétrages révélés actuellement par l'invention présente. [00145] Il faut considérer que le réseau 454 transporte des données depuis une source vers une destination. Les paramétrages du réseau 454 peuvent utiliser des appareils de réseau, tels que routeurs, commutateurs, pare-feu et/ou serveurs et connexions (par exemple, des liens) pour transporter les données. Le réseau 454 peut être un réseau câblé utilisant des conducteurs et/ou des fibres optiques et/ou peut être un réseau sans fil utilisant des systèmes optiques en espace libre, des fréquences radio (« RF ») et/ou des circuits de transmission acoustique. Dans une des mises en oeuvre, le réseau 454 peut être en grande partie un réseau ouvert public, comme Internet. Dans une autre mise en oeuvre, le réseau 454 peut être un réseau plus restreint, comme un réseau d'entreprise virtuel. Le réseau 454 peut par conséquent comprendre des LAN, WAN, réseaux métropolitains (« MAN »), réseaux sans fil (par exemple, en utilisant IEEE 802.11, Bluetooth, etc.), etc., ou toute combinaison de ceux-ci. Le réseau 454 peut utiliser du middleware, tel que l'architecture CORBA (Common Object Request Broker Architecture) ou le modèle DCOM (Distributed Component Object Model). Les mises en oeuvre du réseau et/ou d'appareils fonctionnant sur des réseaux décrits ici ne se limitent à aucun type de données, protocole, architecture/configuration, etc. [00146] Le fournisseur de services 456 peut comprendre un appareil qui rend un service disponible pour un autre appareil. Par exemple, le fournisseur de services 456 peut inclure une entité (par exemple, un individu ou une corporation) qui fournit un ou plusieurs services vers une destination en utilisant un serveur et/ou d'autres appareils. Les services peuvent inclure des instructions d'exécuter une opération qui sont effectuées par une destination. De 89 manière alternative, un service peut inclure des instructions qui sont exécutées pour le compte d'une destination ; celles-ci effectuent une opération pour le compte de la destination. De la même façon, les systèmes informatique 106, 110 et 108 peuvent être configurés comme un ou plusieurs dispositifs informatisés, éventuellement avec un ou plusieurs dispositifs de stockage de mémoire, semblables à la configuration du système 450, et ces systèmes peuvent inclure des dispositifs qui reçoivent, stockent et transmettent des informations par le biais du réseau 454. Programme acheteur [00147] Le programme acheteur est un mécanisme financier destiné à établir des règles essentielles de traitement de système depuis la perspective SCF. Les règles sont configurées dans le programme acheteur ; elles déterminent les aspects financiers associés aux négociations et aux financements du système. Le programme acheteur permet des fonctionnalités configurables telles que (1) la définition des profils de prix de l'institution financière, (2) la distribution des partages de l'intérêt et de la commission entre les participants de la communauté, (3) la distribution d'offres d'achat aux institutions financières, (4) la définition des devises et du fuseau horaire, (5) la définition des fenêtres de marché (c'est-à-dire les heures de la journée pendant lesquelles une offre peut être acceptée pour une obligation donnée), si c'est utilisé, (6) les valeurs de durée limite pour l'acceptation de la transaction, si c'est utilisé, (7) les fournisseurs et institutions financières participantes, (8) les limites d'échanges qui protègent les institutions financières contre le dépassement de seuils financiers, (9) l'affichage du taux d'intérêt journalier, mensuel ou annuel, (10) la distribution automatique d'offres de vente, (11) la génération automatique d'offres de vente, (12) les passerelles de règlement, (13) les rapports d'avis de paiement, (14) les comptes de compensation, (15) la distribution de l'intérêt et des commissions aux participants de la communauté et (16) les prix du fournisseur, entre autres. [00148] La figure 2 est un diagramme 30 de flux de données du programme acheteur illustrant le transfert de flux de données en provenance du gestionnaire de communauté 120 et du fournisseur de services 20 vers et en provenance d'une configuration du programme acheteur et un processus de gestion 136 (voir également la figure 3) pour le système financier 10 de la chaîne d'approvisionnement de la figure 1A. Chaque flux de données peut contenir un ou plusieurs paramètres, règles ou autres éléments de configuration. [00149] Le programme acheteur 100 (la figure 3) peut être configuré par un gestionnaire de communauté 120 et un fournisseur de services 20. La division des tâches entre le gestionnaire de communauté 120 et le fournisseur de services 20 peut être séparée lorsque les fonctions sont effectuées par des entités séparées ayant chacune des composants de connexion indépendants. Au moment de la connexion au système 10 (la figure 1A), chaque entité peut accéder aux options et aux fonctionnalités directement reliées à cette entité. Le fournisseur de service 20 a accès aux détails du programme acheteur 100 dans le cadre du support mais ne peut modifier aucun champ en lien avec les aspects financiers. Le fournisseur de services 120 gère également plusieurs paramètres clés du programme acheteur 100 qui sont reliés au niveau opérationnel et nécessaires à la configuration et à l'exploitation du programme acheteur 100. [00150] Dans la figure 2, le flux de données entre le fournisseur de services 20 et le programme acheteur 100 par le biais de la configuration du programme acheteur 136 représente ces processus qui sont effectués principalement par une série d'interfaces dans le cadre de la configuration et de la gestion du système du programme acheteur 100 et des entités 91 associées au programme Elles comprennent des fonctionnalités telles que (1) configuration des paramètres du système du programme acheteur, (2) configuration et gestion du compte bancaire du fournisseur de services (SP), (3) ajout et maintien de l'entité des institutions financières, (4) ajout et maintien de l'entité du fournisseur, (5) visualisation des requêtes d'activation du compte bancaire et confirmation des informations du compte bancaire, (6) ajout et maintien de l'entité de l'acheteur, (7) activation des fournisseurs des programmes acheteur une fois que l'entité du fournisseur a été configurée, (8) visualisation des règles du programme acheteur si des problèmes de configuration qui nécessitent l'attention du fournisseur de services apparaissent et (9) établissement et maintien des prix du fournisseur de services et distribution des commissions. [00151] Dans la figure 2, le flux de données entre le gestionnaire de communauté 120 et le programme acheteur 100, de nouveau par le bais des interfaces de l'acheteur pour la configuration du programme 136, représente ces processus qui sont principalement effectués après établissement des bases du programme acheteur 120 par le fournisseur de services 100. Ce sont des processus qui sont indépendants de ceux effectués par un fournisseur de services 20 mais qui restent toutefois dépendants du rôle du fournisseur de services lors de la configuration initiale et de la gestion continue des entités qui participent au programme. Ils comprennent des fonctionnalités tels que (1) désignation des FI internes pour les programmes acheteur, (2) activation et désactivation des FI des programmes acheteur, (3) configuration et maintien des profils fiscaux s'il y a lieu, (4) établissement des charges et des marges pour tous les programmes acheteur, (5) définition de plusieurs règles qui contrôlent comment le programme acheteur traite les obligations de paiement et les paiements, (6) configuration des fournisseurs dans leurs échelons respectifs du programme acheteur, (7) association des profils de prix des FI aux programmes acheteur, (8) configuration du programme acheteur par défaut et les échelons liés du programme acheteur, (9) configuration des paramètres qui contrôlent les montants minimaux et maximaux des offres de vente, les jours limite, etc., s'ils sont utilisés, (10) configuration et attribution des comptes bancaires, (11) distribution des offres d'achat qui nécessitent une distribution manuelle et (12) activation des fournisseurs dans le programme acheteur. Configuration du programme acheteur [00152] La figure 3 est un aperçu d'un processus exemplaire pour la configuration et la gestion du programme acheteur (indiqué sous 100 comme un ensemble de paramètres et de règles définis et effectués par les processus illustrés dans la figure 3) pour la gestion de la chaîne d'approvisionnement financière. La configuration et le maintien d'un programme acheteur 100 est une série de processus. Même si les processus sont traditionnellement effectués selon un ordre spécifique lors de la configuration initiale du programme acheteur 100, les mêmes processus sont également utilisés lors de la gestion courante du programme acheteur 100 et peuvent par conséquent être effectuées selon la séquence requise. Une série de tâches de configuration correspondent à chaque processus. Certains processus sont effectués par le fournisseur de services 20, tandis que d'autres sont effectués par le gestionnaire de communauté 120. Le fournisseur 108, l'acheteur 106 et l'institution financière 110 sont également impliqués dans le processus de configuration. Il convient de préciser que les étapes de configuration du programme acheteur 100 peuvent différer de ce paramétrage exemplaire. Certaines étapes peuvent être omises ou des étapes supplémentaires peuvent être incluses. En 93 outre, les étapes ne doivent pas nécessairement être conformes à l'ordre donné dans cet exemple non obligatoire. Configuration du programme acheteur par défaut--Fournisseur de services [00153] Un module de fournisseur de services 20 (voir la figure 5) est utilisé pour configurer la plateforme SCF. La plateforme SCF comprend des communautés, et chaque communauté 112 comprend un ou plusieurs programmes acheteur 100. Les composants en lien avec le programme acheteur 100 comprennent les communautés 112, fournisseurs 108, acheteurs 106, institutions financières 110, programmes acheteur par défaut et comptes bancaires. [00154] Lorsqu'un programme acheteur 100 est ajouté pour la première fois, il s'agit d'un programme acheteur 100 par défaut. Un acheteur 106 peut avoir plusieurs programmes acheteur 100 par défaut. Chacun des multiples programme acheteur 100 par défaut peut avoir une devise spécifiée différente, et certains ou tous les programmes acheteur 100 par défaut peuvent avoir la même devise. Le programme acheteur 100 par défaut peut être subdivisé en sous-programmes ou échelons du programme acheteur 214 (la figure 4). Le gestionnaire de communauté 120 peut utiliser les échelons du programme acheteur pour organiser les fournisseurs 108 selon différents profils de prix pour le même acheteur 106. [00155] Un scénario de configuration de fournisseur de services 20 pour un programme acheteur 100 commence traditionnellement par l'étape 121 de la configuration de l'acheteur. Le fournisseur de services 20 saisit dans la base de données 452 (la figure 23) les informations de l'acheteur 106 telles que nom, adresse, informations de contact et nom d'utilisateur. [00156] Une étape supplémentaire 122 du programme acheteur par défaut entre les paramètres en lien avec le système 10 qui contrôlent les activités d'échange et de financement. D'autres paramètres pour le nouveau programme acheteur 100 sont inclus pour initialiser la devise, le compte bancaire du fournisseur de services, les prix du fournisseur de services et le fuseau horaire. [00157] Une étape 124 de configuration FI ajoute une première institution financière 110 à la communauté 112. Cette étape ne s'applique pas si une institution financière 110 est utilisée par le programme acheteur 100. L'étape 126 de l'association de la FI à la communauté relie l'institution financière 110 à la communauté 112. A ce stade, l'institution financière 110 ne participe pas réellement, parce qu'elle n'a pas encore reçu d'invitation à rejoindre le programme acheteur 100. [00158] Une étape 128 de configuration du fournisseur ajoute et active les fournisseurs 108 de telle sorte qu'ils puissent être associés au programme acheteur 100. Un acheteur 106 peut avoir un grand nombre de fournisseurs 108 qui ne se trouvent pas actuellement sur la même plateforme SCF. Les fournisseurs 108 doivent être ajoutés et activés pour être associés au programme acheteur 100. Un fournisseur 108 est ajouté en ajoutant les informations d'entreprise et le nom d'utilisateur administrateur initial du fournisseur. Les informations du nom d'utilisateur sont traditionnellement communiquées au fournisseur 108 par email. Bien sûr, les fournisseurs 108 qui sont déjà ajoutés ou associés au programme acheteur 100 n'ont pas besoin d'être à nouveau ajoutés. Le fournisseur de services 20 approuve les fournisseurs 108 ajoutés par une interface web avant que les fournisseurs 108 ne puissent être ajoutés à un programme acheteur 100. Une fois que les fournisseurs 108 ont été ajoutés (si nécessaire) et 95 que les autres configurations du programme acheteur ont été effectuées, le fournisseur de services 20 accède au programme acheteur par défaut et associe le fournisseur 108 au programme acheteur 100. Bien sûr, un fournisseur 108 ayant été ajouté préalablement peut également être associé au programme acheteur 100. Veuillez noter, comme indiqué dans la figure 3, que le gestionnaire de communauté 120 peut également ajouter et activer des fournisseurs selon le processus 128. [00159] Lors de l'étape 134 de vérification/approbation des comptes bancaires, le fournisseur de services 20 vérifie que toutes les informations des comptes bancaires et données d'autorisation entrées dans le système soient correctes. Cette étape s'effectue normalement en utilisant l'interface web ; toutefois, une fois que cette étape a été réalisée avec succès, le fournisseur de services 20 configure et active le compte bancaire en utilisant le SCF système 10. Le fournisseur de services 20 vérifie également les profils de prix de l'institution financière (qui ont été entrés par l'institution financière) par rapport aux prix sur lesquels les parties s'étaient mises d'accord dans les contrats au 135. Avant l'étape de vérification, l'institution financière aura introduit ses profils de prix, traditionnellement par devise, au 139. Configuration du programme acheteur par défaut--Gestionnaire de communauté [00160] Le gestionnaire de communauté 120 effectue la configuration 136 du programme acheteur par défaut et est responsable de la configuration et de la mise à jour des programmes acheteur 100. Avant que les fournisseurs 108 ne puissent faire une transaction, la configuration initiale configure et active le programme acheteur 100 avec au moins un fournisseur 108 et une institution financière 110 active. Une fois que le programme acheteur 100 est actif, le gestionnaire de communauté 120 continue de surveiller et de gérer le programme en utilisant les outils à disposition sur la plateforme SCF. Un fournisseur ne peut pas être ajouté à un programme acheteur avant que le programme acheteur ne soit activé, ce qui a lieu une fois que les données de la communauté sont saisies, qu'une institution financière a accepté le programme acheteur, qu'un acheteur a saisi les informations de son compte bancaire et que le fournisseur de services a vérifié les informations du compte bancaire. [00161] Un scénario de configuration de gestionnaire de communauté 120 pour un programme acheteur 100 par défaut comprend une étape 130 d'association de profil de prix FI. Le gestionnaire de communauté 120 a accès à une liste 204 de profil de prix (la figure 4). La liste 204 de profil de prix FI donne un accès aux détails des profils de prix FI 208 (la figure 4) et à l'historique de taux 206 (la figure 4). Le profil de prix FI 208 contient les prix fournis à l'institution financière 110 dans le cadre du processus de financement. Sont compris le taux de base et les points de base de la marge que l'institution financière 110 reçoit lorsqu'elle accepte une offre d'achat. [00162] Une étape 132 d'ajout de comptes sur marges/de compensation ajoute des comptes sur marges et/ou de compensation s'ils n'existent pas déjà. Le gestionnaire de communauté 120 utilise la fonctionnalité de compte sur marges/de compensation des échéances pour ajouter de nouveaux comptes. Bien sûr, si les comptes sur marges/de compensation existent déjà, l'étape 132 d'ajout de comptes sur marges/de compensation peut être sautée. Le compte sur marges est le compte sur lequel les commissions du gestionnaire de communauté sont payées. Le compte de compensation d'échéance est le compte depuis lequel les paiements sont faits sur les créances commerciales arrivant à échéance aux institutions financières (si elles ont été échangées) ou aux fournisseurs (si elles n'ont pas été échangées). 97 [00163] Les paramètres du programme acheteur 100 sont initialisés durant la configuration 136 du programme acheteur. Ces paramètres sont expliqués plus en détail plus bas et ont lieu dans un onglet programme acheteur, un onglet paramètres, un onglet distribution, un onglet institutions financières et un onglet fournisseur. [00164] Lors de la configuration 136 du programme acheteur, les paramètres de l'onglet programme acheteur sont initialisés, y compris les détails de l'entreprise, les détails du programme acheteur, les règles de restriction d'avance automatique, les détails du gestionnaire de communauté et les règles de calcul des intérêts. [00165] Lors de la configuration 136 du programme acheteur, les paramètres de l'onglet paramètres sont initialisés, y compris marge nette de la communauté, frais de transaction du fournisseur, jours limites minimaux de transaction (s'il y a lieu), jours limites maximaux de transaction (s'il y a lieu), réserve (s'il y a lieu), compte sur marges, compte de compensation des échéances, affichage des taux, profil fiscal, montant minimal (offre de vente) (s'il y a lieu) et montant maximal (offre de vente) (s'il y a lieu). [00166] Lors de la configuration 136 du programme acheteur, les paramètres de l'onglet distribution sont initialisés, y compris rotation et manuel. Le paramètre de rotation est initialisé lorsque plus d'une institution financière 110 est comprise dans le programme acheteur 100. Le paramètre manuel est initialisé lorsque le gestionnaire de communauté 120 distribue des offres de vente. [00167] Lors de la configuration 136 du programme acheteur, les paramètres de l'onglet institutions financières sont initialisés, y compris désactiver la FI, ajouter la FI, associer le profil de prix FI et modifier la séquence de rotation. [00168] Lors de la configuration 136 du programme acheteur, l'onglet fournisseur n'a aucune information, parce que les fournisseurs ne peuvent pas être ajoutés avant que la configuration ne soit terminée. Toutefois, après la configuration, l'onglet fournisseur permet au gestionnaire de communauté 120 de voir tous les fournisseurs dans le programme acheteur et de déplacer les fournisseurs 108 entre les échelons du programme acheteur. [00169] Lors de la configuration 136 du programme acheteur, une possibilité d'ajout de programme acheteur permet au gestionnaire de communauté 120 de configurer les échelons du programme acheteur. Le gestionnaire de communauté 120 peut organiser les fournisseurs 108 dans des échelons séparés et attribuer différents taux et commissions, ou d'autres paramètres, à chaque échelon. [00170] Il convient de noter qu'à part l'onglet programme acheteur, l'onglet paramètres et l'onglet institution financière (section détails), les paramètres de l'échelon du programme acheteur 214 sont traditionnellement hérités du programme acheteur 100 par défaut. Configuration du programme acheteur--Institution financière [00171] Une fois que le gestionnaire de communauté 120 a associé une institution financière 110 au programme acheteur 100 sous 126, l'institution financière 110 reçoit une invitation à s'y joindre. Dans le cadre d'un processus d'inscription, l'institution financière 110 utilise une interface utilisateur du gestionnaire de portfolio 503 (la figure 7) (expliqué plus bas) pour rejoindre le programme acheteur au 138 et pour définir les paramètres importants du 99 programme acheteur 100, y compris les informations du compte bancaire, les informations de contact, les limites de crédit et les règles d'acceptation automatique. Configuration du programme acheteur--Fournisseur [00172] Une fois que le fournisseur de services 20 ou qu'un gestionnaire de communauté 120 a associé un fournisseur 108 au programme acheteur 100, le fournisseur 108 reçoit une invitation à rejoindre le programme acheteur si les règles d'avance automatique sont actives pour le programme acheteur. Dans un paramétrage décrit ici, une règle d'avance automatique est définie pour vendre les offres selon le mode d'avance automatique le jour précédant les échéances applicables du fournisseur, et les fournisseurs sont par conséquent invités à rejoindre le programme acheteur et doivent accepter avant d'être inclus. Dans le cadre du processus d'inscription, le fournisseur 108 utilise une interface utilisateur d'activation du programme acheteur (expliqué plus bas) pour rejoindre le programme d'utilisateur au 140. En règle générale, le fournisseur configurera ses comptes bancaires lors de sa configuration dans le système, mais le fournisseur peut effectuer n'importe quelle tâche administrative comme la configuration de l'avance automatique. Si un programme acheteur n'est pas activé pour l'avance automatique, le fournisseur n'est pas averti lorsque le fournisseur de services ou le gestionnaire de communauté ajoute le fournisseur au programme acheteur. Puisque le fournisseur aura la possibilité de décider manuellement de négocier toute obligation dans ce programme, l'accord du fournisseur pour entrer dans le programme n'est pas nécessaire, même si, dans un autre paramétrage, l'accord du fournisseur est toujours obtenu. Configuration du programme acheteur-1' Acheteur [00173] De même, puisque l'acheteur 106 télécharge de manière sélective et volontaire les données A/P afin de créer des obligations de paiement, l'acheteur 106 ne doit pas nécessairement s'enregistrer dans un programme acheteur 100 une fois que la CA est établie. Plusieurs tâches de configuration sont requises dans ce paramétrage, toutefois, et l'acheteur 106 configure par conséquent les paramètres de l'acheteur lors du processus 142, y compris la définition des dates d'échéance, la correction automatique des dates d'échéance et des comptes bancaires. Comme mentionné ci-dessus, le système extrait les dates d'échéance de l'acheteur et du fournisseur à partir des informations fournies dans les données A/P de l'acheteur, et celles-ci sont vérifiées afin de s'assurer qu'elles tombent sur des jours ouvrables valables. La base de données du système maintient une ou plusieurs tables qui définissent les jours ouvrables valables, qui peuvent être définis de n'importe quelle manière acceptable entre les parties. Dans un paramétrage, les jours ouvrables valables sont les jours où les banques sont ouvertes à la fois dans le pays de l'institution financière et de l'acheteur, mais la base de données peut également être réglée pour que les jours ouvrables valables soient également valables dans le pays du fournisseur. Dans un paramétrage, une table de calendrier simple est utilisée, de telle sorte que si un jour n'est pas un jour ouvrable valable dans le pays de l'acheteur ou dans celui de l'institution financière (ou, dans un autre paramétrage, également dans le pays du fournisseur), il ne s'agit pas d'un jour ouvrable valable. Dans une autre configuration, des tables séparées sont maintenues pour chaque fournisseur, institution financière et acheteur, de telle sorte que les jours ouvrables valables sont définis pour chacun d'entre eux. Une manière de le faire est d'établir une table de jours ouvrables valables pour chaque pays dans lequel les acheteurs, fournisseurs et institutions financières sont situés, et 101 d'associer dans le système 10 une telle entité avec la table appropriée sur la base de l'emplacement. Chacune de ces tables identifie les jours du calendrier qui sont des week-ends ou des jours fériés dans les pays respectifs. Le système 10 peut ensuite vérifier les échéances du fournisseur, les échéances de l'acheteur et les dates d'offres par rapport aux tables applicables pour les parties impliquées dans la transaction. Le système peut, par exemple, vérifier les échéances de l'acheteur par rapport aux tables de jours ouvrables valables de l'acheteur et des institutions financières, puisque la transaction sur l'échéance de l'acheteur se situe entre ces deux entités. L'échéance du fournisseur et la date d'offre sont vérifiées par rapport aux tables de l'institution financière et du fournisseur, pour des raisons similaires. Même si la date d'offre n'implique pas une transaction financière, et n'est pas vérifiée par rapport à la table des jours ouvrables valables dans un des paramétrages, cette vérification est effectuée dans un autre paramétrage, sur la base d'une hypothèse que l'offre devrait être faite pendant un jour ouvrable, lorsque les parties sont susceptibles d'exercer des activités. Comme mentionné ci-dessus, dans un autre paramétrage, il y a une table unique de jours ouvrables valables qui identifie tous les jours ouvrables non valables pour tous les acheteurs, fournisseurs et institutions financières dans un programme acheteur. Cette table unique est utilisée pour vérifier toutes les échéances de l'acheteur, les échéances du fournisseur et les dates d'offre pour toutes les transactions dans le programme acheteur respectif. [00174] Le système 10 définit certaines règles par défaut qui peuvent affecter la validité d'une date d'échéance donnée. Comme décrit ci-dessus, la règle du système pourrait, par ex., être que les dates d'échéance ne peuvent pas coïncider avec des jours qui ne sont pas des jours ouvrables valables dans la base de données. En général, s'il y a un conflit, le système déplace les échéances de l'acheteur vers le prochain jour ouvrable valable suivant, et déplace les dates conflictuelles du fournisseur et celles de l'offre vers le prochain jour ouvrable valable précédent. Toutefois, l'acheteur 106, peut ajouter ses propres règles (p.ex. changer la date d'échéance au prochain mercredi, indépendamment du fait qu'il y ait ou non un conflit de jour ouvrable valable) et/ou des règles qui régissent la définition des dates d'échéance lorsque les règles par défaut sont violées. De plus, une option du système permet au système de déplacer les échéances de l'acheteur d'une obligation de paiement, de telle sorte qu'une date d'échéance donnée ait suffisamment de valeur positive pour couvrir une note de crédit due à cette date. Entités du programme acheteur [00175] Le système 10 maintient et présente une interface utilisateur séparée pour chaque entité de la communauté. Au moment d'accéder au système 10 par une connexion réseau par Internet 454 (la figure 23), le système 10 présente un écran de connexion à la partie en train d'accéder au système et demande un nom d'utilisateur et un mot de passe. Puisque, dans la configuration, chaque entité de la communauté est associée dans la base de données avec son type d'entité (c'est-à-dire institution financière, acheteur, fournisseur, fournisseur de services ou gestionnaire de communauté), l'entrée du nom d'utilisateur et du mot de passe de la partie permet au système d'identifier le type d'entité correcte pour la partie et ainsi de présenter à la partie l'interface utilisateur correcte. L'interface de page Web de chaque entité est configurée en fonction des besoins de cette entité. Gestionnaire de communauté [00176] La figure 4 est un diagramme illustrant les caractéristiques de la page Web 200 d'un gestionnaire de communauté du programme acheteur. Les caractéristiques Web du 103 gestionnaire de communauté, de même que les autres pages et, plus généralement, les interfaces décrites ici, sont présentées à l'utilisateur par la connexion Internet 454 (la figure 23) par le processeur du SCF système 456. Une page d'accueil 202 du gestionnaire de communauté contient une liste d'acheteurs 210 (c'est-à-dire une liste de tous les acheteurs dans la communauté) et un résumé des informations sur les acheteurs ayant trait à tous les programmes acheteur 100 pour cet acheteur 106. En outre, le gestionnaire de communauté 120 peut accéder aux programmes acheteur 100 pour chaque acheteur 106 affiché. [00177] Les acheteurs 106 sont fournis dans la liste d'acheteurs 210 du programme acheteur. Les acheteurs peuvent avoir plusieurs programmes acheteur 100. Toutefois, un programme acheteur donné peut aussi être associé à un ou plusieurs échelons de programme acheteur. Un échelon du programme acheteur est en grande partie une réplique du programme acheteur parent, mais avec de légers changements spécifiques à un ou plusieurs fournisseurs donnés. Ainsi, si un acheteur a un groupe de fournisseurs que l'acheteur considère comme lié, mais pour lequel il peut souhaiter garder quelques paramètres individuels, le gestionnaire de communauté (conjointement avec l'acheteur et/ou l'institution financière) configure un ou plusieurs échelons du programme acheteur groupé, à l'intérieur d'un groupe de programme acheteur, avec le programme acheteur original duquel provient l'échelon. Un groupe d'échelons du programme acheteur et le programme acheteur parent peut être considéré comme un programme acheteur collectif ou pas, selon le contexte. Par exemple, le paramètre de fenêtre de marché est défini au niveau du groupe, alors que les profils de prix FI sont spécifiques à un programme ou échelon du programme acheteur donné. Le gestionnaire de communauté a la capacité d'organiser les fournisseurs 108 dans une liste de fournisseurs 216 en différents échelons du programme de 1"acheteur 214 pour le même acheteur 106. Les capacités du programme acheteur 100 permettent également l'association d'un profil de prix FI 208 unique à n'importe quel échelon du programme acheteur 214 à l'intérieur d'un programme acheteur 100. [00178] Le gestionnaire de communauté 120 peut voir les profils de prix FI 208 et voir l'historique des taux 206. Une capacité supplémentaire à fixer des prix en lien avec les échelons du programme acheteur 214 peut également être ajoutée. Les capacités du programme acheteur 100 permettent également l'association d'un profil de prix FI 208 unique à n'importe quel échelon du programme acheteur 214 à l'intérieur d'un programme acheteur 100. [00179] Depuis le programme acheteur 100, le gestionnaire de communauté 120 peut voir la liste de fournisseurs 216 contenant les fournisseurs 108 qui sont actifs dans le programme acheteur 100. Un échelon du programme acheteur associe un fournisseur donné 108 à une série de paramètres, y compris les profils de prix FI, de telle sorte que ces paramètres s'appliquent aux transactions qui impliquent ce fournisseur à cet échelon. Ainsi, depuis une interface 212 du programme acheteur, le gestionnaire de communauté 120 peut grouper des fournisseurs 108 dans un échelon du programme acheteur 214 de telle sorte que les fournisseurs 108 ayant été attribués à ce profil reçoivent des considérations financières de prix spécifiques, y compris, mais sans s'y limiter, des jours limites de transaction (s'il y a lieu), taux de base FI, marge FI, taux du fournisseur de services, taux du gestionnaire de communauté, frais de transactions du fournisseur (s'il y a lieu) et frais de transaction financière (s'il y a lieu). Le taux du gestionnaire de communauté et le taux du fournisseur de services 105 peuvent être combinés dans un taux de marge de communauté net, p. ex. lorsqu'une entité unique est à la fois le fournisseur de services et le gestionnaire de communauté. Toutefois, lorsque ces entités sont distinctes, le gestionnaire de communauté peut introduire uniquement une marge de communauté nette (c'est-à-dire seulement le taux de gestionnaire de communauté), et le fournisseur de services introduit séparément le taux du fournisseur de services. Dans ce premier cas, le prix total du fournisseur est égal à la commission de l'institution financière plus la commission de marge de communauté brute plus tout frais de transaction de l'institution financière et/ou du fournisseur de services, mais, dans le dernier cas, la marge de communauté brute est remplacée par le marge de communauté nette et le taux du fournisseur de services. [00180] Le profil de prix FI (voir 204) fournit au programme acheteur 100 les taux et commissions associés aux institutions financières 110 qui participent au programme acheteur 100. Le profil de prix FI est associé au programme acheteur 100 par le gestionnaire de communauté 120 au 130 (la figure 3). Le profil de prix FI est spécifique à la devise et est attribué à un programme acheteur 100 spécifique lorsque le réglage de devise du programme acheteur 100 correspond au réglage du profil de prix FI. Le profil de prix FI fournit les prix FI au programme acheteur 100 et définit les taux de base FI et la marge FI. [00181] Les informations financières du profil comprennent le nom du profil, la devise spécifiée, le taux du profil en points de base, la marge additionnelle FI (mensuelle/prime/fixée) en points de base, le calcul des taux (annuel ou plat) et le nombre de jours dans l'année pour le calcul des taux. Le profil de prix FI est spécifique à la devise et correspond à celle du programme acheteur 100 associé. Le taux du profil est affiché en pourcentage (mais pourrait être affiché en points de base) et il s'agit de la somme du taux de base FI (en fonction du critère de sélection du taux) et de la marge additionnelle FI. La marge additionnelle FI est la marge que l'institution financière 110 recevra sur le taux de base FI (mensuel, préférentiel ou fixe). Par exemple, si le taux FI fixe est défini à 6%, et que la marge additionnelle FI est de 100 points de base, alors le taux de profil sera de 700 points de base ou 7%. Le calcul du taux peut être annuel ou forfaitaire. Pour un calcul de taux annuel, le taux est réparti sur le nombre total de jours restants avant l'échéance de l'acheteur (c'est-à-dire qu'il s'agit du taux, divisé par le nombre de jours dans l'année, multiplié par le nombre de jours restants avant l'échéance de l'acheteur). Pour un calcul du taux forfaitaire, le taux est appliqué au montant entier, et les jours restants avant l'échéance de l'acheteur ne sont pas pris en compte. Le nombre de jours dans l'année est utilisé pour spécifier le nombre de jours en calculant un taux annuel. [00182] Le critère de sélection du taux spécifie la manière selon laquelle le taux d'intérêt (c'est-à-dire le taux de base FI) est appliqué aux obligations de paiement. Une option basée sur l'échéance permet à l'institution financière d'introduire un taux de base FI spécifique au nombre de jours entre l'échéance de l'acheteur et la date à laquelle la transaction a lieu. Tales jours peuvent être groupés en trente jours ou, autre, par incréments. Les options de taux « préférentiel/libor » et « fixe » appliquent un seul taux, indépendamment de la différence de temps. Indépendamment de la manière selon laquelle le taux de base FI est défini, il sera traité comme défini par un paramètre « Type de Taux ». Modifier le programme acheteur [00183] Les règles d'avance automatique sont définies au niveau du programme acheteur. De manière plus spécifique, les règles d'avance automatique restreintes définissent 107 des paramètres pour la création automatique d'ordres d'achat. Si un paramètre « Régler l'avance automatique » est réglé sur « On », les options d'avance automatique peuvent être sélectionnées. Les règles d'avance automatique prévoient un montant minimal, un montant maximal, la date (n'importe quel jour, date d'échéance, dans l'intervalle d'arrivée à échéance, dates spécifiques) qui va être avancée automatiquement, le montant de l'obligation de paiement, le numéro de l'obligation de paiement et les dates de programme (chaque jour ou à des dates précises). L'option « n'importe quel jour » signifie que les obligations de paiement téléchargées pour ce fournisseur pour ce programme acheteur sont automatiquement offertes après leur création lors du prochain fonctionnement de l'avance automatique. L'option « date d'échéance » signifie que les obligations de paiement sont automatiquement offertes à une date du calendrier (la date d'échéance) identifiée dans les données téléchargées à partir des données de l'acheteur. Pour les programmes acheteur ayant des obligations de paiement avec échéances de fournisseur, « Régler l'avance automatique » est réglé sur « on », et la règle de « date d'échéance » est sélectionnée, et le système sélectionne l'échéance du fournisseur comme date d'échéance pour les règles d'avance automatique. Cela amène le système à proposer automatiquement les obligations de paiement à la vente la veille de leur échéance de fournisseur (avec ajustement possible lors d'un conflit avec la (les) table(s) de jours ouvrables valables, comme décrit ici. L'option « date d'arrivée à échéance » signifie que le système offrira automatiquement les obligations de paiement à la vente à une certaine heure avant leurs dates d'échéance. L'avance automatique peut aussi être réglée sur la base de l'heure à partir de la date de la facture pour la (les) facture(s) sur laquelle (lesquelles) l'obligation de paiement se base. Comme noté ici, le système 10 fonctionne sur la base des obligations de paiement, et non pas des factures, mais si un acheteur télécharge des données de facture comme contenu posté par les membres, le système peut utiliser la date de la facture à cet effet. Dans ce paramétrage, si l'une des options de sélection de date est choisie, les autres sont désactivées. Si « date d'échéance » est sélectionné, les options « arrivée à échéance » ou « n'importe quel jour » ne peuvent pas être sélectionnées, même s'il convient de préciser que le système pourrait être configuré pour permettre des règles simultanées d'avance automatique. Il convient de noter que l'option d'avance automatique peut être réglée sur « On » lors de la configuration initiale pour un programme acheteur 100 par défaut ou de la configuration initiale d'un échelon de programme acheteur. Dans un paramétrage, une fois qu'elle a été éteinte pour tout programme acheteur 100 ou échelon de programme acheteur, l'option d'avance automatique ne peut pas être réactivée pour ce programme ou pour l'échelon. [00184] Les règles d'avance automatique pour un programme acheteur spécifique sont accessibles par le biais d'une interface utilisateur de l'administrateur de ce programme. Les règles d'avance automatique comprennent les détails du traitement, critères de sélection des offres de vente et sélection de la date d'avance automatique. Comme noté ci-dessus, l'avance automatique peut être réglée sur « on » ou « off ». Si l'avance automatique est réglée sur « on », et si une règle de date d'échéance est active, toutes les autres règles sont assujetties à la règle de la date d'échéance, ce qui signifie que si la règle entre en conflit avec la règle de date d'échéance, c'est la règle de date d'échéance qui prime. [00185] Les critères de sélection d'offre de vente comprennent le montant minimal, montant maximal, sélection par montant d'obligation de paiement et sélection par numéros d'obligation de paiement. Lorsqu'un montant minimal est précisé, le système 10 ne créera pas 109 d'offre de vente avec un montant inférieur au montant minimal précisé. Lorsqu'un montant maximal est précisé, le système 10 ne créera pas d'offre de vente qui excède le montant maximal précisé. [00186] Le critère de sélection de date permet à l'utilisateur fournisseur 108 de déterminer l'âge des obligations de paiement à inclure dans l'offre de vente. L'âge se base sur le nombre de jours avant l'échéance de l'obligation de paiement. Les critères de sélection comprennent « n'importe quel jour » (n'importe quelle date de transaction), « seulement les obligations de payement arrivant à échéance entre » (un nombre de jours configurable) ou « entre » (une période de dates configurable). La sélection de dates d'avance automatique entre certains jours fournit un calendrier de planification qui s'ouvre pour sélectionner les dates afin de spécifier la période. La sélection peut également être effectuée par les montants d'obligation de paiement dans un intervalle de prix, ou définie par les numéros d'obligation de paiement. [00187] La sélection de dates de planification pour l'avance automatique prévoit que le réglage de la (des) date(s) planifiée(s) pour l'avance automatique ait lieu aux dates sélectionnées pour l'avance automatique. Une fenêtre du calendrier de planification s'ouvre pour permettre une sélection des dates. [00188] La possibilité de planifier l'avance automatique permet à l'utilisateur de régler l'avance automatique en fonction des options « Initier le financement » ou « Examiner ». Si l'avance automatique est réglée sur « initier », l'offre de vente est soumise immédiatement après l'exécution du processus d'avance automatique. Si l'avance automatique est réglée sur « examiner », l'offre de vente n'est pas soumise automatiquement, mais elle est conservée pour examen et l'utilisateur peut annuler ou soumettre l'offre de vente. Une tâche et une alerte avisent le fournisseur 108 si l'avance automatique a créé une offre de vente et émet une alerte pour chaque programme acheteur 100. [00189] Les règle de calcul des intérêts au niveau du programme acheteur déterminent la date utilisée par le système 10 pour le calcul des intérêts (taux total, c'est-à-dire taux de base FI, marge FI, taux du fournisseur de services et taux du gestionnaire de communauté) pour une transaction. La date de transaction du paiement est la date par défaut, et elle a pour effet le calcul de l'intérêt à la date de transaction par le système 10. Toutefois, il est possible, de sélectionner la date réelle du paiement, qui prévoit que l'intérêt soit calculé un nombre de jours spécifique après la date de transaction. Ceci nécessite de saisir le nombre de jours après la transaction, de telle sorte que le système puisse calculer l'intérêt. [00190] L'utilisateur a la possibilité de modifier les informations financières du programme, telles que la marge de communauté brute, les frais du fournisseur de services (vue seulement), la marge de communauté nette, les frais de transaction du fournisseur, les frais de transaction FI, les jours limites minimaux de transaction, les jours limites maximaux de transaction, la réserve, le compte sur marges, le compte de compensation des échéances, l'affichage des taux, le profil fiscal et le montant minimal et maximal de l'offre de vente. [00191] Les frais de transaction sont également définis au niveau du programme acheteur. Les frais du fournisseur de services sont dérivés du profil de prix de la communauté attribué à la communauté 112 à laquelle le programme acheteur 100 appartient. Les frais du fournisseur de services sont les points de base établis par le fournisseur de services. Le montant est estimé (des estimations peuvent être requises lorsque les frais du fournisseur de 111 services sont appliqués à des échelons sur la base du volume de transaction) et basé sur les échelons de prix du fournisseur de services. Les échelons de prix du fournisseur de services sont établis par le fournisseur de services par le biais de la fonctionnalité du profil de prix du module du fournisseur de services 20. [00192] La marge de communauté nette est soit calculée en points de base (marge de communauté brute (GCM) - points de base du fournisseur de services) ou entrée en tant que points de base. [00193] Les frais optionnels de transaction du fournisseur et de transaction FI sont des montants fixes par transaction et sont imputés au moment de la transaction. [00194] Les jours limites minimaux de transaction pour une offre de vente sont également un paramètre du programme acheteur. Le système 10 validera le nombre de jours avant l'échéance des obligations de paiement comprises dans une offre de vente avant de le générer dans une offre de vente. Les dates d'échéance des obligations de paiement dans une transaction doivent être au-delà du jour où la transaction a lieu, plus ce nombre de jours limites. Les obligations de paiement qui tombent dans les jours limites ne sont pas disponibles à la transaction et ne sont pas visibles sur la page des obligations disponibles au financement. Dans un paramétrage, les jours limites minimaux sont réglés sur les jours principaux de pré-échéance. Les jours principaux de pré-échéance spécifient le nombre de jours avant l'échéance de l'acheteur pour lesquels le système 10 générera des instructions de paiement. [00195] Les jours limites maximaux de transaction sont introduits dans la case indiquée. Le système 10 atteste que le nombre de jours avant l'échéance (à partir de la date de transaction) de toute obligation de paiement est inférieur ou égal à cette valeur avant de les afficher sur l'écran des obligations disponibles au financement. Lorsqu'un programme acheteur a des obligations de paiement qui ont des échéances de fournisseur, ce paramètre sera de préférence réglé sur zéro. [00196] La réserve pour le programme acheteur 100 peut être sélectionnée (oui) ou pas (non). Lorsqu'un programme acheteur a des obligations de paiement qui ont des échéances de fournisseur, ce paramètre sera de préférence réglé sur zéro. Toutefois, si le paramètre est actif, un montant (dollar ou autre devise) ou un pourcentage est entré dans la case si la réserve est sélectionnée. Le montant ou pourcentage est défini sur une base mensuelle, de telle sorte que la réserve peut changer tous les mois. Il convient de préciser que la fonctionnalité de réserve se combine avec les notes de crédit pour éviter que l'acheteur 106 ne passe à un solde net négatif avec ses fournisseurs 108 à cause de la transaction. La réserve permet de retenir un montant ou un pourcentage des obligations de paiement pour un fournisseur 108 afm qu'il ne soit pas négocié. Le montant non-négocié est utilisé pour contrebalancer les notes de crédit qui pourraient venir pendant le mois pour ce fournisseur 108. [00197] Un montant minimal requis pour une transaction peut être sélectionné au niveau du programme acheteur. Si un montant minimal est saisi, aucune offre de vente inférieure à ce montant ne peut être soumise. Lorsqu'un programme acheteur a des obligations de paiement ayant des échéances de fournisseur, les options du montant minimal et du montant maximal (ci-dessous) ne seront, de préférence, pas sélectionnées. [00198] Un montant maximal requis pour une transaction peut être sélectionné, même si lorsqu'un programme acheteur a des obligations de paiement ayant des échéances de 113 fournisseur, ce paramètre ne sera, de préférence, pas utilisé ou est désactivé. Si un montant maximal est saisi, aucune offre de vente supérieure à ce montant ne peut être soumise. [00199] Le programme acheteur définit comment les institutions financières sont sélectionnées pour recevoir les offres de vente lorsque de multiples institutions financières sont disponibles. Dans le paramétrage actuellement décrit, les méthodes de distribution disponibles sont rotatives ou manuelles. Il convient de préciser que pour des programmes acheteur 100 de l'institution financière 110 unique, l'option rotative devrait être sélectionnée. La sélection de l'option manuelle a pour effet que le gestionnaire de communauté 120 devient responsable de l'attribution des offres de vente aux institutions financières 110 spécifiques. Il convient également de noter que dans ce paramétrage, même si ce n'est pas nécessaire, l'option rotative peut uniquement être changée dans un programme acheteur 100 initial ou par défaut--le premier programme acheteur 100 entré pour l'acheteur 106--par le biais de l'interface 212 du programme d'achat (la figure 4). Les échelons 214 du programme acheteur ultérieur--ceux basés sur le programme acheteur 100 par défaut--hériteront de cette valeur à partir de la valeur par défaut. Fournisseur de services [00200] La figure 5 est un diagramme illustrant les caractéristiques de la page web 300 du fournisseur de services du programme acheteur. Une page d'accueil 302 du fournisseur de services du programme acheteur permet d'effectuer les tâches en rapport avec le programme acheteur 100. A partir d'une interface 304 de fournisseur de services, un fournisseur de services 20 peut ajouter des communautés 112, ajouter des acheteur 106 à une communauté 112, ajouter le programme acheteur 100 par défaut pour le nouvel acheteur 106, configurer les paramètres en rapport avec le système du programme acheteur, ajouter des institutions financières 110, ajouter des fournisseurs 108 au programme acheteur 100 et visualiser et gérer les applications des comptes bancaires. [00201] De manière plus spécifique, le fournisseur de services 20 peut ajouter des communautés 112, visualiser des détails de communauté par le biais d'une interface de communauté 306, visualiser et approuver les candidatures 324 des fournisseurs, gérer les fournisseurs 108 et gérer les institutions financières 110. [00202] À partir de l'interface de communauté 306, le fournisseur de services 20 peut accéder à une liste 308 d'acheteurs de la communauté et à une liste 320 du FI dans la communauté. À partir d'une liste 308 d'acheteurs de la communauté, le fournisseur de services 20 peut désactiver un (des) acheteur(s), ajouter des acheteurs au 310, visualiser les détails de l'acheteur et accéder à une liste 312 du programme acheteur. À partir de la liste 312 du programme acheteur, le fournisseur de services 20 peut effectuer un ajout de programme acheteur 314, accéder au programme acheteur 316 (gestion des fournisseurs), accéder aux règles commerciales du programme acheteur et effectuer la configuration 318 du système du programme acheteur. La gestion des fournisseurs 108 par le biais de l'interface du programme acheteur 316 (gestion des fournisseurs) permet au fournisseur de services 20 d'ajouter des fournisseurs, de désactiver des fournisseurs, de voir et de modifier les fournisseurs, de mettre à jour les renvois des fournisseurs et les comptes bancaires restreints. À partir de la liste 320 du FI dans la communauté, le fournisseur de services 20 peut désactiver les institutions financières 110 et ajouter des institutions fmancières à la communauté au 322. 115 [00203] Une interface de visualisation des candidatures des fournisseurs 324 permet au fournisseur de services 20 de visualiser les informations du fournisseur et d'activer les fournisseurs 108. Le fournisseur de services 20 gère les fournisseurs 108 grâce à une interface 326 de la liste de fournisseurs et une interface 328 d'ajout de fournisseurs. Le fournisseur de services 20 gère les institutions financières 110 grâce à une interface 330 de la liste du FI et une interface 332 d'ajout du FI. [00204] Un paramètre « ouverture de la fenêtre d'offre d'achat » précise l'heure de la journée à laquelle les offres d'achat sont disponibles pour le programme acheteur. Un paramètre « fermeture de la fenêtre de l'offre d'achat » précise l'heure de la journée à laquelle les offres d'achat ne sont plus disponibles à l'achat pour la journée. Un paramètre « durée limite totale de l'offre d'achat » précise la durée (traditionnellement en heures) avant laquelle une offre d'achat aura expiré, et il est mesuré à partir du moment où un fournisseur 108 soumet l'offre. Cette durée peut comprendre l'attente de la distribution par le gestionnaire de la communauté de l'offre de vente, ainsi que l'approbation de l'institution financière 110. Un paramètre « durée limite FI de l'offre d'achat » précise le nombre d'heures avant lequel une offre d'achat expire en attendant l'approbation de l'institution financière 110. Lorsque le programme acheteur a des obligations de paiement ayant des dates d'échéance de fournisseur, les paramètres de durée limite peuvent être désactivés, ou réglés sur une durée suffisamment longue pour garantir raisonnablement l'acceptation de l'offre par une institution financière. Gestion des comptes bancaires [00205] La figure 6 est un diagramme illustrant les caractéristiques de la page web 400 de gestion des comptes bancaires. Elle fournit l'accès à une liste 404 de banques et aux fonctions d'activation des comptes bancaires 410 par le biais du menu déroulant bancaire de la page d'accueil 302 du fournisseur de services. Ces fonctions permettent d'effectuer les tâches en rapport avec les comptes bancaires. [00206] Les comptes bancaires font partie intégrante du fonctionnement du programme acheteur 100. A moins que les comptes bancaires ne soient activés pour chaque membre de la communauté, le membre reste en attente. Chaque entité gère ses propres comptes bancaires ; toutefois, la validation et l'activation de ces comptes dans le SCF système 10 est contrôlé par le fournisseur de services 20. [00207] Sur la page 404 de la liste des banques, le fournisseur de services 20 peut mettre à jour le SWIFT et voir les détails de la banque. Sur la page 406 des détails de la banque, le fournisseur de services 20 peut mettre à jour le SWIFT et modifier les détails de la banque 408. [00208] Sur la page 410 des listes de comptes bancaires de passage, le fournisseur de services 20 peut activer des comptes bancaires, allouer une banque à un compte 412, éditer le profil des comptes bancaires et visualiser les données concernant la société. Avant l'activation, certaines banques peuvent demander à obtenir de plus amples informations sur le profil du compte bancaire. Ces comptes sont des comptes bancaires établis comme des comptes clients et de compensation à échéance. Si le fournisseur de services 20 est satisfait des informations saisies, le compte bancaire doté du lien hypertexte « activer » pourra être immédiatement activé. En cas de doute sur l'exactitude des données, le fournisseur de services 20 peut effectuer une recherche dans une liste des banques existantes afin de déterminer si la banque existe déjà. Si elle existe (banques validées 414), elle pourra alors être associée au nouveau 117 compte. Ce dernier portera le numéro d'acheminement de la banque associée. Le profil des comptes bancaires pourra être modifié à partir de la page de profil du compte bancaire 416. Institution financière [00209] La figure 7 est un schéma des diverses fonctionnalités de la page Internet de l'institution financière 500. La page d'accueil de l'institution financière 502 permet de procéder aux tâches de gestion des portefeuilles liés aux institutions financières 110. Il faut noter que, dans chaque programme d'acheteur 100, il devra au moins y avoir une institution financière active (110), afin que le programme de l'acheteur 100 puisse être activé. [00210] Un utilisateur de FI peut accéder à une liste des acheteurs 501, des portefeuilles actifs 510 et des portefeuilles disponibles 512. La liste des acheteurs 501 permet d'accéder aux informations détaillées concernant les relations acheteurs 110/devises des institutions financières, notamment sur les obligations à échéance, les portefeuilles et l'historique des acheteurs. [00211] La liste des portefeuilles actifs 510 permet d'accéder aux informations concernant le taux des programmes d'acheteur, les honoraires, la limite de crédit de notoriété, le crédit de notoriété, la gestion des programmes et de désactiver les programmes d'acheteurs 100. L'utilisateur peut accéder au détail concernant le programme actif 506 et modifier les informations concernant le programme d'acheteur de la FI 100 à l'aide d'un programme d' édition 508. [00212] La liste des portefeuilles disponibles 512 donne accès à tous les nouveaux programmes d'acheteurs 100 proposés à l'institution financière 110. Ils sont proposés par un animateur de communauté 120 qui ajoutera l'institution financière 110 à un programme d'acheteur 100. L'utilisateur de l'institution financière 110 peut accepter un programme d'acheteur disponible 100 via la liste de portefeuilles disponibles 512. [00213] La page d'accueil de l'institution financière donne accès aux données de synthèse des portefeuilles de l'institution financière 110. Un portefeuille comprend tous les acheteurs qui ont bénéficié d'un financement de l'institution financière 110. La synthèse des portefeuilles donne une vue d'ensemble sur toutes les combinaisons acheteurs/devises et fait état de la limite de crédit totale engagée, du total du crédit utilisé, du crédit total disponible, de la moyenne des échanges commerciaux par jour, du cumul mensuel de la marge à ce jour, de la marge du mois précédent et du cumul annuel de marge à ce jour. [00214] Le programme d'acheteur permet de définir si l'institution financière acceptera manuellement de vendre les offres ou si le système les acceptera automatiquement au nom de l'institution financière au moment où le système lui présentera les offres. Les règles d'acceptation automatique permettent de contrôler le montant et les diverses caractéristiques d'une offre de vente qui sera automatiquement acceptée par l'institution financière 110. Il est possible d'activer et de désactiver ces règles d'acceptation automatique. Une institution financière peut décider d'activer l'acceptation automatique pour les offres de vente reçues au cours d'une période spécifique ou, par exemple, d'accepter automatiquement toutes les offres de vente déclenchées par une règle d'avancement automatique à échéance. Lorsque l'acceptation automatique est activée, le système accepte les offres d'achat au nom de l'institution financière à une heure spécifique du jour où l'offre a été faite. [00215] A partir de la page d'accueil de l'institution financière, l'utilisateur peut accéder au menu déroulant « pupitre de négociation » qui affichera alors un écran à partir duquel 119 l'utilisateur pourra manuellement accepter les offres d'achat. La colonne « Total des offres » donnent les informations concernant le nombre total d'offres de vente avec fonds acceptés soumises à l'institution financière. La colonne « Total de nouvelles offres » donne des informations sur les offres que l'institution financière n'a pas encore vu. L'institution financière peut accepter ou rejeter une offre donnée en cochant l'une des cases de la rangée qui contient les informations concernant l'offre souhaitée et en activant respectivement le bouton « accepter » ou « refuser ». L'activation de ce bouton met à jour le statut de l'offre dans le système 10 comme étant acceptée ou rejetée, en fonction du bouton activé. Fournisseur [00216] En activant le menu déroulant « financement » (non illustré) de la page d'accueil d'un fournisseur, l'écran 552 représenté dans l'illustration 8 apparaît et donne une estimation des financements mis à la disposition du fournisseur en question, triés par devises. Le « taux » est une combinaison du taux de base de l'institution financière, de la marge de l'institution financière, du taux du fournisseur de services et du taux de l'animateur de communauté. Le « nombre de PO » fait état du nombre et de la valeur des obligations de paiement. Le « nombre de CM » représente le nombre de notes de crédit et leurs valeurs respectives. Le fournisseur peut saisir un montant dans la case « financement souhaité » et activer le bouton « créer une offre de vente ». Le système 10 recherche alors, pour ce fournisseur, les obligations de paiement qui peuvent être financées et ayant les frais d'escompte les plus bas, créant ainsi une offre aussi proche que possible du montant souhaité, tout en facturant le moins d'intérêts possible. En cochant la case « négociation », qui active à son tour le bouton « créer une offre de vente », l'utilisateur incite le système à créer une offre de vente en utilisant toutes les obligations de paiement disponibles. « Synthèse par date » permet à l'utilisateur de visualiser les obligations de paiement par date et de traiter les transactions par date d'échéance. En se reportant à la figure 15-E(3A), l'écran de synthèse par date regroupe les obligations de paiement par date. Chaque rangée représente une date et identifie le nombre d'obligations de paiement arrivant à échéance à cette date. « Date d'échéance » fait référence à la période restante entre la date d'échéance et la date du jour. Le système émet une note de crédit et procède à des provisions (traitées ci-dessous). Il affiche ensuite la somme des notes de crédit et des retenues qui en découlent dans des colonnes respectives. La somme des obligations de paiement du jour, déduite de la somme des notes de crédit et des provisions, représente ce qui est mis à disposition pour financer le montant. Les honoraires projetés sont le total du taux de base et la marge de le FI, du taux de fournisseur de service et le taux de l'animateur de la communauté, appliqués au nombre de jours affichés dans « nombre de jour à échéance », la différence étant affichée dans « règlement projeté ». En cochant une case dans la colonne la plus à gauche, l'utilisateur peut sélectionner des obligations de paiement à une date donnée pour négociation. [00217] « Détails PO » (dans la figure 8) permet à l'utilisateur de voir chacune des obligations de paiement disponibles à la négociation et de sélectionner des obligations de paiement pour une offre individuelle, telles que représentées dans l'illustration 10. La figure 10 divise les informations représentées dans la figure 9 en obligations de paiement individuelles, sauf si une obligation de paiement est détenue, elle n'apparaîtra pas dans la figure 10 même si elle comprend un des nombres des obligations de paiement reflétées pour ce jour dans la colonne « nombre de PO » de la figure 9. La case à cocher de la colonne la plus à 121 gauche de la figure 10 permet à l'utilisateur de sélectionner individuellement des obligations de paiement pour négociation. [00218] Après activation du bouton « créer une offre de vente » de la page 552 (ou l'écran des figures 9 ou 10), le système présente un écran affichant le détail de l'offre de vente demandée. A l'activation du bouton « confirmer offre de vente », le système conclut l'offre de vente qui devient alors irrévocable. En activant la case « désélectionner », l'offre de vente en attente est retirée. Le taux de remise projeté représente le montant que le fournisseur devra payer pour la négociation si elle a lieu à ce moment. [00219] Egalement disponible à partir du menu déroulant « financement » de la page d'accueil du fournisseur (non illustré), le système présente un écran qui fournit des informations détaillées sur les précédentes offres de vente du fournisseur. La recherche d'offres de vente peut se faire sur des critères temporels. De même, une page d'historique d'obligation de paiement et de notes de crédit est disponible à partir du menu déroulant de financement de la page d'accueil du fournisseur. [00220] A partir du menu « rapports » de la page d'accueil du fournisseur (non illustré), le fournisseur peut accéder à un écran 556 qui fournit des informations supplémentaires sur les obligations de paiement sous forme de rapport. Une date de transaction est la date à laquelle la négociation a eu lieu, si l'obligation de paiement est négociée ou la date à laquelle le paiement a été effectué lorsque l'obligation de paiement n'a pas été négociée. La date d'entrée en vigueur est la date de paiement, que l'obligation de paiement ait été négociée ou pas. La date initiale de la facture est la date fournie par l'acheteur lorsque les données sont téléchargées. Même si elle se situe en dehors de l'opération du système 10, la date est probablement la date de la facture sous-jacente. Acheteur [00221] La fonction que l'acheteur 106 exécute dans le paramétrage d'un programme d'acheteur 100 consiste à paramétrer les fonctionnalités de gestion de programme, comprenant également le paramétrage de dates d'échéance valables et de règles de paramétrage automatiques. [00222] Pour accéder à la page de paramétrage des dates d'échéance, l'acheteur 106 sélectionne l'option « paramétrer les dates d'échéance » à partir du menu déroulant de gestion de programme d'acheteur sur une barre de navigation (non illustrée). Les paramètres de devise, fuseaux horaires et d'échéance sont représentés pour le programme d'acheteur respectif 100. Les acheteurs 106 qui ont établi des dates d'échéance d'acheteur pour le paiement des obligations de paiement du fournisseur 108 peuvent utiliser l'option de date d'échéance réglée pour saisir les dates d'échéance respectives de l'acheteur. Les obligations de paiement qui ont été téléchargées dans le système 10 sont validées pour assurer que les dates d'échéance de l'acheteur d'obligation de paiement sont validées en fonction des dates sélectionnées. [00223] La fonction de calendrier illustrée pour sélectionner une date d'échéance de l'acheteur spécifique ne fonctionne pas comme le calendrier de planification précédemment utilisé. La dates sans échéance sont paramétrées par le fournisseur de service 20 et comprend les jours fériés et les weekends. Les dates d'échéance valables sont paramétrées par l'acheteur 106 à l'aide du calendrier pour sélectionner des dates d'échéance du système valables désignées. 123 [00224] Au cours du téléchargement des obligations de paiement, les restrictions du calendrier sur les dates d'échéance paramétrées par l'acheteur 106 (c-à-d l'acheteur identifie les dates de weekend et de jours fériés, qui dans une exécution ne sont pas des dates d'échéance valables) sont utilisées pour valider les dates d'échéances du fournisseur et de l'acheteur sur les obligations de paiement. Les obligations de paiement rejetées au cours du processus de téléchargement apparaissent dans la liste d'obligations de paiement rejetés. Il faut noter que l'acheteur devra sélectionner les restrictions qui couvrent une période couvrant au moins quatre-vingt-dix jours à partir de la date actuelle. Cela dit, l'acheteur peut paramétrer des restrictions de calendrier dans le futur immédiat, dans la mesure où ces restrictions s'étendent également à au moins quatre-vingt-dix jours. Il faut noter que le réglage par défaut sur la page de date d'échéance est initialement réglé sur « aucune date d'échéance spécifique ». Pour paramétrer des restrictions spécifiques, l'utilisateur utilise une fonction de calendrier et saisit des dates spécifiques, à nouveau de préférence pour une période s'étendant à au moins quatre-vingt-dix jours dans le futur. [00225] On peut cesser de valider une date d'échéance en sélectionnant l'option « aucune échéance spécifique » puis en sélectionnant l'option « soumettre » pour sauvegarder les modifications. Il faut noter que les utilisateurs doivent encore corriger les dates d'échéance de toutes les obligations de paiement précédemment rejetées même s'il ont désélectionné l'option « date d'échéance spécifique ». [00226] Pour accéder à la page de correction automatique des dates d'échéance, l'acheteur 106 sélectionne l'option « correction automatique des dates d'échéance » à partir du menu glissant de gestion du programme d'acheteur sur la barre de navigation (non illustré). L'acheteur 106 a la possibilité de paramétrer des règles lui permettant de corriger automatiquement les dates d'échéance du fournisseur et de l'acheteur au moment où une obligation de paiement ou une note de crédit est téléchargée dans le système 10. L'acheteur 106 peut paramétrer la correction automatique des obligations de paiement avec des dates d'échéance rejetées qui sont préalables à la première date d'échéance valable lors du téléchargement ou pour régler la correction automatique des obligations de paiement avec des dates d'échéance qui tombent sur des dates d'échéance non valables dans le futur ou les deux. [00227] En outre, l'acheteur 106 peut configurer une correction automatique des notes de crédit avec des dates d'entrée en vigueur préalables à la première date d'entrée en vigueur valable lors du téléchargement ou régler la correction automatique des notes de crédit avec des dates d'entrée en vigueur qui tombent sur des dates d'entrée en vigueur futures non valables ou les deux. [00228] L'acheteur 106 sélectionne les case à cocher « passé » ou « futur » à partir des options des dates d'échéance des obligations de paiement rejetées. La sélection de l'option « passé » permettra de corriger automatiquement les obligations de paiement ayant une date d'échéance d'acquisition préalable à la prochaine date d'échéance valable. En sélectionnant l'option « futur » l'utilisateur sera tenu de sélectionner la manière dont il appliquera les dates d'échéance corrigées automatiquement soit à la date d'activité valable la plus proche, une date d'activité préalable ou une date d'activité valable future. [00229] L'acheteur 106 sélectionne les case à cocher « passé » ou « futur » des options des dates d'entrée en vigueur des notes de crédit rejetées. En sélectionnant l'option « passé », les notes de crédit rejetées seront automatiquement corrigées avec une date d'entrée en vigueur 125 préalable à la prochaine date d'entrée en vigueur valable. En sélectionnant l'option « futur », l'utilisateur devra sélectionner la manière dont il appliquera les dates de maturité automatiquement corrigées (soit à la date d'activité valable la plus proche, une date d'activité préalable ou une date d'activité valable future). Fonctionnalités supplémentaires du programme d'acheteur [00230] Fixer la marge nette de la communauté. L'animateur de la communauté 120 a la capacité de fixer la valeur de la marge nette de la communauté (NCM) à une valeur spécifique qui résulte en une marge brute de communauté valable (GCM) correspondant à la tarification tierce du fournisseur de services approprié utilisée. Une case à cocher « fixe » est disponible à côté de la case de texte NCM sur l'onglet de paramètres du paramétrage du programme d'acheteur. Ceci permet de fixer la valeur NCM et empêche le système 10 de changer à nouveau la valeur. La boîte de dialogue de NCM devient un champ de saisie obligatoire si la case « fixe » est sélectionnée. Lors du paramétrage d'une NCM spécifique sur ON (marche), le GCM est égal aux honoraires du fournisseur de service plus la valeur de NCM fixée. Lors de la fixation de la valeur de la NCM en sélectionnant la case à cocher ON (marche), la case de saisie GCM devra généralement être désactivée. La GCM est ensuite calculé automatiquement. [00231] Marge brute de la communauté saisie. Si la NCM est paramétrée sur OFF (arrêt), la case de texte de GCM est un champ de saisie requis et la case de texte NCM est désactivée. L'utilisateur doit saisir la marge brute de la communauté qui est égale à ou supérieure aux honoraires du fournisseur de service. Le système 10 calcule ensuite automatiquement la NCM : la marge nette de la communauté est égale à la marge brute de la communauté moins les honoraires du fournisseur de service. Il faut noter que lorsque le taux bloqué de la tarification totale du fournisseur (TPS) est sélectionné, la case à cocher ON du NCM est désactivée. [00232] Compte de compensation. Un compte de compensation est utilisé par l'acheteur 106 pour les obligations à échéance. Sur la page des paramètres du programme des acheteurs, une saisie de compte de compensation à échéance est disponible et utilisée pour les obligations à échéance généralement détenues par l'acheteur 106. Les transactions de paiement aux fournisseurs 108 et aux institutions financières 110 pour les obligations à échéance passent par ce compte de compensation. [00233] Devise du programme de l'acheteur par défaut Le système 10 permet au fournisseur de service 20 de sélectionner la devise au niveau du programme d'acheteur par défaut. Les tiers du programme de l'acheteur 214 (variations de la valeur par défaut) sont dans la même devise que le programme d'acheteur par défaut 100. Le système 10 permet tout nombre de programmes d'acheteur par défaut 100 par devise, et permet de multiples programmes d'acheteur 214 par programme d'acheteur par défaut 100. Un acheteur 106 peut avoir tout nombre de devises et les tiers du programme de l'acheteur 214 de la valeur par défaut sont dans la même devise que la valeur par défaut. Les tiers de programmes d'acheteur 214 ne donnent pas à l'utilisateur l'option de sélectionner la devise mais affichent plutôt la devise du programme d'acheteur par défaut 100. Une fois la devise établie pour le programme d'acheteur 100, elle ne peut être modifiée. [00234] Un fournisseur 108 peut appartenir à plus d'un programme d'acheteur par défaut 100 par acheteur 106. Etant donné qu'un fournisseur 108 peut facturer un acheteur 106 dans 127 différentes devises (par exemple européenne et canadienne) le fournisseur 108 peut appartenir à plusieurs programmes d'acheteur par défaut 100. Le fournisseur 108 ne peut pas appartenir à deux tiers de programmes d'acheteur différents 214 du même programme d'acheteur par défaut 100. Un fournisseur 108 peut uniquement être déplacé entre les programmes d'acheteur qui sont des tiers de programme d'acheteur 214 d'un programme d'acheteur par défaut 100. Ils ne peuvent pas être déplacés entre des programmes d'acheteur par défaut 100. [00235] Par le biais de la page d'accueil de l'animateur de communauté (la figure 5), l'animateur de communauté 120 peut définir la devise des comptes de compensation et de marge bancaires. Tous les comptes bancaires sont définis par devise. Le système 10 permet uniquement à ce qu'un compte de compensation avec la même devise que le programme d'acheteur 100 lui soit associé. Un animateur de communauté 120 n'est pas habilité à associer un compte bancaire de compensation qui n'a pas la même devise que le programme d'acheteur 100. Le programme d'acheteur 100 peut avoir un compte de compensation avec les obligations à échéance qui peuvent être détenues par l'acheteur 106. Toute institution financière sur un programme d'acheteur doit avoir un second compte de compensation dans lequel les fonds permettant de payer les négociations ayant lieu chaque jour sont conservés. Cela permet de garder deux types de transactions bien distinctes. [00236] La capacité de procéder à la tarification du fournisseur et d'allouer les taux aux institutions financières. Le programme de l'acheteur 100 a la capacité de procéder à la tarification du fournisseur, ainsi que la capacité d'allouer des taux aux institutions financières 110. Le page de la liste du programme de l'acheteur contient une liste de programmes d'acheteurs 100 associés à un acheteur sélectionné 106. A partir de la liste de programmes d'acheteur, l'animateur de la communauté 120 peut rechercher et trouver les programmes d'acheteur 100, voir le détails du programme de l'acheteur, désactiver les programmes de l'acheteur 100 et ajouter des programmes d'acheteur 100. La page des listes de programmes d'acheteur est accessible à partir de la page d'accueil ou de la page de liste d'acheteurs de la communauté. [00237] Méthodes de distribution d'offres d'achat pour les programmes d'acheteur. Deux méthodes de distribution pour les offres d'achat sont disponibles pour sélectionner à partir du programme de l'acheteur par défaut 100 de l'acheteur 106 uniquement au sein du module de la communauté. Elles sont rotationnelles et manuelles. Dans la méthodes de distribution rotationnelle, les offres d'achat sont immédiatement envoyées aux institutions financières 110 pertinentes après création par un fournisseur 108 et passent à la prochaine institution financière 110 dans l'ordre en cas de rejet ou de temporisation. Dans la méthode de distribution manuelle, les offres d'achat sont immédiatement envoyées à l'animateur de communauté 120 après création par un fournisseur 108. L'animateur de communauté 120 distribue les offres d'achat pertinentes aux institutions financières 110. Si l'offre d'achat est temporisée ou rejetée, elle retourne à l'animateur de communauté 120 pour redistribution. Si la méthode de distribution rotationnelle est sélectionnée (sur l'onglet de distribution du programme de l'acheteur 100), chaque institution financière 110 qui fait partie du programme d'acheteur 100 se voit allouer un ordre rotationnel (alloué par le système ou manuellement). Ceci permet d'assurer que les offres d'achat tournent entre les institutions financières 110 dans un ordre spécifique. 129 [00238] Institutions financières internes/externes La mise en valeur des liquidités d'autofinancement met à disposition une fonctionnalité qui permet à un département du trésor de l'acheteur 106 de « devenir » l'institution financière 100 et de financer leurs propres obligations de paiement. Ce nouveau type d'institution financière 110 est connu sous le nom de « FI interne ». Les institutions financières 110 réelles sont connues sous le nom de « FI externes ». [00239] Limite journalière d'échéance. La limite journalière d'échéance par acheteur 106 est surveillée pour empêcher l'institution financière 110 d'acheter des obligations de paiement supérieures au maximum journalier. Ceci aide à éviter que les institutions financières 110 ne dépassent des limites de crédit journalières. Par exemple, un acheteur dispose d'une limite de crédit de $1 million et d'une limite journalière de $100 000. Ainsi, l'acheteur ne souhaite pas dépasser $100 000 en un jour pour les obligations à échéance. Si un fournisseur 108 crée un offre de vente et que la limite journalière est atteinte, ces obligations de paiement sont rejetées pour les offres de vente qui dépassent la limite journalière. Si on empêche la négociation des obligations de paiement, le système donne la préférence aux obligations de paiement qui ont atteint la date d'échéance de leurs fournisseurs sur celles qui ne l'ont pas atteinte. Après avoir contrôlé si l'offre de paiement dépasse la limite de crédit total disponible pour l'offre de vente, la limite d'échéance journalière sera contrôlée. Si l'acheteur 106 dispose d'une limite d'échéance journalière réglée, le système 10 contrôle la date d'échéance de l'acheteur pour les obligation(s) de paiement sur une offre de vente, ajoute toutes les obligations de paiement avec la même date d'échéance de l'acheteur sur cette offre de vente et ensuite ajoute ce total à ce qui a été déjà acheté ce jour. Le système 10 compare ensuite ce total à la limite journalière afin de veiller à ce qu'elle ne soit pas dépassée. Si la limite est dépassée, l'utilisateur sera alerté que la limite est dépassée pour la date d'échéance de l'acheteur donné, la limite disponible et que les obligations de paiement pour cette date d'échéance seront retirées de l'offre de vente (favorisant les obligations de paiement qui ont atteint leurs dates d'échéance de fournisseurs). L'utilisateur peut annuler ou continuer. [00240] S'il décide de continuer, ces obligations de paiement sont retirées (de préférence tout d'abord les obligations de paiement qui n'ont pas atteint les dates d'échéance de fournisseur) et le système 10 vérifie la prochaine date. Le système 10 procédera jour après jour jusqu'à que l'offre de vente finale soit créée. [00241] Si l'utilisateur décide d'annuler, l'offre de vente ne sera pas créée et l'utilisateur pourra retourner à la feuille de travail afin de retirer les obligations de paiement et resoumettre afin de rester dans la disponibilité d'échéance journalière. [00242] Institution financière inter-communauté Le fournisseur de service 20 a la capacité d'affecter des institutions financières à travers les programmes d'acheteur 100 et les communautés 112. Une institution financière 110 peut appartenir à n'importe quel nombre de communauté 112 et nombre de programmes d'acheteurs 100 avec ces communautés 112. La seule exception à cette règle est lorsque l'institution financière 110 ne peut pas appartenir à plus d'un tiers de programmes d'acheteur 214 au sein d'un programme d'acheteur par défaut 100. [00243] Fournisseurs inter-communautés Le fournisseur de service 20 a la capacité d'affecter des fournisseurs 108 à travers plusieurs programmes d'acheteur 100 et de communautés 112. Un fournisseur 108 peut appartenir à plusieurs communautés 112 et à 131 plusieurs programmes d'acheteurs 100 avec ces communautés 112. La seule exception à cette règle est lorsque le fournisseur 108 ne peut pas appartenir à plus d'un tiers de programmes d'acheteur 214 au sein d'un programme d'acheteur par défaut 100. [00244] Communautés multiples avec la plateforme SCF Le fournisseur de services 20 a la capacité de configurer plusieurs communautés 112 pour prendre en charge les entités participantes sur la plateforme SCF. Chaque communauté 112 peut être composée d'un ou de plusieurs programmes d'acheteur 100. Les fournisseurs 108 et les institutions financières 110 peuvent appartenir à plusieurs programmes d'acheteur 100 au sein de plusieurs communautés 112 fournissant ainsi une plage complète de possibilités de configuration. Notes de crédit [00245] Comme il a été précédemment décrit, le système 10 peut accepter des notes de crédit qui peuvent réduire la valeur totale d'obligations de paiement au sein du système. Les notes de crédit sont téléchargées à partir du système ERP de l'acheteur et représentent les compensation par rapport aux obligations A/P créées entre l'acheteur et le vendeur en dehors du système 10. La validité de la compensation sous-jacente ne fait pas partie du système 10 ou de son fonctionnement. Les parties ont convenu que les notes de crédit peuvent être saisies dans le système pour offset les obligations de paiement et si les parties ne conviennent pas de la propriété d'une note de crédit donnée, ces problèmes sont résolus entre les partie en dehors de l'opération du système 10. [00246] Les données des notes de crédit pour une note de crédit donnée comprend l'identification de l'acheteur, l'identification du fournisseur, la devise, le montant et la date d'entrée en vigueur. La date d'entrée en vigueur est définie par l'acheteur et il s'agit de la date à laquelle la note est appliquée contre les obligations de paiement. Le système associe les notes de crédit aux programmes de l'acheteur de la même manière que les obligations de paiement (par identification de l'acheteur, devise et identification du fournisseur. [00247] Une fois chargée dans le système, une note de crédit reste active jusqu'à sa date d'entrée en vigueur. A cette date, le système contrôle les obligations de paiement non négociées de l'acheteur au fournisseur dans les programmes de l'acheteur (par ex qui ont des dates d'échéance) à la date d'entrée en vigueur de la note de crédit. Si le montant total de ces obligations de paiement est égal ou supérieur au montant total des notes de crédit, le système compense le total des notes de crédit avec les obligations de paiement (c-à-d réduit le montant des obligations de paiement) et génère des instructions de paiement pour payer au fournisseur le montant net (obligations de paiement moins les notes de crédit). [00248] A une date d'entrée en vigueur/d'échéance, si le montant total des obligations de paiement est inférieur au montant total des notes de crédit, donc sous une première option, le système change la date d'entrée en vigueur de toutes les notes de crédit ayant cette date d'entrée en vigueur au prochain jour ouvré. Le système modifie également la date d'échéance de l'acheteur des obligations de paiement arrivant à échéance ce jour au prochain jour ouvré. Cela dit, lorsqu'un groupe de notes de crédit et un groupe d'obligations de paiement ont la même date d'entrée en vigueur et date d'échéance de l'acheteur, respectivement et lorsque la valeur totale de l'obligation de paiement est inférieure à la valeur totale des notes de crédit, le système augmente la date d'entrée en vigueur des notes de crédit et celle des obligations de paiement de l'acheteur d'un jour ouvré. Lorsque le prochain jour ouvré arrive, le système répète cette procédure, pas uniquement avec les notes de crédit et les obligations de paiement 133 déplacées du jour ouvré précédent, mais également en prenant en considération toutes les notes de crédit et les obligations de paiement ayant une date d'entrée en vigueur et d'échéance de l'acheteur au prochain jour ouvré. Ce processus peut être répété, accumulant les notes de crédit et les obligations de paiement, jusqu'au jour où la valeur totale de l'obligation de paiement atteigne ou dépasse la valeur totale des notes de crédit. A ce stade, les notes de crédit accumulées réduisent le montant des obligations de paiement et un paiement est effectué de la manière décrite ci-dessus. [00249] Par exemple et en se reportant à la figure 11, il y a deux notes de crédit arrivant à échéance le 8 mai, mais il n'existe aucune obligation de paiement pour compenser les notes de crédit. Le système incrémente automatiquement les dates d'entrée en vigueur de ces notes de crédit au prochain jour ouvré, le 9 mai. Le système peut ensuite appliquer des notes de crédit sur des obligations de paiement arrivant à échéance le 9 mai, avec des notes de crédit supplémentaires avec cette date d'entrée en vigueur. La figure 12 affiche l'historique des notes de crédits et des obligations de paiement qui ont été avancées. [00250] Dans toutes les réalisations présentement décrites, le système fournit une seconde option avec laquelle au moins certaines notes de crédit peuvent être appliquées à une date d'entrée en vigueur à laquelle l'obligation de paiement totale est inférieure à la valeur totale des notes de crédit. A ce jour, le système identifie la ou les notes de crédit qui ont la date initiale d'entrée en vigueur la plus ancienne (car les notes de crédit peuvent avoir été avancées à de nouvelles dates d'entrée en vigueur, tel que décrit ci-dessus, certaines notes de crédit ayant la date d'entrée en vigueur présente peuvent avoir une date d'entrée en vigueur préalable). De cette ou ces notes de crédits, le système identifie la note de crédit ayant la valeur indépendante la plus grande. Si la valeur de cette note de crédit est supérieure à la valeur totale des obligations de paiement arrivant à échéance à ce jour, le système n'applique pas de note de crédit et fait passer les obligations de paiement au prochain jour ouvré. Cependant, si la valeur de la note de crédit est inférieure à la valeur totale des obligations de paiement à échéance, le système compense alors le montant des obligations de paiement par le montant de cette note de crédit. En réduisant le montant de l'obligation de paiement par le montant de la note de crédit, le système répète le processus, à l'exception de la note de crédit actuellement appliquée, en trouvant la note de crédit la plus ancienne/la plus importante et en l'appliquant (si possible) à la valeur de l'obligation de paiement restante arrivant à échéance à ce jour. Cette analyse se répète pour les notes de crédit restantes et génère un paiement en utilisant toutes les obligations de paiement et les notes de crédit appliquées. Les notes de crédit restantes sont déplacées au prochain jour. [00251] Dans une réalisation, l'acheteur peut régler une tolérance d'échéance pour les soldes négatifs nets à l'aide de la seconde option de note de crédit. Il s'agit d'un seuil de paiement maximum que l'acheteur est prêt à autoriser pour le paiement des obligations mentionnées plus haut et les notes de crédit appliquées. Tel que précédemment décrit, si la valeur de la note de crédit est inférieure à la valeur de la note de crédit à une date donnée, il arrive un moment, après avoir traité les notes de crédit auquel le système ne peut plus appliquer de notes de crédit à l'obligation de paiement à une date donnée. A ce stade, il y aura une valeur d'obligation de paiement restante. Si le montant total des obligations de paiement restantes avec cette date d'échéance acheteur est inférieur à ce seuil, le système autorise ces obligations de paiement à arriver à échéance et par conséquent traite le paiement de obligations 135 de paiement de la manière décrite dans les présentes. Cependant, les notes de crédit restantes sont déplacées au prochain jour. Si la valeur totale des obligations de paiement restantes est supérieure au seuil, les notes de crédit ainsi que les obligations de paiement sont incrémentées. [00252] La figure 13 représente un exemple de la seconde option de notes de crédit. Supposons que les notes de crédit de 1 à 5 se soient accumulées à une date d'entrée en vigueur présente du 20 avril. La figure 13 représente la date d'entrée en vigueur initiale pour chaque note de crédit et sa valeur. Le 20 avril, la valeur totale de l'obligation de paiement est de $6 000. Les notes de crédit 1 et 2 sont les plus anciennes. La note de crédit la plus importante est la 2, qui s'élève à $4 400. Etant donné que ce montant est inférieur au montant total des obligations de paiement ($6 000) la note de crédit 2 est appliquée à la valeur totale des obligation de paiement, laissant un solde de la valeur des obligations de paiement de $600. Le système essaie ensuite d'appliquer la note de crédit 1. Etant donné que sa valeur ($1 000) est inférieure à la valeur totale restante des obligations de paiement ($1 600), le système applique la note de crédit 1. La prochaine note de crédit la plus proche est du 13 avril, pour la note de crédit 3 Sa valeur est de $6 500. Etant donné qu'elle est supérieure à la valeur restante des obligations de paiement, la note de crédit 3 ne pourra pas être traitée. La prochaine note de crédit la plus proche est celle du 14 avril La note de crédit 4 a une plus grande valeur des notes de crédit à cette date, à $400. Etant donné que ce montant est inférieur au solde total des obligations de paiement restante, elle est appliquée à la valeur totale des obligation de paiement, réduisant la valeur des obligations de paiement à $200. La valeur des notes de crédit restante pour la note de crédit 5 est de $125. Etant donné que ce montant est inférieur à la valeur totale des obligations de paiement restantes, la note de crédit n°5 est arrivée à échéance et appliquée à la valeur des obligations de paiement, laissant un solde de la valeur des obligations de paiement de $75. Supposons que la tolérance d'échéance est réglée sur $100. Etant donné que la valeur des obligations de paiement restantes est inférieure au niveau de tolérance, le système fait arriver toutes les obligations de paiement et notes de crédit à échéance, mettant en vigueur le paiement de $75 au fournisseur. Si le solde des obligations de paiement restante était supérieur à $100, la date d'échéance de toutes les obligations de paiement et la date d'entrée en vigueur de toutes les notes de crédit seraient incrémentées au prochain jour ouvré. [00253] Dans les réalisations présentement décrites, l'acheteur peut désigner une obligation de paiement existante à laquelle appliquer une note de crédit donnée. Chaque obligation de paiement a une ID de référence par l'acheteur au moment du téléchargement du système ERP de l'acheteur. L'acheteur alloue de la même manière des ID de référence aux notes de crédit. Pour lier la note de crédit à une obligation de paiement, l'acheteur télécharge un enregistrement (au moment du téléchargement de la note de crédit pertinente) répertoriant l'ID de la note de crédit et l'ID de l'obligation de paiement. Au moment du téléchargement, le système vérifie que l'obligation de paiement associée n'est toujours pas non négociée et n'est pas arrivée à échéance et est d'une valeur supérieure ou égale à la note de crédit. Si ces trois critères sont satisfaits, le système applique la note de crédit à l'obligation de paiement désignée, réduisant ainsi sa valeur certifiée par le montant de la note de crédit. Si l'un de ces critères n'est pas respecté, le système ignore la relation entre la note de crédit et l'obligation de paiement et traite la note de crédit comme toute autre note de crédit à cette date d'entrée en vigueur, tel que décrit ci-dessus. 137 [00254] Les notes de crédit ont également un effet sur la négociation des obligations de paiement, au moins en ce qui concerne les obligations de paiement ayant une date d'échéance à la date ou après la date d'entrée en vigueur d'une note de crédit donnée. Pour toute note de crédit donnée, les obligations de paiement ayant des dates d'échéance préalables à la date d'entrée en vigueur de la note de crédit peuvent être négociées sans regard à la note de crédit. Les notes de crédit peuvent cependant éviter la négociation des obligations de paiement avec des dates d'échéance ou après les dates d'entrée en vigueur des notes de crédit à moins que le système ne dispose de suffisaient d'obligations de paiement pour couvrir les notes de crédit. [00255] En se reportant à la figure 14, par exemple, le fournisseur voit les obligations de paiement qui arriveront à échéance le 14 novembre. Etant donné que la date d'échéance de la première note de crédit est le 15 novembre, le fournisseur peut négocier les deux obligations de paiement arrivant à échéance le 14 novembre. [00256] En ce qui concerne les négociations, le système associe les notes de crédit aux obligations de paiement sur la base des dates. Supposons par exemple que deux notes de crédit aient une date d'entrée en vigueur donnée et que plusieurs obligations de paiement arrivent à échéance à la même date. Le système compare la valeur de la première note de crédit avec les obligations de paiement. Le fournisseur peut décider d'appliquer les obligations de paiement par ordre ascendant ou descendant. S'il choisit l'ordre descendant, le système contrôle la valeur de la note de crédit à l'obligation de paiement la plus grande arrivant à échéance ce jour. Si sa valeur est égale ou supérieure à la valeur de la note de crédit, le système déduit le montant de la note de crédit de la valeur de l'obligation de paiement. S'il s'agit de la seule note de crédit avec cette date d'entrée en vigueur, l'obligation de paiement sera également disponible au fournisseur pour négociation, avec la valeur réduite. Etant donné qu'il y a une autre note de crédit ce jour, cependant, le système appliquera la valeur de la note de crédit à la valeur de l'obligation de paiement. Si la valeur restante de l'obligation de paiement est supérieure à la valeur de la seconde note de crédit, les deux notes de crédit sont imputées sur l'obligation de paiement et cette dernière est disponible à la négociation, à sa valeur réduite. Si la valeur restante de l'obligation de paiement est inférieure au montant de la seconde note de crédit, le système applique la note de crédit à cette valeur restante et déplace à la prochaine plus grande obligation de paiement pour satisfaire le solde restant de la note de crédit, traitant les obligations de paiement suivantes jusqu'à le faire. Si la valeur de l'obligation de paiement totale est inférieure à la valeur totale de la note de crédit pour ce jour, alors toutes ces obligations seront retenues et le solde restant de la note de crédit passera au prochain jour ouvré pour être pris en considération pour déterminer si les obligations de paiement sont disponibles à la négociation au prochain jour ouvré. De cette manière, si les notes de crédit entrent en vigueur au jour auquel aucune obligation de paiement n'arrive à échéance, les notes de crédit sont appliquées simplement, pour des raisons de négociations à la prochaine obligation de paiement arrivant à échéance. [00257] En se reportant à la figure 15, par exemple, l'obligation de paiement du 10 mai peut être négociée sans considération des notes de crédit. Cependant, l'obligation de paiement du 11 mai sera déduite des deux notes de crédit entrant en vigueur le 11 mai. [00258] Tel que noté, le fournisseur peut décider d'appliquer les notes de crédit aux obligations de paiement à une date donnée, pour des raisons de négociation, par ordre ascendant, ce qui signifie que les notes de crédit sont initialement associées à l'obligation de 139 paiement la plus petite arrivant à échéance à cette date, et ensuite aux obligations de paiement plus importantes. Par exemple et en se reportant à la figure 16, il n'existe aucune note de crédit entrant en vigueur le 7 mai, avec sept obligations de paiement arrivant à échéance. La valeur de la note de crédit et celle des obligations de paiement sont fournies dans la colonne « valeur » et l'imputation de la note de crédit sur les obligations de paiement est fournie dans la colonne « valeur imputée de la note de crédit ». Le système impute tout d'abord la note de crédit à l'obligation de paiement 227533 puis à l'obligation de paiement 227571 et enfin à l'obligation de paiement 227536. Tel qu'indiqué dans la dernière colonne à gauche, le système retient ces trois obligations de paiement qui sont disponibles à la négociation. Le solde restant de la note de crédit, 4 558,60 DKK, est inférieur à la valeur de la prochaine plus grande obligation de paiement, c-à-d l'obligation de paiement 227641. Ce solde restant est par conséquent imputé à l'obligation de paiement 641, qui est disponible à la négociation au montant réduit. Un exemple similaire suit dans la figure 16 pour les éléments entrant en vigueur et arrivant à échéance le 8 mai. La figure 17 donne le même exemple, où le fournisseur sélectionne une application des notes de crédit aux obligations de paiement par ordre décroissant. [00259] Dans les réalisations présentement décrites, le système permet la négociation d'une note de crédit qui est divisée entre les obligations de paiement uniquement si ces dernières arrivent à échéance le même jour. Par défaut, le système retient uniquement les obligations de paiement auxquelles les notes de crédit divisent entre les différents jours sont imputées. Dans l'exemple décrit ci-dessus, lorsque le total des obligations de paiement à une date donnée est inférieur à la somme des notes de crédit, de manière à ce qu'une partie de la note de crédit soit portée en diminution d'une obligation de paiement un jour après, suppose que la note de crédit soit débitée en contrepartie d'une obligation de paiement d'une valeur supérieure du montant de la note de crédit transitoire. Sous le réglage par défaut, le système retient l'obligation de paiement, même s'il s'agit du montant disponible restant. Cependant, dans la cas où l'acheteur télécharge ensuite les obligations de paiement à la date d'échéance initiale, de manière la somme des obligations de paiement à cette date est supérieure au total des notes de crédit et que le système puisse allouer toutes les notes de crédit à la date initiale aux obligations de paiement arrivent à échéance, le système réalloue la note de crédit aux obligations de paiement à la date initiale, et l'obligation de paiement au jour d'après, précédemment détenue, pourra alors être traitée. En outre, lorsqu'une obligation de paiement est détenue de par l'allocation d'une note de crédit sur plusieurs jours, le solde restant de l'obligation de paiement est imputé à la réserve. [00260] Par exemple et en se reportant à la figure 18, au 26 avril, la valeur du crédit est supérieure à la valeur de l'obligation de paiement. La valeur du crédit est par conséquent reportée au 27 avril. Etant donné que la valeur de la note de crédit est étalée sur plusieurs dates d'échéance, l'obligation de paiement sur laquelle est imputée la valeur de la note de crédit (53545) ne pourra pas être traitée. Le solde restant (1 750 EUR) est reflété dans la colonne de la valeur détenue. [00261] La restriction sur les notes de crédit imputées sur plusieurs dates d'échéance ne s'applique pas aux programmes d'acheteur autofinancés, si le fournisseur décide de traiter toutes les obligations de paiement soumises à la note de crédit divisée datant du même jour. Dans une configuration autofinancée, le système remplace automatiquement une des dates 141 d'échéance de l'obligation de paiement par la date de la transaction. Ainsi, si un fournisseur d'un programme d'acheteur autofinancé décide de traiter toutes les obligations de paiement soumises à une note de crédit divisée le même jour, toutes les obligations auront la même date d'échéance, évitant ainsi de diviser l'échéance. [00262] Au sein d'un processus plus avancé, l'utilisateur peut configurer un programme d'acheteur en activant l'option « autoriser le mouvement des obligations de paiement au cours de la transaction » afin de pouvoir traiter les obligations de paiement soumises aux notes de crédit divisées. Si le fournisseur sélectionne ce type d'obligation de paiement pour la traiter, le système remplace la date d'arrivée à échéance de l'acheteur de chacune des obligations de paiement à zéro auxquelles la note de crédit est imputée par la date d'arrivée à échéance de l'obligation de paiement partiellement réduite. Ainsi, toutes les obligations de paiement soumises à la note de crédit divisée datant du même jour ont maintenant la même date d'échéance. Par conséquent, le système traite l'obligation de paiement partiellement réduite avec les obligations de paiement à zéro. En se reportant à la figure 19, par exemple, au 26 avril, la valeur de la note de crédit est supérieure à la valeur de l'obligation de paiement. La valeur du crédit est par conséquent reportée au 27 avril. Etant donné que l'option « autoriser le mouvement de l'obligation de paiement au cours de la transaction » est activée, l'obligation de paiement sur laquelle est partiellement imputée la valeur de la note de crédit (obligation de paiement 53545) peut être traitée. Si le fournisseur traite cette obligation de paiement, le système modifie les dates d'échéance de toutes les obligations de paiement à zéro du 26 avril au 27 avril et il en va de même pour les dates d'entrée en vigueur des notes de crédit. [00263] Avant le calcul des honoraires, la valeur des notes de crédit est soustraite de la valeur de l'obligation de paiement. Cela dit, lorsqu'une note de crédit est portée en diminution d'une obligation de paiement, le montant de la note de crédit est déduit du montant certifié de l'obligation de paiement. [00264] Rapport des notes de crédit. La figure 20 est un exemple d'écran des critères du rapport des notes de crédit, tel qu'indiqué dans 555. Egalement indiqué dans 555, la figure 21 est un exemple d'écran des résultats obtenus avec le rapport des notes de crédit. [00265] Les documents des notes de crédit sont soumis à une date d'entrée en vigueur et une date de soumission. Dans les options de sélection d'une plage de dates, le terme « Dates des notes de crédit » apparaît à proximité des boutons radio afin de sélectionner l'un des éléments suivants : date d'entrée en vigueur, date de soumission, date initiale d'entrée en vigueur, date d'imputation ou date d'échéance. [00266] L'option « Inclure info sur PO et date d'entrée en vigueur/échéance » permet à l'utilisateur de voir dans les résultats du rapport, non seulement les données des notes de crédit mais également celles des obligations de paiement. [00267] Si cette option est active, le système affichera alors le numéro ou la date d'échéance des obligations de paiement. Si la note de crédit se voit attribuer une date d'échéance plutôt qu'une transaction, elle n'inclut pas de numéro d'obligation de paiement. La date appliquée, la date d'échéance et le montant appliqué sont implémentés alors que le champ de la date initiale reste vide. Réserve 143 [00268] Lorsqu'un programme d'acheteur comprend des obligations de paiement avec des dates d'échéance fournisseur, la fonction de réserve peut être désactivée, ou n'être tout simplement pas utilisée. Au cours d'autres processus, elle peut cependant être utilisée malgré les dates d'échéance fournisseur, avec les parties qui entendent que certaines obligations de paiement risquent de ne pouvoir être traitées par dates d'échéance fournisseurs. La fonctionnalité de réserve se combine avec les notes de crédit afin d'empêcher que l'acheteur 106 n'acquière un solde négatif net avec les fournisseurs 108 à traiter. La fonctionnalité de réserve permet au système 10 de configurer un pourcentage ou un montant de réserve, ou une combinaison des deux, et ce, par mois afin de réserver certaines obligations de paiement pour un fournisseur 108 donné et d'empêcher leur négociation. Si la combinaison des deux est utilisée, le système réserve le montant le plus élevé qui résultera en l'utilisation du pourcentage d'un montant fixé pour un mois donné. Les montants et les pourcentages de réserves configurés peuvent être les mêmes pour tous les mois ou être différents pour chaque mois. Le montant de l'obligation de paiement non traitée ou réservée est utilisé pour compenser les notes de crédit entrantes pour ce fournisseur 108. Supposons par exemple qu'un acheteur 106 détient E500 000 de crédit-fournisseur. Ensuite, avant l'échéance, il découvre qu'ils dispose de E50 000 de crédits. Si le fournisseur 108 a traité l'intégralité des E500 000, l'acheteur détiendra alors E50 000 de plus qu'il ne souhaite. En ayant une réserve de 10 %, cela permettra de retenir E50 000. Etant donné que E50 000 n'ont pas été traités, ces fonds pourront compenser les crédits. [00269] Réserves et disponibilités du financement La réserve s'applique lors du calcul de montant mise à disposition pour le financement. Elle est utilisée pour les transactions plutôt qu'avec les obligations arrivant à échéance et restreint uniquement le traitement des obligations. [00270] Réserves et notes de crédit La fonctionnalité de réserve fonctionne avec les notes de crédit. Elle s'exécute généralement suite à l'application de la note de crédit. Lorsque l'utilisateur atteint l'écran des disponibilités de financement, et que le système 10 calcule la valeur disponible, le système calcule également la réserve. A partir de l'onglet sur le détail de la note de crédit, en appliquant les notes de crédit par ordre croissant plutôt que décroissant, la réserve se voit être de nouveau appliquée. Une obligation de paiement qui a été provisionnée, ne peut plus être réservée, à cause de la manière dont les notes de crédit ont été appliquées. Par exemple, une obligation de paiement réservée peut atteindre E0,00 car la nouvelle note de crédit est en cours d'exécution et ne peut plus être réservée. [00271] En outre, la réserve de paiement est uniquement appliquée par ordre croissant. Elle commence au début du mois et s'exécute vers le bas, imputant ainsi les obligations de paiement les plus proches dans le temps avant de passer aux obligations de paiement plus tardives. Un fournisseur 108 ne peut procéder à un calcul de réserve décroissant à partir de la fin du mois. Ainsi, la réserve commence généralement à la date du jour et progresse vers la fin du mois. Une fois que le calcul de réserve atteint la première date ayant des obligations de paiement disponibles, la provision se fait par ordre croissant. Le calcul de la réserve prend en considération les obligations de paiement les plus petites puis progresse vers les obligations de paiement plus importantes, avec l'objectif d'imputer les obligations de paiement les moins importantes et de laisser les obligations de paiement les plus importantes en négociation. 145 [00272] Période de réserve La période de réserve s'applique généralement à un mois calendaire et le montant de la réserve est calculée pour cette période. Si le montant de réserve calculé n'est pas utilisé pour cette période, il ne s'applique généralement pas aux autres périodes. [00273] Par exemple, si la réserve de janvier s'élève à E10 000, l'intégralité de la réserve est de E10 000. Si aucune réserve n'est faite au cours du mois de janvier, ou qu'aucun crédit n'est reçu, le solde de E10 000 n'est pas reporté à février mais expire plutôt à la fin du mois (janvier). [00274] Cependant, si les notes de crédit ne sont pas utilisées dans une période donnée (ou mois), elles n'expirent pas mais sont reportées au mois suivant. Si la note de crédit est reportée au mois suivant, elle sera imputée à la réserve de ce mois. [00275] Pourcentage ou montant. Tel que précédemment mentionné, la réserve peut être basée sur un pourcentage calculé ou un montant spécifique des obligations de paiement chargées. Si l'utilisateur spécifie un pourcentage calculé et un montant spécifique, le plus grand des deux sera alors utilisé comme réserve. [00276] Par exemple, l'utilisateur choisit 10% et E10 000 pour la réserve. Si une obligation de paiement de E1 000 est chargée, la réserve sera de E10 000 (10% de E1 000 est égal à E100, donc la valeur la plus grande de E10 000 représentera la réserve). Cependant, si la réserve est configurée sur E10 000, mais qu'aucun pourcentage n'a été spécifié, le système réserve E10 000 et ne procède à aucun calcul de pourcentage. De même, si la réserve est configurée sur 10%, la réserve s'élève alors à E100. [00277] Le pourcentage prend en considération tous les chargements des obligations de paiement du mois qui ont une date d'échéance au cours du mois en question. Si la réserve est de 10% pour janvier, elle sera alors de 10% pour tous les chargements du mois de janvier arrivant à échéance en janvier. Ainsi, si des obligations de paiement arrivant à échéance en janvier sont chargées le 15 janvier, le système utilisera la date d'échéance du ler au 31 janvier pour calculer le pourcentage de 10%. [00278] Il faut noter que le calcul de la réserve est basé sur la valeur initiale des obligations de paiement plutôt que sur la valeur certifiée. Une note de crédit dédiée par l'acheteur à une obligation de paiement spécifique (tel que traité précédemment) diminue la valeur certifiée et engendrerait le mauvais calcul du pourcentage de réserve. [00279] Imputation de la réserve. Lorsque le montant total des notes de crédit chargées au cours de la période mensuelle est égal ou supérieur au montant de la réserve spécifié, l'engagement de la réserve est alors considéré comme étant satisfait pour la période en question. Le montant de la réserve est alors configuré à zéro. [00280] Par exemple, si la réserve de janvier s'élève à E10 000 et que E2 000 de notes de crédit sont chargées, la réserve s'élèvera alors à E8 000. Mais si E10 000 de notes de crédit sont chargées, la réserve sera alors de zéro pour ce mois. Le montant des notes de crédit est basé sur la date d'entrée en vigueur de la note de crédit, et non pas sur la date de chargement ou de soumission. Si les notes de crédit de février sont chargées en janvier, elles seront imputées sur la réserve du mois de février et non pas de janvier. Il faut noter que cette imputation de la réserve comprend tous les montants des notes de crédit, c'est à dire les notes de crédit simples et celles dédiées aux obligations de paiement. 147 [00281] Les réserves sont configurées dans le module de la communauté. La figure 22 représente un exemple d'écran de visualisation des paramètres du programme d'acheteur. Le montant de la réserve est maintenu par l'animateur de communauté 120 au nom de l'organisation acheteuse. Une réserve peut être spécifiée dans tous les programmes d'acheteur 100 ou tiers et peut s'appliquer ou non à tous les tiers. [00282] Le programme d'acheteur 100 comporte un champ de « réserve » qui peut être configuré par tout tiers. Tous les fournisseurs 108 se trouvant dans le tiers obtiennent ensuite cette réserve. Le champ de réserve peut être activé ou non (Oui ou Non dans la figure 22). Si le champ de réserve est activé, deux champs seront mis à disposition pour saisir le pourcentage et le montant correspondants à chaque mois. L'utilisateur peut saisir des valeurs dans un ou deux champs. La valeur la plus importante sera sélectionnée comme montant de réserve. [00283] Le montant de la réserve peut si nécessaire être modifié et prend immédiatement effet. Par exemple, quelques instants après un changement du montant de la réserve, un utilisateur qui se trouve sur l'écran des disponibilités de financement verra les effets des nouveaux montants. [00284] La réserve pour un mois n'est pas proratisée. L'intégralité de la réserve représente plutôt la valeur d'un mois donné. [00285] Traitement restreint des réserves d'une obligation de paiement. Une obligation de paiement ne peut être traitée si une réserve a été portée en diminution de l'obligation de paiement sur la feuille de travail. Cela est vrai même s'il s'agit d'une diminution partielle. Par exemple, une réserve de E1 imputée sur une obligation de paiement de E1 000 fera que E1 000 sera en réserve. [00286] Réserve appliquée uniquement à des factures négociables. Une réserve s'applique uniquement aux obligations de paiement se trouvant sur la feuille de travail. Elle ne peut s'appliquer à une obligation de paiement non négociable qui se trouve sur la feuille de travail. [00287] Modifications de l'écran des disponibilités de financement L'utilisateur peut accéder au montant de réserve au niveau des pages d'estimation de financement, de synthèse chronologique et des détails des obligations de paiement. [00288] La réserve est calculée par mois. Par exemple, si au ler janvier la réserve est de E10 000 per mois et que des obligations de paiement arrivent à échéance en janvier, février et mars, la réserve sera de E30 000 (en supposant qu'il n'y ait aucune note de crédit). La réserve utilise E10 000 par mois plutôt que E30 000 au début janvier. [00289] Lorsque des notes de crédit sont chargées dans le système 10, l'imputation se fait sur le montant de la réserve et le montant disponible pour le mois est réduit. [00290] Suite à l'imputation des notes de crédit, le solde de la réserve est imputé sur les factures du mois par ordre croissant. Une fois que le système atteint la première date ayant une obligation de paiement de disponible, les réserves se font par ordre croissant et sont imputées jusqu'à que leur solde soit égal à zéro. Une obligation de paiement avec une réserve n'est pas négociable. [00291] Le montant de la réserve imputé pour une obligation de paiement rentre dans la valeur appliquée de la réserve. L'utilisateur voit cette valeur tant qu'il ne peut traiter l'obligation de paiement de par la réserve. 149 [00292] Liste de clients fournisseurs La colonne de réserve dans la liste de fournisseurs indique si une réserve est active ou non. Si la réserve est active, l'écran affiche le pourcentage, le montant ou les deux. [00293] Liste de clients acheteurs La colonne de réserve dans la liste de fournisseurs acheteurs indique si une réserve est active ou non. Si la réserve est active, l'écran affiche le pourcentage, le montant ou les deux. [00294] Avancement automatique Le processus d'avancement automatique fait appel aux mêmes règles de calcul et d'imputation de la réserve que le processus de négociation manuelle. Ce processus calcule la réserve puis l'impute en suivant les mêmes règles (en imputant les obligations de paiement retenues pour des notes de crédit divisées par date d'échéance d'acheteur et par la valeur certifiée la plus basse du mois). Une fois la réserve imputée, le système détermine les obligations de paiement négociables restantes qui seront avancées automatiquement en fonction des paramètres d'avancement automatique établis. [00295] Même si un programme d'acheteur ne dispose pas de réserve et si une obligation de paiement est retenue par une note de crédit, le montant restant de l'obligation de paiement (lorsqu'une obligation de paiement est retenue suite à la répartition d'une note de crédit sur plusieurs dates d'échéance d'acheteur) sera reflété dans la valeur de réserve à la fois de la synthèse des notes de crédit et de l'onglet du détail des notes de crédit. Ceci assure l'exactitude du montant du financement (la valeur de l'obligation de paiement diminuée de la valeur de la réserve est égale à la disponibilité de financement). [00296] Par exemple, supposons que le programme d'acheteur d'un fournisseur, détaillé dans les figures 24 et 25 dispose d'une réserve de 10 %. Au mois d'août, il y a près de 4,1 million de dollars en obligations de paiement et E168 000 de notes de crédit. La réserve est de E410 000, moins les E168 000 de notes de crédit existantes, laissant une réserve de E242 000. En réalité, le système a provisionné E266 000 car les obligations de paiement sont provisionnées dans leur intégralité. [00297] Dans cet exemple, un ensemble de notes de crédit s'étale sur deux dates d'échéance, le 15 et le 16 août. Etant donné que l'obligation de paiement fractionnée 248232 n'est pas négociable, la première réserve est imputée à cette obligation de paiement. Ensuite, le système commence à provisionner les obligations de paiement à la première échéance disponible à la négociation (10 août). Le système impute ensuite une réserve aux obligations de paiement datant du 13 août, par ordre croissant de montant, en commençant par l'obligation de paiement la moins élevée et continue ainsi jusqu'à ce que la valeur de la réserve soit atteinte (obligation de paiement 248262). La valeur de cette obligation de paiement (E25 000) sera alors supérieure à la différence entre la réserve calculée et la réserve imputée (E24 000), étant donné que l'intégralité du montant de l'obligation de paiement est réservée. En septembre, et en se référant aux figures 26 et 27, nous disposons de E192 000 en obligations de paiement et d'aucune note de crédit. La réserve de 10% s'élève à E19 000. Ce montant s'applique à une obligation de paiement unique et retient l'intégralité de l'obligation de paiement. [00298] En ce qui concerne la description détaillée qui suit des processus préférables de la présente invention, elle sera facilement comprise par les personnes disposant de compétences dans l'activité que la présente invention est susceptible d'élargir en termes d'utilité et d'application. Même si divers aspects ont été décrits dans le contexte d'un processus préféré, les aspects, fonctionnalités et méthodologies supplémentaires de présentation de cette invention 151 seront alors facilement discernables. Les processus et adaptations de la présente invention autres que ceux décrits dans les présentes, ainsi que diverses variations, modifications, dispositions et méthodologies équivalentes, seront apparents ou raisonnablement suggérés par la présente invention et la description suivante, sans s'éloigner de la substance ou du champ d'application de la présente invention. De plus, tout ordre et/ou ordre temporel des étapes des divers processus décrits et revendiqués dans les présentes sont ceux qui sont considérés être comme le meilleur mode contemplé pour reporter la présente invention. Il faut également comprendre que, même si les étapes des divers processus peuvent être présentés et décrits comme étant dans l'ordre préférable ou l'ordre temporel souhaité, il n'est pas obligatoire d'y procéder dans cet ordre, en absence d'une telle indication afin d'obtenir un résultat prévu particulier. Dans la plupart des cas, les étapes de ces processus peuvent être exécutées dans différents ordres ou séquences, tout en étant dans le champ d'application des présentes inventions. Certaines étapes peuvent également être exécutées simultanément. Par conséquent, même si la présente invention a été décrite ici en détail en termes des processus préférables, il faut comprendre que ce descriptif est à titre indicatif et d'exemple de la présente invention et est essentiellement donné afin de fournir une description complète et propre à la présente invention. La description suivante n'a pas pour but de limiter l'invention ou d'exclure de quelque manière que ce soit les processus, adaptations, variations, modifications ou dispositions équivalentes. Cette invention est uniquement limitée aux revendications y étant liées et équivalents.