FR3027708A1 - Gestion d'une chaine d'approvisionnement - Google Patents

Gestion d'une chaine d'approvisionnement Download PDF

Info

Publication number
FR3027708A1
FR3027708A1 FR1560076A FR1560076A FR3027708A1 FR 3027708 A1 FR3027708 A1 FR 3027708A1 FR 1560076 A FR1560076 A FR 1560076A FR 1560076 A FR1560076 A FR 1560076A FR 3027708 A1 FR3027708 A1 FR 3027708A1
Authority
FR
France
Prior art keywords
date
delivery
pgi
quantities
poli
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR1560076A
Other languages
English (en)
Inventor
James Alan Bielefeldt
Dhirendra Diwan
Timonthy L Horvath
John Joseph Vogt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Landmark Graphics Corp
Original Assignee
Halliburton Energy Services Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Halliburton Energy Services Inc filed Critical Halliburton Energy Services Inc
Publication of FR3027708A1 publication Critical patent/FR3027708A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/08Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/08Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083Shipping
    • G06Q10/0833Tracking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/08Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • G06Q10/0875Itemisation or classification of parts, supplies or services, e.g. bill of materials
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Game Theory and Decision Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Les données logistiques comprennent une pluralité d'envois, chacun comprenant des livraisons liées à un article de la ligne du bon de commande (POLI). Chacune des livraisons possède une quantité de livraison et une date de sortie de marchandises (PGI). Les données logistiques comprennent également une pluralité de services logistiques pour la pluralité des envois y compris les livraisons liées au POLI. Un envoi multi-mode comporte une pluralité de services logistiques séquentiels. Les données logistiques comprennent une pluralité de livraisons liée au POLI, dans laquelle une quantité de marchandises reçues (GR) et une date GR sont déterminés pour chaque livraison. Le processeur permet un affichage de la date PGI et de la date GR pour l'envoi multi-mode. Le processeur calcul la date de marchandises reçues (GR) pour un article de la ligne du bon de commande (POLI) basé sur les multiples envois liés au POLI et les multiples GR liés au POLI saisis dans un champ d'emplacement.

Description

Arrière-plan [0001] Les grandes entreprises qui ont une présence globale acquièrent des produits et des équipements de différentes sources et les envoient à leurs destinations finales dans le monde entier. Le suivi de ces produits et équipements du moment de l'achat jusqu'à l'utilisation finale est un défi.
Présentation du présent exposé Un procédé selon un ou plusieurs mode(s) de réalisation comprend : un processeur calculant la date de marchandises reçues (GR) pour un article de la ligne du bon de commande (POLI) basé sur les multiples envois liés au POLI et les multiples GR lié au POLI saisis dans un champ d'emplacement.
Un procédé selon un ou plusieurs mode(s) de réalisation comprend : l'identification de multiples livraisons liées à un article de la ligne du bon de commande (POLI), chacune des multiples livraisons ayant une quantité de livraison et une date de sortie de marchandise (PGI), chaque date PGI étant la date que les marchandises pour la livraison respective ont été physiquement déplacées d'un entrepôt vers une usine, les dates de PGI ayant un ordre ; l'identification de multiples envois chacun lié à une livraison, dans lequel chacun des multiples envois a une quantité d'envoi ; l'identification de multiples événements de marchandises reçues (GR) pour les multiples livraisons liées au POLI, où chacun des multiples événements GR a une quantité GR et une date GR, et où les dates GR ont un ordre ; l'identification d'une quantité requise pour le POLI; un processeur calculant un réseau GR Date 1 en : faisant correspondre les quantités de livraison liées à un POLI aux quantités GR des multiples événements GR liés au POLI, dans lequel la correspondance est ambiguë parce qu'au moins une partie des quantités de livraison liées au POLI est égale et au moins une partie des quantités GR liées au POLI est égale, la résolution de cette ambiguïté en donnant la préférence à l'alignement de l'ordre des dates de PGI par rapport à l'ordre des dates GR, pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, et la date GR pour chaque correspondance dans le réseau GR Date I le processeur calculant un réseau GR Date 2 en : totalisant les quantités de livraison des livraisons liées au même envoi, faisant correspondre les quantités de livraison totalisée aux quantités GR, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour le réseau GR Date 2 le processeur calculant un réseau GR Date 3 en : totalisant les quantités GR d'un groupe d'événements GR de sorte que la somme corresponde à une quantité de livraison de l'une des multiples livraisons, déterminant un maximum des dates GR à partir du groupe d'événements GR et en l'enregistrant sous forme de maximum GR date 3, changeant les dates GR des événements GR dans le groupe pour maximum GR date 3, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 3 ; le processeur calculant un réseau GR Date 4 en : totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities ; déterminer que la summed GR quantities est égale à la quantité requise pour le POLI, déterminer un maximum des dates GR à partir des multiples événements GR et l'enregistrer sous forme de maximum GR date 4, modifier les dates GR des multiples événements GR pour le maximum GR date 4, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 4 ; pour chaque envoi, détermination d'une ATA date comme l'heure réelle de l'arrivée de la cargaison. la détermination que la condition suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 1 > ATA Date et date GR de GR Date 1 > PGI Date) ; la détermination que la condition suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 2 > ATA Date et date GR de GR Date 2 > PGI Date) ; la détermination que la condition suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 3 > ATA Date et date GR de GR Date 3 > PGI Date) ; la détermination que la condition suivante est fausse pour au moins l'une des livraisons : il) (date GR de GR Date 4 > ATA Date et date GR de GR Date 4 > PGI Date) ; et la détermination, par conséquent, que le bon de commande est toujours ouvert. Un procédé selon un ou plusieurs mode(s) de réalisation comprend : l'identification de multiples livraisons liées à un article de la ligne du bon de commande (POLI), dans laquelle chacune des livraisons multiples a une quantité de livraison et 15 une date de sortie de marchandise (PGI), chaque date PGI étant la date à laquelle les marchandises pour la livraison respective ont été physiquement déplacées d'un entrepôt vers une usine, les dates PGI ayant un ordre ; l'identification de multiples envois chacun lié à une livraison, dans laquelle chacun des multiples envois a une quantité d'envoi ; 20 l'identification de multiples événements de marchandises reçues (GR) pour les multiples livraisons liées au POLI, où chacun des multiples événements GR a une quantité GR et une date GR, et où les dates GR ont un ordre ; l'identification d'une quantité requise pour le POLI; un processeur calculant un réseau GR Date 1 en : 25 faisant correspondre les quantités de livraison liées à un POLI aux quantités GR des multiples événements GR liés au POLI, dans lequel la correspondance est ambiguë parce qu'au moins une partie des quantités de livraison liées au POLI est égale et au moins une partie des quantités GR liées au POLI est égale, 30 la résolution de cette ambiguïté en donnant la préférence à l'alignement de l'ordre des dates de PGI par rapport à l'ordre des dates GR, pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, et la date GR dans le réseau GR Date I le processeur calculant un réseau GR Date 2 en : totalisant les quantités de livraison des livraisons liées au même envoi, faisant correspondre les quantités de livraison totalisée aux quantités GR, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour le réseau GR Date 2 le processeur calculant un réseau GR Date 3 en : totalisant les quantités GR d'un groupe d'événements GR de sorte que la somme corresponde à une quantité de livraison de l'une des multiples livraisons, déterminant un maximum des dates GR à partir du groupe d'événements GR et en l'enregistrant sous forme de maximum GR date 3, changeant les dates GR des événements GR dans le groupe pour maximum GR date 3, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 3 ; le processeur calculant un réseau GR Date 4 en : totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities ; déterminer que la summed GR quantities est égale à la quantité requise pour le POLI, déterminer un maximum des dates GR à partir des multiples événements GR et l'enregistrer sous forme de maximum GR date 4, modifier les dates GR des multiples événements GR pour le maximum GR date 4, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 4 ; pour chaque envoi, détermination d'une ATA date comme l'heure réelle de l'arrivée de la cargaison ; détermination que la condition GRDATE1 suivante est vraie pour au moins l'une des livraisons : (date GR de GR Date 1 > ATA Date et date GR de GR Date 1 > PGI Date) ; et la définition d'une date GR pour chacune de l'au moins une livraison pour laquelle la condition GRDATE1 est vraie par rapport à la date GR respective pour la livraison dans le réseau GR Date 1. Un procédé selon un ou plusieurs mode(s) de réalisation comprend : l'identification de multiples articles de livraisons liées à un article de la ligne du bon de commande (POLI), chacune des multiples articles de livraisons ayant une quantité de livraison d'article et une date de sortie de marchandise (PGI), chaque date PGI étant la date à laquelle les marchandises pour l'article de livraison respective ont été physiquement déplacées d'un entrepôt ou une usine, les dates de PGI ayant un ordre ; l'identification de multiples envois, dans laquelle chacun des multiples envois a une quantité d'envoi, dans laquelle chaque envoi est lié à une livraison, chaque livraison est liée à un article de livraison, et au moins une des livraisons est liée à une pluralité d'articles de livraison ; l'identification de multiples événements de marchandises reçues (GR) pour les multiples articles de livraisons liés au POLI, où chacun des multiples événements GR a une quantité GR et une date GR, et où les dates GR ont un ordre ; l'identification d'une quantité requise pour le POLI; un processeur calculant un réseau GR Date 1 en : faisant correspondre les quantités d'article de livraison liées aux POLI aux quantités GR des multiples événements GR liés au POLI, où la correspondance est ambiguë parce qu'au moins une partie des quantités d'article de livraison liée au POLI est égale et au moins une partie des quantités GR liée au POLI est égale, la résolution de cette ambiguïté en donnant la préférence à l'alignement de la commande des dates de PGI à la commande des dates de GR, et pour chaque article de livraison, l'enregistrement de la quantité d'article de livraison, la date PGI pour la quantité d'article de livraison, et la date GR pour chaque correspondance dans le réseau GR Date 1 ; le processeur calculant un réseau GR Date 2 en : totalisant les quantités d'article de livraison des articles de livraisons liées au même envoi, faisant correspondre les quantités d'article de livraison totalisée aux quantités GR, et pour chaque livraison, l'enregistrement de la quantité d'article de livraison totalisée, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour le réseau GR Date 2 ; le processeur calculant un réseau GR Date 3 en : totalisant les quantités GR d'un groupe d'événements GR de sorte que la somme corresponde à une quantité d'article de livraison de l'une des multiples livraisons, déterminant un maximum des dates GR à partir du groupe d'événements GR et en l'enregistrant sous forme de maximum GR date 3, changeant les dates GR des événements GR dans le groupe pour maximum GR date 3, et pour chaque livraison, l'enregistrement de la quantité d'article de livraison, la date PGI pour la quantité d'article de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 3 ; le processeur calculant un réseau GR Date 4 en : totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities ; déterminer que la summed GR quantities est égale à la quantité requise pour le POLI, déterminer un maximum des dates GR à partir des multiples événements GR et l'enregistrer sous forme de maximum GR date 4, changer les dates GR des multiples événements GR au maximum GR date 4, pour chaque article de livraison, enregistrement de la quantité d'article de livraison, la date PGI pour la quantité d'article de livraison, la quantité GR totalisée, et la date GR changée dans le réseau GR Date 4 ; pour chaque envoi, détermination d'une ATA date comme l'heure réelle de l'arrivée de la cargaison ; déterminer que la condition GRDATE1 suivante n'est pas vraie pour au moins l'un des articles de livraison : (date GR de GR Date 1 > ATA Date et date GR de GR Date 1 > PGI Date) ; déterminer que la condition GRDATE2 suivante est vraie pour au moins l'une des livraisons (date GR de GR Date 2 > ATA Date et date GR de GR Date 2 > PGI Date) ; et la définition de la date GR pour chacune des livraisons pour laquelle la condition GRDATE2 est vraie pour la date GR respective dans le réseau GR Date 2. Un procédé selon un ou plusieurs mode(s) de réalisation comprend : l'identification de multiples livraisons liées à un article de la ligne du bon de commande (POLI), dans laquelle chacune des livraisons multiples a une quantité de livraison et une date de sortie de marchandise (PGI), chaque date PGI étant la date à laquelle les marchandises pour la livraison respective ont été physiquement déplacées d'un entrepôt vers une usine, les dates PGI ayant un ordre ; l'identification de multiples envois chacun lié à une livraison, où chacun des multiples envois a une quantité d'envoi ; l'identification de multiples événements de marchandises reçues (GR) pour les multiples livraisons liées au POLI, où chacun des multiples événements GR a une quantité GR et une date GR, et où les dates GR ont un ordre ; l'identification d'une quantité requise pour le POLI; un processeur calculant un réseau GR Date 1 en : faisant correspondre les quantités de livraison liées à un POLI aux quantités GR des multiples événements GR liés au POLI, dans lequel la correspondance est ambiguë parce qu'au moins une partie des quantités de livraison liées au POLI est égale et au moins une partie des quantités GR liées au POLI est égale, la résolution de cette ambiguïté en donnant la préférence à l'alignement de la commande des dates de PGI à la commande des dates de GR, et pour chaque livraison, l'enregistrement de la quantité de livraison, la PGI de la quantité de livraison, la quantité GR, et la GR pour chaque correspondance dans le réseau GR Date 1 ; le processeur calculant un réseau GR Date 2 en : totalisant les quantités de livraison des livraisons liées au même envoi, faisant correspondre les quantités de livraison totalisée aux quantités GR, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour le réseau GR Date 2 le processeur calculant un réseau GR Date 3 en : totalisant les quantités GR d'un groupe d'événements GR de sorte que la somme corresponde à une quantité de livraison de l'une des multiples livraisons, déterminant un maximum des dates GR à partir du groupe d'événements GR et en l'enregistrant sous forme de maximum GR date 3, changeant les dates GR des événements GR dans le groupe pour maximum GR date 3, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la 15 quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 3 ; le processeur calculant un réseau GR Date 4 en : totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities ; 20 déterminer que la summed GR quantities est égale à la quantité requise pour le POLI, déterminer un maximum des dates GR à partir des multiples événements GR et l'enregistrer sous forme de maximum GR date 4, modifier les dates GR des multiples événements GR pour le maximum GR date 4, 25 et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 4 ; pour chaque envoi, détermination d'une ATA date comme l'heure réelle de l'arrivée de la 30 cargaison ; la détermination que la condition GRDATE1 suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 1 > ATA Date et date GR de GR Date 1 > PGI Date) ; la détermination que la condition GRDATE2 suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 2 > ATA Date et date GR de GR Date 2 > PGI Date) ; la détermination que la condition GRDAIE3 suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 3 > ATA Date et date GR de GR Date 3 > PGI Date) ; et définir une date GR pour chacune de l'au moins une livraison pour laquelle la condition GRDATE3 est vraie pour la date GR respective pour la livraison dans le réseau GR Date 3. Un procédé selon un ou plusieurs mode(s) de réalisation comprend : l'identification de multiples livraisons liées à un article de la ligne du bon de commande (POLI), dans laquelle chacune des livraisons multiples a une quantité de livraison et une date de sortie de marchandise (PGI), chaque date PGI étant la date à laquelle les marchandises pour la livraison respective ont été physiquement déplacées d'un entrepôt vers une usine, les dates PGI ayant un ordre ; l'identification de multiples envois chacun lié à une livraison, où chacun des multiples envois a une quantité d'envoi ; l'identification de multiples événements de marchandises reçues (GR) pour les multiples livraisons liées au POLI, où chacun des multiples événements GR a une quantité GR et une date GR, et où les dates GR ont un ordre ; l'identification d'une quantité requise pour le POLI; un processeur calculant un réseau GR Date 1 en : faisant correspondre les quantités de livraison liées à un POLI aux quantités GR des multiples événements GR liés au POLI, dans lequel la correspondance est ambiguë parce qu'au moins une partie des quantités de livraison liées au POLI est égale et au moins une partie des quantités GR liées au POLI est égale, la résolution de cette ambiguïté en donnant la préférence à l'alignement de l'ordre des dates de PGI à l'ordre des dates de GR, et pour chaque livraison, l'enregistrement de la quantité de livraison, la PGI de la quantité de livraison, la quantité GR, et la GR pour chaque correspondance dans le réseau GR Date I ; le processeur calculant un réseau GR Date 2 en : totalisant les quantités de livraison des livraisons liées au même envoi, faisant correspondre les quantités de livraison totalisée aux quantités GR, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour le réseau GR Date 2 le processeur calculant un réseau GR Date 3 en : totalisant les quantités GR d'un groupe d'événements GR de sorte que la somme corresponde à une quantité de livraison de l'une des multiples livraisons, déterminant un maximum des dates GR à partir du groupe d'événements GR et en l'enregistrant sous forme de maximum GR date 3, changeant les dates GR des événements GR dans le groupe pour maximum GR date 3, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 3 ; le processeur calculant un réseau GR Date 4 en : totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities ; déterminer que la summed GR quantities est égale à la quantité requise pour le POLI, déterminer un maximum des dates GR à partir des multiples événements GR et l'enregistrer sous forme de maximum GR date 4, modifier les dates GR des multiples événements GR pour le maximum GR date 4, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 4 ; pour chaque envoi, détermination d'une ATA date comme l'heure réelle de l'arrivée de la cargaison ; la détermination que la condition GRDATE1 suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 1 > ATA Date et date GR de GR Date 1 > PGI Date) ; la détermination que la condition GRDATE2 suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 2 > ATA Date et date GR de GR Date 2 > PGI Date) ; la détermination que la condition GRDATE3 suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 3 > ATA Date et date GR de GR Date 3 > PGI Date) ; la détermination que la condition GRDATE4 suivante est vraie pour au moins l'une des livraisons : (date GR de GR Date 4 > ATA Date et date GR de GR Date 4 > PGI Date) ; et la définition de la date GR pour chacune de l'au moins une livraison pour laquelle la condition GRDATE4 est vraie pour la date GR respective pour la livraison dans le réseau GR Date 4. Un procédé selon un ou plusieurs mode(s) de réalisation comprend : un processeur recevant et stockant des données logistiques concernant un article de la ligne de bon de commande (POLI), les données logistiques comprenant : une pluralité d'envois, chaque envoi comprenant des livraisons liées à un article de la ligne du bon de commande (POLI), dans laquelle chaque livraison comporte : une quantité de la livraison, et une date de sortie de marchandises (PGI) ; une pluralité de services logistiques pour la pluralité des envois comprenant des livraisons liées au POLI, l'un de la pluralité des envois, un envoi multi-mode, ayant une pluralité de services logistiques séquentiels ; une pluralité de livraisons liées au POLI, dans laquelle les éléments suivants sont déterminés pour chacune des livraisons : une quantité de marchandises reçues (GR), et une date GR; le processeur permettant un affichage de la date PGI et de la date GR pour l'envoi multimode ayant une pluralité de modes de transport. Dans un ou plusieurs mode(s) de réalisation, le processeur recevant et stockant des données logistiques concernant le POLI comprend la réception des données provenant des fournisseurs de données logistiques choisis dans le groupe composé de transitaires et des courtiers des douanes. Dans un ou plusieurs mode(s) de réalisation, la pluralité des services logistiques séquentiels comprend: un premier mode de transport opéré par un premier fournisseur, le premier fournisseur transportant l'envoi multi-mode d'un premier endroit vers un deuxième endroit ; et un deuxième mode de transport opéré par un deuxième fournisseur différent du premier fournisseur, le deuxième fournisseur transportant l'envoi multi-mode d'un deuxième endroit vers un troisième endroit ; et Dans un ou plusieurs mode(s) de réalisation, la détermination de la date GR pour chacun des livraisons comprend : le processeur calculant les dates GR pour les livraisons liées à l'envoi multi-mode basé sur la pluralité des livraisons liée au POLI. Dans un ou plusieurs mode(s) de réalisation, la pluralité des services logistiques séquentiels comprennent : un service fourni par une compagnie de transitaire ; un service fourni par une compagnie de courrier ; et un service fourni par un courtier des douanes logistique. Dans un ou plusieurs mode(s) de réalisation, la pluralité des services logistiques séquentiels est choisie dans un groupe composé d'un service fourni par une compagnie de manutention de fret, un service fourni par une compagnie de courrier et un service fourni par un courtier des douanes logistique. Brève description des figures [0002] La Fig. 1 est une illustration d'une chaîne d'approvisionnement. [0003] Les Fig. 2A-2C représentent un organigramme d'une application de visualisation d'une chaîne d'approvisionnement. [0004] Les Fig. 2D-2H sont une illustration du flux de données associé à l'application de visualisation d'une chaîne d'approvisionnement. [0005] La Fig. 3 est un organigramme d'un connecteur SAP®. [0006] La Fig. 4 est une capture d'écran utilisée pour saisir des données sur le portail d'un événement additionnel. [0007] Les Fig. 5, 6 et 8-13 sont des diagrammes de relation illustrant les relations entre les fichiers dans l'application de visualisation de la chaîne d'approvisionnement. [0008] Les Fig. 7A-7D sont des diagrammes de flux illustrant le traitement des données des marchandises reçues. [0009] La Fig. 14 est une capture d'écran d'une application présentant la visualisation. [0010] La Fig. 15 est une capture d'écran d'un écran de recherche. [0011] La Fig. 16 illustre les entêtes de colonne pour un écran de toutes les commandes. [0012] La Fig. 17 illustre les entêtes de colonne pour un écran de toutes les commandes (résumé logistique). [0013] La Fig. 18 est une capture d'écran d'une page de suivi d'un envoi. [0014] La Fig. 19 est une capture d'écran d'un outil statistique d'un réseau logistique. [0015] La Fig. 20 est une capture d'écran d'un outil de notification d'une annulation de commande.
Description détaillée [0016] Dans le cadre de ce document, une « livraison » ou une « livraison sortante » est définie comme un document SAP® (SAP Aktiengesellschaft Corporation de Dietmar-Hopp-Allee, Allemagne) qui autorise la sortie de marchandises et d'une quantité de l'inventaire. La livraison est ensuite attribuée à un envoi (défini ci-dessous) représentant les marchandises à livrer ensemble au récipiendaire des marchandises. Le document comprend : - le numéro de la marchandise, - la quantité de la livraison, - les indications sur l'emplacement (c'est-à-dire, l'endroit de réception des marchandises, l'endroit de décharge), - les poids et les volumes des produits individuels. [0017] Dans le cadre de ce document, une « date de sortie de marchandises » (ou « date PGI ») est apposée à une livraison et représente la date à laquelle les marchandises sont physiquement déplacées d'un entrepôt ou d'une usine lorsqu'un chargement d'une livraison est complété. Lorsque les marchandises sont des marchandises destinées à une livraison sortante, le stock d'un entrepôt contenant le produit est réduit par la quantité livrée. [0018] Dans le cadre de ce document, un « envoi » est défini comme le transport de marchandises d'un expéditeur vers un destinataire, selon les conditions convenues. La planification du transport, l'adresse de réception, le trajet, les frais d'expédition, etc., sont définis dans les documents d'expédition. Un envoi peut être constitué d'un ensemble de livraisons ayant le même trajet. Les livraisons effectuées dans le cadre du processus d'envoi ou la fonctionnalité d'envoi sont appelées « réseau stratégique ». Les livraisons qui n'ont pas de fonctionnalité d'envoi sont appelées « réseau non-stratégique ». [0019] Dans le cadre de ce document, un « bon de commande » (ou « BO ») est défini comme une requête ou une instruction provenant d'un organisme d'achat destiné à un fournisseur ou à une usine pour fournir ou proposer une certaine quantité de marchandises ou de services à un moment donné ou dans un certain délai donné. Un bon de commande est composé d'un en-tête de document et d'un ou de plusieurs éléments, (ou « lignes des éléments d'un bon de commande » ou « POLI »)). [0020] Dans un ou plusieurs modes de réalisation, comme l'illustre la Fig. 1, une application de visualisation d'une chaîne d'approvisionnement 102 comprend une application logicielle qui permet un suivi international des commandes ouvertes pour des produits et des équipements à travers une chaîne d'approvisionnement, généralement identifiée par une flèche 104, du fabricant/centre de réparation, l'adresse du vendeur ou l'adresse de l'entrepôt jusqu'à la livraison et la réception des marchandises (GR) à la destination finale. Il sera compris que la Fig. 1 est un exemple illustratif qui n'est pas destiné à limiter la portée des revendications. [0021] Dans un ou plusieurs modes de réalisation, l'application de visualisation de la chaîne d'approvisionnement 102 comprend quatre portails à travers lesquels des données peuvent être saisis - une interface d'échange de données informatisée, (EDI) 106, qui est une interface informatisée à travers laquelle les données provenant des transitaires (c'est-à-dire, les compagnies de transport qui transportent le fret d'un endroit à un autre) et des courtiers des douanes (c'est-à-dire, des gens ou des bureaux qui facilitent l'import et l'export des marchandises à travers des frontières politiques) peuvent être saisies dans l'application de visualisation de la chaîne d'approvisionnement 102, dans laquelle, dans un ou plusieurs modes de réalisation, elles sont stockées dans un système de gestion de produits SAPe fournit par SAP Aktiengesellschaft Corporation de Dietmar-Hopp-Allee Allemagne à travers une interface de langage d'interrogation structuré (SQL) vers un serveur SQL dans le SAPe ; - une interface des fichiers mensuels de transitaire et de courtage (FF BIVII) 108, à travers laquelle les transitaires et les courtiers de douane proposent des rapports mensuels contenant des données d'événements qui sont téléchargées vers le serveur SQL; - une interface de portail des événements manuels (MEP) 110, qui est un portail sur l'Internet qui permet aux transitaires et aux courtiers des douanes d'y consigner des événements ; - une interface de portail des événements additionnels (AEP) 112, qui est utilisée par les employés d'une entreprise 114 pour saisir des informations sur l'expédition ou pour les mouvements des factures imputées qui n'ont pas été converties en envois stratégiques (c'est-à-dire, les mouvements non-EDI) et pour enregistrer des informations d'événements dans un format standard. [0022] Dans un ou plusieurs modes de réalisation, tel que le démontre la Fig. 1, la chaîne d'approvisionnement comprend une entreprise 114, qui coordonne les activités de la chaîne d'approvisionnement. Dans un ou plusieurs modes de réalisation, l'entreprise 114 acquiert des produits et des équipements d'un ou de plusieurs centres de fabrication ou de réparation 116, d'un ou de plusieurs fournisseurs 118 et/ou d'une ou de plusieurs emplacements sur le terrain 120, pour remplir un POLI. Dans un ou plusieurs modes de réalisation, le bon de commande qui comprend le POLI comprend d'autres éléments de ligne de bon de commande. [0023] Dans un ou plusieurs modes de réalisation, l'un ou les plusieurs centres de fabrication ou de réparation 116 répondent avec une ou plusieurs envois par un ou plusieurs camions exploités par un ou plusieurs transitaires 122. Il sera compris que chacun des transitaires décrit ici peut fonctionner par air, mer, rail, camion ou par charter ou par une quelconque combinaison de ces modes de transport. Dans un ou plusieurs modes de réalisation, l'un ou les plusieurs transitaires 122 communiquent avec l'application de visualisation de la chaîne d'approvisionnement via l'EDI, comme l'indique l'éclair 124 (qui correspond à l'éclair au-dessus de l'EDI de la Fig. 1). [0024] Dans un ou plusieurs modes de réalisation, l'un ou les plusieurs fournisseurs 118 répondent à un ou plusieurs envois par un ou plusieurs modes différents (air/océan/rail/terre) exploités par un ou plusieurs transitaires 126. Dans un ou plusieurs modes de réalisation, l'un ou les plusieurs transitaires 126 procurent des rapports mensuels contenant des données d'événements qui sont téléchargées vers l'application de visualisation de la chaîne d'approvisionnement à travers le serveur SQL, tel qu'indiqué par le symbole de dossier de fichier 128 (qui correspond au symbole de dossier de fichier au-dessus du FF BMF dans la Fig. 1). [0025] Dans un ou plusieurs modes de réalisation, les emplacements sur le terrain 120 répondent avec un ou plusieurs envois par un ou plusieurs modes différents (air/océan/rail/terrestre) exploités par un ou plusieurs transitaires 130. Dans un ou plusieurs modes de réalisation, l'un ou les plusieurs transitaires 130 soumettent des événements à l'application de visualisation de la chaîne d'alimentation à travers le MEP, comme l'indique le symbole de clavier (qui correspond au symbole de clavier au-dessus du MEP dans la Fig. 1). [0026] Dans un ou plusieurs modes de réalisation, l'entreprise 114 reçoit les envois de l'un ou des plusieurs centres de fabrication ou de réparation 116, le ou les plusieurs fournisseurs 118 et/ou l'un ou les plusieurs emplacements sur le terrain 120. [0027] Dans un ou plusieurs modes de réalisation, l'entreprise 114 divise les envois reçus en multiples envois consolidés. [0028] Dans un ou plusieurs modes de réalisation, l'entreprise 114 expédie l'un ou les plusieurs envois par un plusieurs modes différents (air/océan/rail/terrestre) exploités par un ou plusieurs transitaires 134, qui enregistrent les événements avec l'application de visualisation de la chaîne d'approvisionnement par l'EDI, tel que l'indique l'éclair 136. [0029] Dans un ou plusieurs modes de réalisation, l'entreprise 114 expédie l'un ou les plusieurs envois par un plusieurs modes différents (air/océan/rail/terrestre) exploités par un ou plusieurs transitaires 138, qui enregistrent les événements avec l'application de visualisation de la chaîne d'approvisionnement par FF BMF, tel que l'indique le symbole de dossier de fichier 140. [0030] Dans un ou plusieurs modes de réalisation, l'entreprise 114 expédie l'un ou les plusieurs envois par un plusieurs modes différents (air/océan/rail/terrestre) exploités par un ou plusieurs transitaires 142, qui enregistrent les événements avec l'application de visualisation de la chaîne d'approvisionnement par MEP, tel que l'indique le symbole de clavier 144. Dans un ou plusieurs modes de réalisation, le transitaire 142 expédie le chargement à un agent du port 146 dans un port. Dans un ou plusieurs modes de réalisation, l'agent du port enregistre les événements avec l'application de visualisation de la chaîne d'approvisionnement par l'EDI, tel que l'indique l'éclair 148. Dans un ou plusieurs modes de réalisation, l'agent du port 146 expédie le chargement par un plusieurs modes différents (air/océan/rail/terrestre) exploités par un ou plusieurs transitaires 150, qui enregistrent les événements avec l'application de visualisation de la chaîne d'approvisionnement par l'EDI, tel que l'indique l'éclair 152. [0031] Dans un ou plusieurs modes de réalisation, les chargements expédiés par le transitaire 134, les chargements expédiés par le transitaire 138, et les chargements expédiés par le transitaire 150 arrivent à une destination finale 154. Dans un ou plusieurs modes de réalisation, la destination finale 154 enregistre des événements avec l'application de visualisation de la chaîne d'approvisionnement par l'EDI, tel que l'indique l'éclair 156. [0032] Dans un ou plusieurs modes de réalisation, les chargements envoyés par le transitaire 134 sont stockés à la destination finale 154. Dans un ou plusieurs modes de réalisation, les chargements envoyés par le transitaire 138 sont stockés à la destination finale 154. Dans un ou plusieurs modes de réalisation, les chargements envoyés par le transitaire 152 sont stockés à la destination finale 154 [0033] Dans un ou plusieurs modes de réalisation, la destination finale 154 retire des produits et les utilisent en des quantités qui ne correspondent pas aux quantités dans les cargaisons, comme il est présenté en détail en relation avec les Fig. 7A-7D et les scénarios 1-5. [0034] Dans un ou plusieurs modes de réalisation, les envois provenant de l'entreprise 114 ne sont pas tous expédiés le même jour. Dans un ou plusieurs modes de réalisation, les dates auxquelles les envois sont livrés à la destination finale 154 ne sont pas toutes les mêmes. Dans un ou plusieurs modes de réalisation, certaines mais pas toutes les dates sont les mêmes. [0035] Dans un ou plusieurs modes de réalisation, les plusieurs transitaires 122, 126, 130, 134, 138, 142 et 152, et l'agent du port 146 saisissent les informations suivantes dans l'application de visualisation de la chaîne d'approvisionnement pour chaque envoi : - date ETD - la date estimée à laquelle l'envoi sera expédié du pays d'origine, - date ATD - la date réelle à laquelle l'envoi est expédié du pays d'origine, - date ETA - la date estimée à laquelle l'envoi arrivera au pays de la destination finale. - date ATA - la date réelle à laquelle l'envoi est arrivé au pays de la destination finale. [0036] Dans un ou plusieurs modes de réalisation, un envoi peut passer à travers un pays intermédiaire (c'est-à-dire, par transbordement) (par exemple, le port desservi par l'agent du port 146) sur le chemin vers le pays de la destination finale. Par exemple, dans un ou plusieurs modes de réalisation, un envoi peut aller de la Malaisie en passant par Singapour sur le chemin vers l'Arabie Saoudite. Dans un ou plusieurs modes de réalisation, même après l'arrivée au pays de la destination finale, un envoi peut être traité par la bureaucratie des douanes du pays de la destination finale et pourrait ne pas être libéré des douanes dans son intégralité, mais peut être séparé en colis plus petits. [0037] Comme on peut le voir, le POLI unique peut avoir de multiples chargements à travers les transitaires 134, 138, 142 et 152 et des multiples dates de livraisons. Il sera compris que le nombre chargements, le nombre de transitaires et le nombre de dates de livraisons peuvent être supérieurs ou inférieurs à celui indiqué dans la Fig. 1. Il sera également compris que la Fig. 1 est juste un exemple d'une chaîne d'approvisionnement. Beaucoup de variations de l'exemple illustré sont envisagées. [0038] Dans un ou plusieurs modes de réalisation, illustrés dans les Fig. 2A, 2B et 2C (qui sont agencés tel que le montre la clé de la Fig. 2C), les événements saisis à travers l'EDI 106, le FFBMI 108 et le MEP 110 sont saisis dans un serveur SQL 202 (les saisies EDI 106 et MEP 110 passent à travers le SAPe avant d'entrer dans le serveur SQL 202), tel que le Microsoft SQLServer. Dans un ou plusieurs modes de réalisation, les données sont transférées du serveur SQL 202 vers un modèle de données associé 212 créé sur une plate-forme QLIKVIEWe fournit par QlikTech International AB Corporation de Schleelevâgen Suède. Dans un ou plusieurs modes de réalisation, un générateur de données QLIKVIEWe (QVD) 204 génère des fichiers QVD 206 à partir du serveur SQL 202. Dans un ou plusieurs modes de réalisation, les fichiers QVD 206 sont des données pour le modèle de données associatif 212. [0039] Dans un ou plusieurs modes de réalisation, d'autres données, telles que les données soumises à travers l'EDI 106 et le MEP 110, sont stockées sur un système SAPe 208 fourni par SAP Aktiengesellschaft Corporation de Dietmar-Hopp-Allee Allemagne. [0040] Dans un ou plusieurs modes de réalisation, un connecteur SAPe 210, développé par QLIKVIEWe permet le téléchargement à partir du système SAPe vers les fichiers QVD. Ceci est illustré avec plus de détails dans la Fig. 3. Dans un ou plusieurs modes de réalisation, le système SAPe 208 comprend une base de données (DB) 302 qui est accessible au module Open SQL 304, un module de requête SAPe Query 306 et un module de rapports 308. Dans un ou plusieurs modes de réalisation, chacun de ces modules est accessible par le connecteur SAPe 210 à travers les fonctions respectives de la fonction d'appel à distance QVC (RFC) 301, 312, 314. Dans un ou plusieurs modes de réalisation, le connecteur SAPe 210 comprend un connecteur SQL 316 qui accède à la fonctionnalité du module Open SQL 304. Dans un ou plusieurs modes de réalisation, le connecteur SAPe 210 comprend un connecteur de requête 318 qui accède à la fonctionnalité du module de requête du SAP 206. Dans un ou plusieurs modes de réalisation, le connecteur SAPe 210 comprend un connecteur 320 qui accède à la fonctionnalité du module de rapports 308. Dans un ou plusieurs modes de réalisation, un QLIKVIEWe publisher 322 exécute un logiciel 324 sur un système informatique 326 pour générer des fichiers QVD 206. [0041] Dans un ou plusieurs modes de réalisation, le modèle de données associatif 212 (voir la Fig. 2B) comprend un modèle de données logistiques 214 pour les données stratégiques, qui stockent des données provenant des transbordements, des transporteurs de fret, des courtiers de douane, des lignes consolidées et des logiciels protégés (par exemple, AEP 112). Dans un ou plusieurs modes de réalisation, le modèle de données associé 212 comprend un rapport de commande ouverte 216 pour les données non-stratégiques, qui stockent des rapports provenant d'une quelconque adresse de terrain vers une autre adresse de terrain ou d'un fournisseur vers une adresse qui n'est pas stratégique. Dans un ou plusieurs modes de réalisation, un modèle de données de visualisation 218 constitue un portail à travers lequel les données provenant du modèle de données logistiques 214 et du rapport de commande ouverte 216 peuvent être présentées à travers une présentation de visualisation 220 sur un écran 222. [0042] Dans un ou plusieurs modes de réalisation du flux de données associé à l'application de visualisation de la chaîne d'approvisionnement, illustrés dans les Fig. 2D-2H (qui sont agencés tel qu'illustré dans la clé de la Fig. 2H), le modèle de données logistique 214 contient les données d'expédition 224, les données de l'unité de manutention (HU) 226, les données du BO 228, les données de livraison 230 et les données logistiques 232. Dans un ou plusieurs modes de réalisation, les données provenant du modèle de données logistique 214 sont jointes (bloc 234). Dans un ou plusieurs modes de réalisation, le tableau de commandes ouvertes 216, qui comprend des données de livraison non-stratégiques 236, est utilisé avec le fichier de l'historique du BO 238, qui contient les données GR, pour calculer les données GR pour les livraisons non-stratégiques 240. Les données provenant du bloc 234 et les dates de GR calculées à partir du bloc 240 sont combinées pour créer un tableau de visualisation de toutes les commandes-1 242. Les données AMI 244 (c.-à-d., les données sur la gestion des produits internes) et les données d'organisation 246 sont associées au tableau de visualisation de toutes les commandes-2 (bloc 248) pour créer le tableau de visualisation de toutes les commandes-2 250. Ces données sont associées aux dates du calendrier du bon de commande 252, aux dates du calendrier des bons de vente 254 et les dates sur-site attendues 256 (bloc 258). Ces données sont associées aux événements logistiques 260 associés (stratégiques) 262, les données provenant du transporteur de fret 264 et les données du courtage douanier 266 pour créer le tableau de visualisation de toutes les commandes-3 268. Les données du portail des événements additionnels 270 sont associées 272, 274 aux données des événements logistiques pour créer un tableau d'événements logistiques (suivi) 276 à l'intérieur du modèle des données de visualisation 218. Les données du portail des événements additionnels 270 sont associées 272, 278 au tableau de visualisation de toutes les commandes-3 268 pour créer le tableau de visualisation de toutes les commandes-4. Ces données sont utilisées pour créer 282 un tableau de liaison avec une clé de commande et un numéro de référence 284. Un champ de réduction des données est créé pour le tableau de visualisation de toutes les commandes-4 280 (bloc 286) et un modèle réduit (avec un GR < 30 jours) est créé (bloc 288), qui est disponible pour la recherche et l'affichage au niveau d'un point d'accès 290. [0043] Comme il a été mentionné ci-dessus, le portail d'événement additionnel (AEP) 112 permet d'insérer des données dans la base de données SQL, à travers un écran, tel que celui illustré dans la Fig. 4, où il est validé par rapport au système SAP® 208. [0044] Les sources de données, les entités, les adresses, les transformations effectuées et les fichiers QVD de destination sont décrits dans le Tableau 1 suivant : Tableau 1 Type Sources Entité Emplacement Transformation réalisée QVD de données Externe Excel Transitaire Serveur SQL Procédure stockée SQL- Ajouter données de référence SAP aux données du transporteur de fret FFLOGData (38 rapport du terrain) Excel Fichiers du courtage douanier (26 Rapport de terrain) Serveur SQL Procédure stockée SQL- Ajouter données de référence SAP aux données de courtage douanier Courtage douanier SAP EDI - Serveur SQL Générer clé de Événements Type Sources Entité Emplacement Transformation réalisée QVD de données Données du courtage douanier l'unité de manipulation d'envoi SAP Données du portail des événements manuels - Transitaire Portail Générer clé de l'unité de manipulation d'événements manuels/Serveur SQL SAP EDI - Serveur SQL Générer clé de l'unité de manipulation Données du transitaire Interne Portail Données du portail des événements additionnels (AEP) Portail Web/ Convertir tous les numéros de référence en clé de livraison Événements Serveur SQL additionnels SAP En tête du bon de commande Connecteur QVD Générer bon de commande pour la clé d'article En-tête du bon du SAP de commande logistique SAP Articles du bon de commande Connecteur QVD Générer bon de commande pour la clé d'article Articles du bon du SAP de commande logistique SAP bons de ventes Connecteur QVD Générer bon de vente pour clé de l'article bons de ventes du SAP SAP Articles du bon de vente Connecteur QVD Générer bon de vente pour clé de l'article Articles du bon du SAP de vente Type Sources Entité Emplacement Transformation réalisée QVD de données SAP Flux de Connecteur QVD Générer bon de vente pour clé de l'article et clé de livraison Flux de document de ventes du SAP document de ventes SAP Partenaire du document de ventes Connecteur QVD Créer charges de cartographie Partenaire du du SAP document de ventes SAP Livraison Connecteur QVD Générer clé de livraison Livraison du SAP SAP Articles de livraison Connecteur QVD Générer clé de livraison Articles de du SAP livraison SAP Référence croisée de livraison Serveur SQL Générer clé de livraison Référence croisée de livraison logistique SAP Envoi Serveur SQL Niveau du service des cartes et description du groupe de transport Expédition logistique SAP Étapes de l'envoi Serveur SQL Créer charges de cartographie Étape de l'envoi logistique SAP Voie Connecteur QVD Créer charges de cartographie Trajet logistique du SAP SAP Documents de facturation Serveur SQL Générer clé d'article pour document de facturation Documents de facturation SAP Unité de manutention Serveur SQL Générer clé de l'unité de Unité de manutention Type Sources Entité Emplacement Transformation réalisée QVD de données manutention logistique SAP Articles de l'unité de manutention Serveur SQL Générer clé de l'unité de manutention, Créer charge de cartographie Articles de l'unité de manutention logistique SAP Actifs (données AMI) Serveur SQL Générer AMI et clé de livraison ZAAUR SAP Fiche d'article Connecteur QVD Créer charges de cartographie Matériels du SAP SAP Fiche d'article d'équipement Serveur SQL Créer charges de cartographie Fiche d'équipement SAP Matériaux de l'usine Serveur SQL Créer charges de cartographie Matériaux de l'usine SAP Organisation PSL Serveur SQL Créer charges de cartographie Organisation SAP Usine Serveur SQL Créer charges de cartographie Usine SAP Client Serveur SQL Créer charges de cartographie Client SAP Dates du bon de commande Connecteur QVD Générer bon de commande pour la clé d'article Dates du bon de commande du SAP SAP Dates du bon de vente Connecteur QVD Générer bon de vente pour clé de l'article Dates du bon de vente du SAP SAP Date d'article Connecteur QVD Générer bon de Date d'article de Type Sources Entité Emplacement Transformation réalisée QVD de données de la ligne de bon de vente du SAP vente pour clé de l'article la ligne de bon de vente SAP Historique du bon de Connecteur QVD Générer bon de commande pour la clé d'article Historique du commande du SAP bon de commande [0045] Le modèle de données logistique 214 cartographie les charges lorsqu'il y a une relation d'un à un entre les champs tel que le démontre le Tableau 2 suivant : Tableau 2 Nom de cartographie Tableau Champ de saisie Champ de cartographie Carte du centre de profit des bons de vente Qvd des articles des bons de vente Article du bon des ventes Centre de profit Carte de nom de pays Pays. Qvd Code de pays Nom de pays Carte de pays Pays. Qvd OID de pays Code de pays Carte de pays du client Client. Qvd Numéro de client Code de pays Carte d'événement Description d'événement. Qvd Identité de l'événement Description de l'événement Carte du niveau de service prioritaire de livraison Priorité de livraison (Tableau en ligne) Priorité de livraison Niveau de service Carte de la ville de l'usine Usine. Qvd Numéro de l'usine Ville de l'usine Carte du pays de l'usine Usine. Qvd Numéro de l'usine Pays de l'usine Carte du nom de l'usine Usine. Qvd Numéro de l'usine Nom de l'usine Carte de type d'usine Usine. Qvd Numéro de l'usine Type d'usine [0046] Dans un ou plusieurs modes de réalisation, le modèle de données logistique 214 est construit sur le cadre du modèle de données associatif 212 utilisant des données d'envoi stratégique provenant du SAP®. Les données sont stockées dans des tableaux transformés dans un format QVD qui doivent être utilisés par le modèle de données de visualisation 218. [0047] La Fig. 5 et les autres diagrammes de relation décrits ici (les Fig. 6 et 8-13) utilisent un symbolisme de « pattes d'oie ». Chacun des boîtes avec les coins arrondis représente un tableau QVD. Une ligne entre les deux tableaux indique une relation entre les tableaux. Un seul trait à chaque extrémité de la ligne indique une relation d'un à un. Un seul trait à une extrémité de la ligne et une patte d'oie à l'autre indiquent une relation d'un à plusieurs, la patte d'oie représentant le côté « plusieurs » de la relation. Un cercle ouvert avec une patte d'oie à une extrémité d'une ligne indique zéro ou plus. [0048] Dans un ou plusieurs modes de réalisation du modèle associatif 212, illustré dans la Fig. 5, le tableau des envois 502 a une relation d'un à un avec le tableau de la voie 504. Dans un ou plusieurs modes de réalisation, le tableau des envois 502 comprend un champ du numéro de l'envoi (clé principale), un champ de voie et un champ de mode d'envoi. [0049] Dans un ou plusieurs modes de réalisation, le tableau des envois 502 a une relation d'un à zéro à plusieurs avec un tableau des stades d'envoi 506. Dans un ou plusieurs modes de réalisation, le tableau des stades d'envoi 506 comprend un champ du numéro de l'envoi des envois (clés étrangères,), un champ de stades d'envoi et un champ du numéro du transitaire de l'envoi. [0050] Dans un ou plusieurs modes de réalisation, le tableau des envois 502 a une relation d'un à zéro à plusieurs avec un tableau de l'en-tête de l'unité de manutention 508. Dans un ou plusieurs modes de réalisation, le tableau d'en-tête de l'unité de manutention 508 possède un champ identifiant de l'unité de manutention externe (clé principale), un champ de numéro d'envoi, un champ de numéro de l'unité de manutention et un champ de numéro d'envoi des envois (clé étrangère). [0051] Dans un ou plusieurs modes de réalisation, le tableau d'en-tête de l'unité de manutention 508 a une relation d'un à zéro à plusieurs avec le tableau des articles de la ligne de manutention 510. Dans un ou plusieurs modes de réalisation, le tableau des articles de la ligne de manutention 510 comprend un champ du numéro de l'unité de manutention (clé étrangère) et un champ de clé de livraison. [0052] Dans un ou plusieurs modes de réalisation, le tableau des articles de la ligne de l'unité de manutention 510 a une relation d'un à zéro à plusieurs avec un tableau de référence croisée de livraison 512. Dans un ou plusieurs modes de réalisation, le tableau de référence croisée de livraison 512 comprend un champ de clés de livraison (clé étrangère), un champ de clés d'articles de bon de commande (clé principale), un champ de numéro de livraison, un champ de pays d'origine, un champ de pays de destination, un champ d'origine de l'usine, un champ de l'usine de destination, un champ du numéro de document de facturation et un champ du numéro de bon de vente. [0053] Dans un ou plusieurs modes de réalisation, le tableau de référence croisée de livraison 512 a une relation d'un à zéro à plusieurs avec un tableau des articles du bon de commande 514. Dans un ou plusieurs modes de réalisation, le tableau des articles du bon de commande 514 contient un champ de clé d'article du bon de commande (clé principale), un champ du numéro du bon de commande, un champ du numéro d'article de la ligne de commande, un champ de centre de profit et un champ d'usine. [0054] Dans un ou plusieurs modes de réalisation, le tableau des articles du bon de commande 514 a une relation d'un à un avec un tableau de l'usine 516. Dans un ou plusieurs modes de réalisation, le tableau de l'usine 516 comprend un champ Usine (clé étrangère), un champ du nom de l'usine et un champ du pays de l'usine. [0055] Dans un ou plusieurs modes de réalisation, le tableau des articles du bon de commande 514 une relation d'un à un avec le tableau d'organisation 518. Dans un ou plusieurs modes de réalisation, le tableau d'organisation 518 comprend un champ de centre de profit (clé principale), un champ de nom de PSL (où « PSL » est une abréviation pour ligne de service de produits), et un champ SOUS PSL. [0056] Dans un ou plusieurs modes de réalisation, illustrés dans la Fig. 6, le tableau des articles du bon de commande 514 (également illustré dans la Fig. 5) a une relation d'un à zéro à plusieurs avec un tableau de référence croisée de livraison logistique 602. Dans un ou plusieurs modes de réalisation, le tableau de référence croisée de livraison logistique 602 comprend un champ de clé de livraison (clé étrangère), une clé d'article de bon de commande (clé étrangère), un champ de la quantité de livraison, un champ de clé d'indice d'article du bon de commande, un champ de clé de lot BO de bon de commande, un champ de clé de la quantité totale reçue du bon de commande, un champ de clé de la quantité d'article totale requise du bon de commande, et une clé d'article de bon de commande des articles du bon de commande. [0057] Dans un ou plusieurs modes de réalisation, le tableau de référence croisée de livraison logistique 602 a une relation d'un à un avec un tableau de date GR 604. Dans un ou plusieurs modes de réalisation, le tableau de date GR 604 comprend un champ de clé de livraison (clé étrangère), un champ de Date 1 de GR et un champ de Date 2 de GR, un champ de Date 3 de GR et un champ de Date 4 de GR. [0058] Dans un ou plusieurs modes de réalisation, le tableau de Date GR 604 a une relation d'un à un avec un tableau de l'historique des bons de commande 606. Dans un ou plusieurs modes de réalisation, le tableau de l'historique des bons de commande 606 comprend un champ de clé d'article de bon de commande, un champ de clé d'indice d'article de bon de commande, un champ de clé de lot de BC de bon de commande, un champ de clé de quantité totale reçue du bon de commande, un champ de clés de quantité totale requise du bon de commande, et un champ de date de GR. [0059] Dans un ou plusieurs modes de réalisation, le tableau de Date GR 604 contient des résultats de l'application des règles GR conçues pour capter la date GR à partir d'un POLI dans le SAP® et de l'associer à un article de la ligne de livraison sur une expédition. Dans un ou plusieurs modes de réalisation, le tableau de Date GR 604 contient quatre réseaux de date GR (GR Date 1, GR Date 2, GR Date 3 et GR Date 4)(il sera compris que des réseaux de date GR additionnels sont possibles et sont dans le cadre de la portée des revendications ci-jointes) qui sont utilisés pour faire une corrélation entre la date GR et l'article de la ligne de livraison, et ils sont utilisés dans des analyses ultérieures, décrites ci-dessous, pour déterminer si un POLI doit être fermé, ce qui veut dire que toutes les expéditions, y compris les livraisons, liées au POLI, ont été reçues (GR). [0060] Dans un ou plusieurs modes de réalisation, chacun des réseaux de date GR concerne un scénario différent qui se produit lors de l'expédition des marchandises. Dans chacun de ces scénarios, dans un ou plusieurs modes de réalisation : - plusieurs expéditions sont composées de livraison liées à un POLI, - chacun des multiples livraisons possède une date sortie de marchandises (PGI) (c.-à-d., la date à laquelle les marchandises liées à cet envoi sont physiquement déplacées d'un entrepôt ou d'une usine), - les dates de PGI ont un ordre (par ex., un ordre de date et/ou un ordre de temps) - des multiples livraisons sont liées au POLI, - chacune des multiples livraisons liées au POLI possède une quantité de livraison ; - chacune des livraisons possède un article de livraison avec une quantité d'article de livraison, tel qu'il est présenté ci-dessous en relation avec le scénario 3 ; - chacune des multiples livraisons liées au POLI peut posséder de multiples événements GR (c.-à-d., il est possible pour des marchandises provenant d'une livraison unique d'être reçues (GR) en plusieurs lots), - chacun des multiples événements GR possède une quantité GR et une date GR, - les dates GR ont un ordre (par ex., un ordre de date et/ou un ordre de temps), - le POLI a une quantité requise de POLI (c.-à-d., la quantité commandée sous le POLI). [0061] Dans un ou plusieurs modes de réalisation, le réseau GR Date 1 concerne le scénario dans lequel les quantités GR correspondent aux quantités de livraison mais l'ordre des quantités GR est différent de l'ordre des quantités livrées. Par ex., assumant le scénario suivant (toutes ces données sont liées à un POLI unique) : Scénario 1 Envoi Quantité de la livraison Date PGI 1 40 1 er juin Événement GR Quantité GR Date GR 1 60 1 er juillet 2014 2 60 3 juin 2014 2014 2 40 3 juillet 2014 [0062] Dans ce scénario, la cargaison 1, avec une quantité de livraison de 40, a une date PGI du ler juin 2014, et la cargaison 2, avec une quantité de livraison de 60, a une date PGI du 3 juin 2014. L'événement GR 1, avec une quantité GR de 60, a une date GR du ler juillet 2014, et l'événement GR 2, avec une quantité GR de 40, a une date GR du 3 juillet 2014. La cargaison 1 et la cargaison 2 n'ont pas été divisées en de multiples livraisons ; c.-à-d., les quantités de livraison et les quantités GR correspondent (c.-à-d., la quantité livrée pour la cargaison 1 correspond à la quantité GR pour l'événement GR 2 et la quantité livrée pour la cargaison 2 correspond à la quantité GR pour l'événement 1). Par conséquent, dans ce scénario, l'établissement d'une date GR pour l'envoi établit également une date GR pour la livraison. La cargaison 1 a été reçue (GR) après la cargaison 2 même si elle a été envoyée en premier, ce qui pourrait se produire en raison des délais lors de l'envoi, des délais au niveau des douanes, ou pour une diversité d'autres raisons. Dans un ou plusieurs modes de réalisation, ceci est confirmé en comparant la date GR et la date ATA. [0063] Dans un ou plusieurs modes de réalisation, le réseau GR Date 1 prend en charge cette situation. Dans un ou plusieurs modes de réalisation, un processeur calcule le réseau GR Date 1 en - faisant correspondre les quantités de livraison des multiples expéditions liées au POLI aux quantités GR des multiples événements GR liés au POLI (c.-à-d., faire correspondre une cargaison 1 à l'événement GR 2 est la cargaison 2 à l'événement GR 1), et - pour chaque envoi, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour chaque correspondance dans le réseau GR Date 1. [0064] Dans un ou plusieurs modes de réalisation, le résultat est un réseau GR Date 1 qui contient les données suivantes : Réseau GR Date 1 pour le Scénario 1 Envoi Quantité de la Date PGI Quantité GR Date GR livraison 1 40 ler juin 2014 40 3 juillet 2014 2 60 3 juin 2014 60 ler juillet 2014 [0065] Dans un ou plusieurs modes de réalisation, le réseau GR Date 1 prend en charge également la situation dans laquelle plusieurs cargaisons liées au POLI ont les mêmes quantités de livraison, tel que le montre le scénario 2: Scénario 2 Envoi Quantité de la livraison Date PGI 1 20 1 er juin 2014 2 60 3 juin 2014 3 20 5 juin 2014 Événement GR Quantité GR Date GR 1 60 1 er juillet 2014 2 20 3 juillet 2014 3 20 5 juillet 2014 [0066] Les correspondances dans le scénario 2 sont plus difficiles que les correspondances dans le scénario 1 parce que les cargaisons 1 et 3 ont les mêmes quantités que les événements GR 2 et 3.
Dans un ou plusieurs modes de réalisation, un processeur calcule le réseau GR Date 1 en : - faisant correspondre les quantités de livraison des multiples cargaisons liées au POLI aux quantités GR des multiples événements GR liés au POLI (c.-à-d., faire correspondre une cargaison 1 à l'événement GR 2 et la cargaison 2 à l'événement GR 1), - lorsque la correspondance est ambigüe parce qu'au moins une partie des quantités de livraison liée au POLI est égale (c. -à-d., les quantités de livraison pour l'envoi 1 et l'envoi 3 sont égales) et au moins une partie des quantités GR liée au POLI est égale (c. -à-d., les quantités GR pour les événements 2 et 3 sont égales)(l'ambiguïté réside dans le fait de savoir si l'envoi 1 doit être lié à l'événement GR 2 ou à l'événement GR 3 est si l'envoi 3 doit être lié à l'événement GR 2 ou à l'événement GR 3), - la résolution de cette ambiguïté en donnant la préférence à l'alignement de la commande des dates de PGI à la commande des dates de GR, et - pour chaque envoi, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour chaque correspondance dans le réseau GR Date 1. [0067] Comme pour le scénario 1, dans un ou plusieurs modes de réalisation, la date GR pour une livraison établit également une date GR pour l'envoi. [0068] Dans un ou plusieurs modes de réalisation, le résultat est un réseau GR Date 1 qui contient les données suivantes : Réseau GR Date 1 pour le Scénario 2 Envoi Quantité de la Date PGI Quantité GR Date GR livraison 1 20 ler juin 2014 20 3 juillet 2014 2 60 3 juin 2014 60 ler juillet 2014 3 20 5 juin 2014 20 5 juillet 201420 [0069] Dans certains modes de réalisation, les livraisons sont divisées en de multiples articles de livraison, tel que le démontre le scénario 3 suivant : Scénario 3 Événement GR Quantité GR Date GR 1 60 1 er juillet 2014 2 20 3 juillet 2014 3 20 5 juillet 2014 Envoi Quantité Date PGI Quantité d'article de livraison de la livraison 1 20 1 er juin 10 2014 1 20 1 er juin 10 2014 2 60 3 juin 2014 60 3 20 5 juin 2014 20 [0070] Dans un ou plusieurs modes de réalisation, le réseau GR Date 2 s'occupe de cette situation. Dans un ou plusieurs modes de réalisation, un processeur calcule le réseau GR Date 2 en : - faisant le total des quantités d'articles de livraison des livraisons liées au même envoi (c. -à-d., la somme des quantités d'articles de livraison pour les livraisons liées à l'envoi 1), - faisant correspondre les quantités d'article de livraison totalisée aux quantités GR (c. -à-d., l'envoi 1 avec les quantités d'articles de livraison additionnées correspondant à l'événement GR 2 et l'envoi 3 correspondant à l'événement GR 3), et - pour chaque envoi, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison et la date GR pour chaque réseau GR Date 2 ; [0071] Le résultat est un réseau GR Date 2 qui comprend les données illustrées ci-dessous : Réseau GR Date 2 pour le Scénario 3 Envoi Quantité de la livraison Date PGI Quantité Quantité GR Date GR d'article de livraison 1 20 ler juin 2014 10 20 3 juillet 2014 1 20 ler juin 2014 10 20 3 juillet 2014 2 60 3 juin 2014 60 60 1 er juillet 2014 3 20 5 juin 2014 20 20 5 juillet 2014 [0072] Dans un ou plusieurs modes de réalisation, les quantités GR ne correspondent pas aux quantités de livraison telle que le démontre le scénario 4 ci-dessous : Scénario 4 Envoi Date PGI Quantité de la livraison 1 ler juin 20 2014 2 3 juin 2014 60 3 5 juin 2014 20 Événement GR Quantité GR Date GR 1 10 1 er juillet 2014 2 10 3 juillet 2014 3 60 5 juillet 2014 4 20 7 juillet 2014 [0073] Dans un ou plusieurs modes de réalisation, le réseau GR Date 3 s'occupe de cette situation. Dans un ou plusieurs modes de réalisation, un processeur calcule le réseau GR Date 3 en : - totalisant les quantités GR d'un groupe d'événements GR de sorte que la somme corresponde à une quantité de livraison de l'une des multiples livraisons (par ex., totalisant les quantités des événements GR 1 et 2 et en faisant correspondre cette somme (20) à la quantité de livraison de la livraison de l'envoi 1), - déterminant un maximum des dates GR à partir du groupe d'événements GR et en l'enregistrant sous forme de maximum GR date 3 (3 juillet 2014, qui est le maximum du 1 juillet 2014 et du 3 juillet 2014), - changeant les dates GR des événements GR dans le groupe pour maximum GR date 3, et - pour chaque livraison, l'enregistrement de la quantité de livraison, de la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR modifiée dans le réseau, GR Date 3. [0074] le résultat est un réseau GR Date 3 qui comprend les données illustrées ci-dessous (à noter que l'envoi 1 a une date GR qui est la plus récente du groupe des événements GR qui ont été totalisés pour correspondre la quantité de livraison de l'envoi 1) : Réseau GR Date 3 pour le Scénario 4 Envoi Date PGI Quantité de la Quantité GR Date GR livraison 1 ler juin 2014 20 20 3 juillet 2014 2 3 juin 2014 60 60 5 juillet 2014 3 5 juin 2014 20 20 7 juillet 2014 [0075] Dans un ou plusieurs modes de réalisation, les quantités de livraison ne correspondent pas aux quantités GR, tel que le démontre le scénario 5 ci-dessous : Scénario 5 Envoi Date PGI Quantité de la livraison 1 ler juin 20 2014 2 3 juin 2014 60 3 5 juin 2014 20 Événement GR Quantité GR Date GR 1 85 1 er juillet 2014 2 5 3 juillet 2014 3 10 5 juillet 2014 [0076] Dans un ou plusieurs modes de réalisation, le réseau GR Date 4 s'occupe de cette situation. Dans un ou plusieurs modes de réalisation, un processeur calcule le réseau GR Date 4 en : - totalisant les quantités GR des multiples événements GR pour générer summed GR quantities (c. -à-d., dans le scénario 4, la somme des quantités GR est de 10+10+60+20 = 100) ; - déterminant que le summed GR quantities est égale à la quantité nécessaire pour le POLI (en assumant que la quantité nécessaire est de 100) ; - déterminant un maximum des dates GR à partir des multiples événements GR et en l'enregistrant sous forme de maximum GR date 4 (la date GR maximale est le 5 juillet 2014), - modifiant les dates GR des multiples événements GR pour le maximum GR date 4; - Pour chaque envoi, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date modifiée dans le réseau GR Date 4. [0077] Le résultat est un réseau GR Date 4 qui comprend les données illustrées ci-dessous (à noter que tous les envois ont une date GR des événements GR les plus récentes dans le scénario) : Réseau GR Date 4 pour le Scénario 5 Envoi Date PGI Quantité de la Quantité GR Date GR livraison 1 ler juin 2014 20 85 5 juillet 2014 2 3 juin 2014 60 5 5 juillet 2014 3 5 juin 2014 20 10 5 juillet 2014 [0078] Dans un ou plusieurs modes de réalisation, le tableau de date GR 604 est créé comme suit : GR Date Table : Load Distinct PalTM QTY INDEX KEY ,P0 Key ,P0 BATCH QTY REC INDEX KEY ,[Dlvry Cross Ref Delivery Quantity] ,P0 TOTAL QTY REC KEY ,P0 ITM REQ QTY KEY ,[Delivery Key] ,Date([DLVRY Actual Goods Movement Date],'MM/DD/YYYY') as PGI Date resident Delivery Xref; left join (GR date Table) load PalTM QTY INDEX KEY ,[POH Posting Date] as GR Date 1 resident PO HIST; left join (GR date Table) load PO BATCH QTY REC INDEX KEY ,[POH Posting Date] as GR Date 2 resident PO HIST; left Join(GR date Table) LOAD PO HIST PO KEY comme PO Key, PO TOTAL QTY REC KEY, max([POH Posting Date]) as GR Date 3 PO HIST PO KEY&"&Sum([POH Receipt Quantity]) as PO TOTAL QTY REC KEY Resident PO HIST Where Exists(P0 HIST PO KEY) Group by PO HIST PO KEY; left Join(GR date Table) LOAD PO HIST PO KEY comme PO Key, PO HIST PO KEY &"&Sum([POH Receipt Quantity]) as PO ITM REQ QTY KEY, max([POH Posting Date]) as GR Date 4 Resident PO HIST Where Exists(P0 HIST PO KEY) Group by PO HIST PO KEY; [0079] Dans un ou plusieurs modes de réalisation, comme également illustrés dans les Fig. 7A-7D (qui sont visualisés tels que montrés sur la clé de la Fig. 7D), les données GR du Tableau 604 sont créées de: - une GR Date 1 702 qui est créé en associant : o une clé d'indice d'article 704, qui est créée à partir de l'historique des PO du fichier QVD 606, avec o une clé d'indice de livraison PO 706, qui est créée à partir du fichier de référence croisée de livraison QVD 602, qui est à son tour créé à partir d'un fichier des articles de la ligne du bon de commande QVD file 514; - une GR Date 2 708 qui est formée en associant : o une clé de lot PO 710, qui est créée à partir de l'historique des PO du fichier QVD 606, avec o une clé de lot de livraison PO 712, qui est créée à partir du fichier de référence croisée de livraison QVD 602; - une GR Date 3 714 qui est formée en associant : o une clé de quantité d'article reçue 716, qui est créée à partir de l'historique des PO du fichier QVD 606, avec o une clé de quantité d'article reçue PO 718, qui est créée à partir du fichier de référence croisée de livraison QVD 602 ; - une GR Date 4 720 qui est formée en associant : o une clé de quantité d'article nécessaire PO 722, qui est créée à partir de l'historique des PO du fichier QVD 606, avec o une clé de quantité d'article nécessaire PO 727, qui est créée à partir du fichier de référence croisée de livraison QVD 602. [0080] Dans un ou plusieurs modes de réalisation, le tableau de données GR 604 est comparé à un tableau des dates de livraisons 726, qui est créé à partir des fichiers QVD contenant les données mensuelles du transitaire 728, les dates EDI (transitaire et courtier) 730, et les données mensuelles de courtage de douane 732, afin de déterminer la date calculée de GR pour chaque livraison et pour déterminer si le POLI doit être fermé sur la base des livraisons, comme suit : - Si la date GR Date 1 > ATA et la date GR Date 1 > PGI (bloc 734) alors la date GR calculée pour la livraison (bloc 736) est définie à GR Date 1 (branche « oui » du bloc 734), sinon (branche « non » du bloc 734) : - Si la date GR Date 2 > ATA et la date GR Date 2 > la date PGI (bloc 738) alors la date GR calculée pour la livraison (bloc 736) est définie à GR Date 2 (branche « oui » du bloc 738), sinon (branche « non » du bloc 738) : - Si la date GR Date 3 > ATA et la date GR Date 3 > la date PGI (bloc 740) alors la date GR calculée pour la livraison (bloc 736) est définie à GR Date 3 (branche « oui » du bloc 740, sinon (branche « non » du bloc 740) : - Si la date GR Date 4 > ATA et la date GR Date 4 > la date PGI (bloc 742) alors la date GR calculée pour la livraison (bloc 736) est définie à GR Date 4 (branche « oui » du bloc 742, sinon (branche « non » du bloc 742) : - la date GR pour la livraison est définie à "nulle" (bloc 744), indiquant que le POLI est toujours ouvert. [0081] Les données ainsi obtenues sont stockées dans le fichier des dates logistiques QVD 746. [0082] Dans un ou plusieurs modes de réalisation, les réseaux de dates GR ont une hiérarchie. Dans un ou plusieurs modes de réalisation, l'ordre de la hiérarchie est le suivant : réseau GR Date 1, réseau GR Date 2, réseau GR Date 3 et réseau GR Date 4. C.-à-d., dans un ou plusieurs modes de réalisation : - si le réseau GR Date 1 peut être calculé il aura préséance sur les autres, - si le réseau GR Date 1 ne peut pas être calculé par le réseau GR Date 2 peut être calculé, le réseau GR Date 2 aura préséance sur les autres, - si le réseau GR Date 1 et le réseau GR Date 2 ne peuvent pas être calculés mais qu'on peut le faire pour le réseau GR Date 3, le réseau GR Date 3 aura préséance sur les autres, et - le réseau GR Date 4 ne sera utilisé que s'il peut être calculé et qu'aucun autre des réseaux ne peut l'être. [0083] Dans un ou plusieurs modes de réalisation, illustrés dans la Fig. 8, le modèle de données logistique 214 calcul la soumission la plus récente du connaissement ou du numéro du bordereau de groupage aérien et associe les rapports mensuels du transitaire et du courtage de douane avec les données EDI aux données d'envoi stratégique au niveau de l'unité de manipulation. Dans un ou plusieurs modes de réalisation, les fichiers QVD ainsi obtenus sont enregistrés pour être utilisés par l'outil de visualisation (présenté ci-dessous) et d'autres outils de rapport. Dans un ou plusieurs modes de réalisation, le tableau des envois 502 (également illustré dans la Fig. 5) a une relation un à zéro à plusieurs par rapport au tableau des données mensuelles du transitaire 702 (décrit ci-dessus en relation avec la Fig. 7). [0084] Dans un ou plusieurs modes de réalisation, le tableau des envois 502 a une relation un à zéro à plusieurs par rapport au tableau des données mensuelles du courtage de douane 704 (décrit ci-dessus en relation avec la Fig. 7). [0085] Dans un ou plusieurs modes de réalisation, le tableau des envois 502 a une relation un à zéro à plusieurs par rapport au tableau des événements d'envoi 706 (décrit ci-dessus en relation avec la Fig. 7). [0086] Dans un ou plusieurs modes de réalisation, le tableau des envois 502 a une relation d'un à zéro à plusieurs avec un tableau de calcul de la priorité des événements EDI 808. Dans un ou plusieurs modes de réalisation, le tableau de calcul de la priorité des événements EDI 808 comprend un champ de l'identifiant de l'unité de manutention externe (clé étrangère), un champ de date ATD minimale, un champ de date ATA maximale, un champ BOL et un champ de données de départ des douanes maximales. [0087] Dans un ou plusieurs modes de réalisation, illustrés dans la Fig. 9, le modèle de données logistique 214 consolide tous les événements internes (c. -à-d. à l'intérieur du SAPe) et externes, qui permettront un suivi au niveau de l'unité de manipulation. Dans un ou plusieurs modes de réalisation, ces données peuvent être extrapolées aux livraisons, envois, bons de commande, bon de vente, numéro de matériel, etc. Dans un ou plusieurs modes de réalisation, un résumé des événements critiques avec une vérification du pays d'origine et de la destination finale est calculé pour procurer un résumé rapide des événements Dans un ou plusieurs modes de réalisation, la date GR est évaluée avec les dates ATD et ATA afin de calculer la date GR finale pour la livraison d'un article de ligne, tel qu'il est décrit ci-dessus en relation avec les Fig. 7A-7D. Dans un ou plusieurs modes de réalisation, le tableau des envois 502 a une relation un à zéro à plusieurs par rapport au tableau des données mensuelles du courtage de douane 704 (décrit ci-dessus en relation avec la Fig. 7) et une relation un à zéro à plusieurs par rapport au tableau des données mensuelles du transitaire 702 (décrit ci-dessus en relation avec la Fig. 7). Dans un ou plusieurs modes de réalisation, le tableau des données mensuelles du courtage de douane 902 et le tableau des données mensuelles du transitaire 904 ont une relation un à zéro à plusieurs avec un tableau des événements logistiques 906. Dans un ou plusieurs modes de réalisation, le tableau des envois 502 a une relation un à zéro à plusieurs par rapport à un tableau des événements d'envoi 806 (décrit ci-dessus en relation avec la Fig. 8) et une relation un à zéro à plusieurs avec un tableau de calcul de la priorité des événements EDI 910. Dans un ou plusieurs modes de réalisation, le tableau de calcul de la priorité des événements EDI 910 a une relation un à zéro à plusieurs avec un tableau des dates de livraison 912. Dans un ou plusieurs modes de réalisation, le tableau de la date GRI 604 a une relation un à zéro à plusieurs avec le tableau des dates de livraison 912. [0088] Dans un ou plusieurs modes de réalisation, le tableau des événements logistiques 906 comprend un champ de l'identifiant de l'unité de manutention externe (clé étrangère), un champ des événements EDI, un champ des événements EDI, un champ des événements du transitaire et un champ des événements du courtage douanier. [0089] Dans un ou plusieurs modes de réalisation, le tableau de calcul de la priorité des événements EDI 910 comprend un champ de l'identifiant de l'unité de manutention externe (clé étrangère), un champ de date ATD minimale, un champ de date ATA maximale, un champ BOL et un champ de données de départ des douanes maximales. [0090] Dans un ou plusieurs modes de réalisation, le tableau des dates de livraison 912 comprend un champ du numéro de l'unité de manutention (clé étrangère), un champ de clé de livraison et un 15 champ de date GR. [0091] Dans un ou plusieurs modes de réalisation, illustrés dans la Fig. 10, un rapport de commande ouverte a été créé pour capter toutes les commandes ouvertes, y compris des commandes d'achat du fournisseur et des redéploiements du fournisseur, pour lesquels des envois n'ont pas été créés ou ne seront pas créés. Dans un ou plusieurs modes de réalisation, ces données sont enchaînées aux 20 données d'envoi stratégique pour le modèle des données de visualisation 214. Dans un ou plusieurs modes de réalisation, pour les bons de vente directe (les envois expédiés directement aux clients) dans lesquelles les commandes ne sont pas GRées dans le SAP®, les données sont enlevées du rapport de visualisation 90 jours après le PGI. Dans un ou plusieurs modes de réalisation, un fanion de livraison complétée provenant des données du bon de commande est utilisé pour enlever les 25 anciens bons de commande complétés. Dans un ou plusieurs modes de réalisation, le calcul de la date GR pour le bon de commande du fournisseur est réalisé dans le modèle des données de visualisation 218. Dans un ou plusieurs modes de réalisation, les événements de visualisation pour les déploiements sur le terrain et les bons de commande du fournisseur sont saisis à travers le portail des événements additionnels 112. [0092] Dans un ou plusieurs modes de réalisation, un tableau d'en-tête de bon de commande 1002 a une relation un à un avec un tableau de bon de vente 1004 et une relation un à un à plusieurs avec le tableau des articles de la ligne du bon de commande 1006. Dans un ou plusieurs modes de réalisation, le tableau de bon de vente 1004 a une relation d'un à zéro à plusieurs avec un tableau des articles du bon de vente 1008. Dans un ou plusieurs modes de réalisation, le tableau des articles du bon de commande 1006 a une relation d'un à un avec un tableau de commandes ouvertes 1010. Dans un ou plusieurs modes de réalisation, le tableau des articles du bon de vente 1008 a une relation d'un à un avec le tableau de commandes ouvertes 1010. Dans un ou plusieurs modes de réalisation, le tableau des articles de la ligne de commande du bon de vente 1008 a une relation d'un à zéro à plusieurs avec un tableau de flux de document de vente 1012. Dans un ou plusieurs modes de réalisation, un tableau de livraison 1014 a une relation d'un à zéro ou plusieurs avec un tableau des articles de livraison 1016. [0093] Dans un ou plusieurs modes de réalisation, le tableau d'en-tête du bon de commande 1002 contient un champ du numéro du bon de commande (clé étrangère), un champ du fournisseur 15 d'origine et un champ de code de type de bon de commande. [0094] Dans un ou plusieurs modes de réalisation, le tableau des bons de vente 1004 comprend un champ du numéro du bon de vente (clé principale) et un champ de type de SO. [0095] Dans un ou plusieurs modes de réalisation, le tableau des articles de la ligne du bon de commande 1006 contient un champ du numéro du bon de commande (clé principale), un champ du 20 numéro d'article de la ligne de commande (clé étrangère), un champ du numéro de matériel, un champ de centre de profit et un champ de fanion de livraison complétée. [0096] Dans un ou plusieurs modes de réalisation, le tableau des articles de la ligne du bon de vente 1008 contient un champ du numéro du bon de vente (clé principale), un champ d'article de la ligne du bon de vente (clé étrangère), un champ du numéro du matériel, un champ du fournisseur 25 d'origine, un champ de la quantité d'article et un champ de fanion de livraison complétée. [0097] Dans un ou plusieurs modes de réalisation, le tableau des commandes ouvertes 1010 contient un champ du numéro du bon de vente (clé étrangère), un champ du numéro de bon de commande (clé étrangère), un champ du numéro de livraison, un champ d'envoi à un partenaire, un champ du fournisseur d'origine, un champ de type de PO, un champ de fanion de livraison complétée et un champ d'identifiant de l'unité de manutention externe. [0098] Dans un ou plusieurs modes de réalisation, le tableau du flux du document de vente 1012 contient un champ du numéro du bon de vente (clé étrangère), un champ du numéro d'article du bon de vente et un champ du numéro de livraison (clé principale). [0099] Dans un ou plusieurs modes de réalisation, le tableau de livraison 1014 contient un champ du numéro de livraison (clé principale), un champ de colonne, un champ du flux du bon de vente du document des ventes (clé étrangère) et un champ du numéro du flux de livraison du document de vente. [0100] Dans un ou plusieurs modes de réalisation, le tableau des articles de livraison 1016 comprend un champ du numéro de livraison (clé étrangère) et un champ d'article de livraison et un champ de la quantité de livraison. [0101] Dans un ou plusieurs modes de réalisation, illustrés dans la Fig. 11, tous les tableaux des commandes et des matériaux d'usine sont associés pour former le PSL de matériel pour les commandes de fabrication. Dans un ou plusieurs modes de réalisation, un tableau de toutes les commandes 1102 est un enchaînement du tableau de référence croisée de la logistique de livraison 602 (présenté ci-dessus en association avec la Fig. 6) et le tableau des commandes ouvertes 1010 (présenté ci-dessus en association avec la Fig. 10). Dans un ou plusieurs modes de réalisation, un tableau des lignes du calendrier du bon de commande 1104 a une relation d'un à zéro ou de plusieurs avec un tableau de toutes les commandes 1102. Dans un ou plusieurs modes de réalisation, un tableau des données AMI 1106 a une relation d'un à zéro ou de plusieurs avec le tableau de toutes les commandes 1102. Dans un ou plusieurs modes de réalisation, un tableau de matériel d'usine 1108 a une relation d'un à un avec le tableau de toutes les commandes 1102. Dans un ou plusieurs modes de réalisation, le tableau de toutes les commandes 1102 a une relation d'un à zéro ou de plusieurs avec un tableau des lignes du calendrier du bon de vente 1110. Dans un ou plusieurs modes de réalisation, le tableau de toutes les commandes 1102 a une relation d'un à zéro ou de plusieurs avec un tableau de la date des articles de la ligne du calendrier du bon de vente 1112. [0102] Dans un ou plusieurs modes de réalisation, le tableau des lignes du calendrier du bon de commande 1104 contient un champ de clé d'article du bon de commande (clé principale), un champ de la première originelle, un champ de la quantité confirmée du BC et un champ de la date sur site confirmée du BC. [0103] Dans un ou plusieurs modes de réalisation, le tableau des données AMI 1106 comprend un champ du numéro de livraison (clé principale) et un champ du numéro du document AMI. [0104] Dans un ou plusieurs modes de réalisation, le tableau du matériau de l'usine 1108 comprend un champ de clé de matériau de l'usine, un champ du centre de profit et un champ PSL. [0105] Dans un ou plusieurs modes de réalisation, le tableau des lignes du calendrier du bon de vente 1110 contient un champ du numéro du bon de vente (clé étrangère), un champ du numéro d'article du bon de vente, un champ de données de confirmation sur site et un champ de quantité 10 confirmée. [0106] Dans un ou plusieurs modes de réalisation, le tableau des dates d'articles du bon de vente 1112 comprend un champ de clé d'article du bon de vente (clé étrangère) et un champ de la date de première confirmation. [0107] Dans un ou plusieurs modes de réalisation, illustrés dans la Fig. 12, les données provenant 15 du portail des événements additionnels 112 accompagnées des rapports du transitaire et du courtier des douanes sont ajoutés au tableau des commandes ouvertes 1010 où les données EDI ne sont pas reçues. Dans un ou plusieurs modes de réalisation, la priorité des événements est la suivante : EDI > données mensuelles du transitaire > données AEP. Dans un ou plusieurs modes de réalisation, une clé de référence est créée dans le tableau des événements logistiques 906 pour des raisons qui 20 sont présentées ci-dessous en relation avec la Fig. 13. [0108] Dans un ou plusieurs modes de réalisation, le tableau des dates de livraison 912 (présenté ci-dessus en relation avec la Fig. 9) a une relation d'un à un avec le tableau des données mensuelles du courtage douanier 704 (présenté ci-dessus en relation avec la Fig. 7), le tableau des données mensuelles du transitaire 702 (présenté ci-dessus en relation avec la Fig. 6), un tableau des 25 événements du portail des événements additionnels 1204 et le tableau des commandes ouvertes 1010 (présenté ci-dessus en relation avec la Fig. 10). Le tableau des commandes ouvertes 1010 a une relation d'un à un avec le tableau des événements logistiques 906 (présenté ci-dessus en relation avec la Fig. 9). Le tableau des données mensuelles du courtage douanier 704 et le tableau des données mensuelles du transitaire 702 ont une relation d'un à zéro ou de plusieurs avec un tableau des événements logistiques 906. [0109] Dans un ou plusieurs modes de réalisation, le tableau des événements du portail des événements additionnels 1204 comprend un champ du numéro de référence (clé principale), un 5 champ de date ATD, un champ de date ATA, un champ de date de départ des douanes, un champ BOL est un champ de type d'événement. [0110] Dans un ou plusieurs modes de réalisation, illustrés dans la Fig. 13, le tableau de toutes les commandes 1102 (présenté ci-dessus en relation avec la Fig. 11) a une relation d'un à zéro ou de plusieurs avec un tableau de liaison 1302. Le tableau des liaisons 1302 a une relation d'un à zéro 10 avec le tableau des événements logistiques 906 (présenté ci-dessus en relation avec la Fig. 9). Le tableau de toutes les commandes 1102 a une relation d'un à un avec le tableau des données AMI 1106. Le tableau des données AMI 1106 (présenté ci-dessus en relation avec la Fig. 11) a une relation d'un à zéro ou de plusieurs avec un tableau d'équipement maître 1306. Le tableau de toutes les commandes 1102 a une relation d'un à un avec le tableau des données de l'association des envois 15 1308. [0111] Dans un ou plusieurs modes de réalisation, le tableau de liaison 1302 comporte un champ de clé d'ordre (clé étrangère) et un champ du numéro de référence (clé étrangère). Dans un ou plusieurs modes de réalisation, le tableau de liaison 1302 est utilisé pour éviter des informations en double ou redondantes dans le tableau de toutes les commandes 1102 étant donné que les 20 événements logistiques sont reçus de plusieurs sources à de multiples niveaux (unité de manipulation, envoi, article du BC, livraison et facture). Afin d'afficher des événements à chaque niveau, une clé du niveau le plus bas a été créée pour associer les données des événements aux données de toutes les commandes. [0112] Dans un ou plusieurs modes de réalisation, le tableau des équipements maîtres 1306 25 comporte un champ de numéro d'équipement (clé étrangère) et un champ de description des équipements. [0113] Dans un ou plusieurs modes de réalisation, le tableau des données de l'association des envois 1308 comporte un champ du numéro d'envoi et un champ du numéro d'association d'envoi.
Application de la présentation de la visualisation [0114] Dans un ou plusieurs modes de réalisation, l'application de présentation de la visualisation (c.-à-d., l'application de visualisation de la chaîne d'approvisionnement) 220 améliore et renforce le processus de la chaîne d'approvisionnement en rendant facilement disponibles les informations sur les commandes ouvertes à tous les actionnaires ; permettant des communications améliorées, une meilleure planification, une gestion des exceptions ; et permettant des décisions commerciales proactives afin d'assurer des livraisons à temps. Dans un ou plusieurs modes de réalisation, l'algorithme de présentation de la visualisation 220 permet aux utilisateurs de suivre les livraisons d'un fabricant ou d'un fournisseur jusqu'à un port. Dans un ou plusieurs modes de réalisation, l'algorithme de présentation de la visualisation 220 donne également la possibilité de suivre des mouvements multi-bras qui nécessitent des modes de transplantation pas air, par mer, par camion et/ou par rail. Dans un ou plusieurs modes de réalisation, l'algorithme de présentation de la visualisation 220 donne la possibilité de suivre des marchandises lorsqu'elles passent à travers les douanes dans différents pays. [0115] Dans un ou plusieurs modes de réalisation, l'algorithme de présentation de la visualisation 220 constitue un outil par lequel la performance des transitaires, des courtiers de douane et d'autres entités de ce type peuvent être analysées. Par ex., en référence à la Fig. 1, si une cargaison provenant d'une entreprise 114 à travers les transitaires 142 et 150 arrive à la destination finale 154 avant une cargaison transportée par le transitaire 138, ces informations peuvent être utiles pour juger de la performance des transitaires 142, 150, 154 et de l'agent du port 146. Par ex, une telle analyse peut entraîner l'utilisation plus fréquente d'un transitaire par rapport à un autre ou à une décision d'utiliser un transitaire donné seulement d'une certaine façon, par ex pour les voies terrestres plutôt qu'aériennes, le chemin de fer, les voies par charter et les voies maritimes. Ainsi, l'application de la présentation de la visualisation 220 constitue un outil avec lequel le département de la logistique d'une entreprise peut analyser et améliorer sa performance. [0116] Dans un ou plusieurs modes de réalisation, l'application de présentation de la visualisation 220 comporte la fonctionnalité suivante, illustrée par les onglets sur la capture d'écran illustrée dans la Fig. 14: - Toutes les commandes : Résumé de la commande complétée avec des jalons logistiques et la date d'arrivée prévue ; - Suivi de l'événement d'envoi : Page de suivi détaillée pour les commandes individuelles ; - Recherche de commandes multiples : Résumé de commande pour les numéros de référence demandés ; - Statistiques du réseau logistique : Analyse sur les fournisseurs par pays et par volume ; - Bons de ventes annulés : Détails des bons de commande ouverts avec des bons de ventes annulées ; et - Méthodologie et Manuel : manuel d'apprentissage et de documentation. Critère de recherche [0117] Dans un ou plusieurs modes de réalisation, comme le montre la Fig. 15, on peut rechercher les commandes par : - origine, y compris l'usine et le pays ; - destination, y compris le pays de destination, le récipiendaire, l'acheteur et le pays d'achat ; - mode de transport, niveau de service , PSL de commande, sous PSL, PSL matériel ; - mouvement, type y compris le type d'origine (fabrication, fournisseur, redéploiements de champ) et type de destination (fabrication, champs et clients). - GR Oui/Non - Aide les utilisateurs à choisir des commandes ouvertes ou fermées - AMI Oui/Non - Choix des actifs - Créée par la livraison - l'utilisateur peut sélectionner des commandes pour lesquelles une livraison a été créée - BC de valeur - On peut facilement rechercher des BC de valeur [0118] Dans un ou plusieurs modes de réalisation, les utilisateurs peuvent rechercher des commandes directement par numéro de référence (numéro de BC, numéro de bons de vente, numéro de livraison, numéro d'envoi, numéro de matériel, numéro du document AMI ou document de facturation/numéro de facture). Toutes les commandes [0119] Dans un ou plusieurs modes de réalisation, le fait de choisir l'onglet « toutes les commandes » génère un détail du niveau matériel avec des dates logistiques clés sur la page de résumé, illustré dans la Fig. 16 (nom des colonnes seulement), qui permet aux utilisateurs de visualiser rapidement leurs commandes avec un minimum d'efforts et de sélection. Dans un ou plusieurs modes de réalisation, ce tableau comporte des détails complets provenant des bons de commande, des bons de vente, des informations sur le matériel, l'envoi, la livraison, la facture, la quantité, la quantité confirmée, la date de livraison prévue, les dates clés logistiques, la date GR, le PSL, le mode, et les informations d'origine et de destination. Toutes les commandes (Résumé logistique) [0120] Dans un ou plusieurs modes de réalisation, un écran « Toutes les commandes » (résumé logistique), illustré dans la Fig. 17 (noms de colonne seulement) procure un résumé de la commande au niveau de l'envoi/de la facture 100 sans doublement des données au niveau du matériel, qui procure un récapitulatif rapide des commandes ouvertes (non pas de la réception des marchandises) pour que le personnel logistique entre des événements sur le portail des événements additionnels. Dans un ou plusieurs modes de réalisation, l'écran affiche également aux gestionnaires un récapitulatif rapide des cargaisons ouvertes et en transit par BOL, Origine, Destination et PSL.
Suivi de cargaison [0121] Dans un ou plusieurs modes de réalisation, la page de suivi de la cargaison de l'outil, illustrée dans la Fig. 18, permet un suivi détaillé de chaque commande à partir de la livraison pour créer un GR. Dans un ou plusieurs modes de réalisation, l'utilisateur peut faire une recherche avec un quelconque numéro de référence d'une commande. Dans un ou plusieurs modes de réalisation, cette fonctionnalité permet un accès facile aux dates de logistique et de SAP® à partir de multiples sources au niveau d'un emplacement. Dans un ou plusieurs modes de réalisation, l'utilisation peut retrouver les détails complets du suivi avec tous les scans comprenant, sans limitation, des scans de transbordement reçu/embarquement, usine de l'origine de départ, événements de transitaire provenant de multiples sources, événements SAP et également un événement au niveau du bon de commande (date GR). [0122] Dans un ou plusieurs modes de réalisation, toutes les commandes peuvent être suivies à l'aide d'un numéro de référence SAP® ou même une référence externe BOL et le numéro de la déclaration des douanes. Dans un ou plusieurs modes de réalisation, les événements illustrés ne sont pas doublés au niveau de chaque boîte alors que la logique a été intégrée dans le modèle de données pour consolider les événements en se basant sur le numéro de référence le plus grand. Outil de visualisation historique [0123] Dans un ou plusieurs modes de réalisation, l'outil de visualisation de la chaîne d'approvisionnement rejette toutes les commandes qui ont des dates GR supérieures à 30 jours à partir de la date actuelle. Dans un ou plusieurs modes de réalisation, ces commandes fermées peuvent être consultées dans un rapport de visualisation historique qui utilise le même concept que le modèle des données de la visualisation de la chaîne d'approvisionnement mais restreintes aux commandes fermées. Dans un ou plusieurs modes de réalisation, le rapport historique est accessible aux utilisateurs à partir de l'outil de visualisation de la chaîne d'approvisionnement en cliquant sur la touche « Données historiques » illustrée dans la figure 15, qui transfert les sélections actuelles à partir du rapport existant vers un nouveau rapport. Dans un ou plusieurs modes de réalisation, cette fonctionnalité utilise la caractéristique « enchaînement de documents » du QLIKVIEW®. La couche de présentation et le critère de sélection sur le rapport de la visualisation historique sont les mêmes que pour l'outil de visualisation de la chaîne d'approvisionnement, ce qui fait que les utilisateurs peuvent facilement extraire et analyser des données de commandes fermées. Statistiques du réseau logistique [0124] Dans un ou plusieurs modes de réalisation, un outil statistique du réseau logistique, illustré dans la Fig. 19, procure une analyse des envois du fournisseur et le volume de commandes par pays.
Statistiques de l'annulation des bons de vente [0125] Dans un ou plusieurs modes de réalisation, un outil de notification de l'annulation des bons de vente, illustré dans la Fig. 20, permet une visualisation des bons de vente annulés, lorsque les bons de commande ne sont pas identifiés comme supprimés dans SAP®. Les utilisateurs de l'approvisionnement et des matériaux peuvent identifier le problème avec les bons de commande ouverts lorsque des bons de vente ont été annulés et peuvent prendre les mesures nécessaires. Recherche de multiples commandes [0126] Dans un ou plusieurs modes de réalisation, une recherche avancée de multiples commandes est un formulaire libre de modèle de recherche (non illustré) conçu pour les utilisateurs expérimentés qui se sentent à l'aise pour utiliser des fonctions étendues pour suivre un numéro de BC, des factures, des cargaisons, des livraisons et des matériaux. Une fois que l'utilisateur a saisi ou copié les sélections connues, c.-à-d., les bons de commande, séparés par des virgules ou des espaces, le système procure des détails sur ces sélections, tels que les détails décrits ci-dessus en relation avec la discussion sur l'onglet « Toutes les commandes » de la Fig. 16. [0127] Dans un ou plusieurs modes de réalisation, le délai matériel est utilisé pour vérifier des événements prévus à chaque emplacement clé. Afin de livrer un produit à la date de livraison prévue, il est possible de calculer la sortie des marchandises d'un emplacement de fabrication ou d'un fournisseur en utilisant le délai total de la date à laquelle la commande doit être livrée. [0128] Dans un ou plusieurs modes de réalisation, des indicateurs de lumière d'arrêt par ligne de BC/cargaison basée sur la logique de livraison prévue permet une gestion des exceptions proactive en amont. Dans un ou plusieurs modes de réalisation, des décisions commerciales critiques pourraient être prises à temps pour soit changer le mode de transport soit pour rechercher un autre fournisseur afin d'éviter les retards de livraison aux clients. [0129] Dans un ou plusieurs modes de réalisation, une notification par e-mail est fournie avec le suivi des commandes. Dans un ou plusieurs modes de réalisation, des détails complets du suivi sont fournis aux clients à travers une notification automatique des événements clés. Dans un ou plusieurs modes de réalisation, des données SAP® intégrées aux événements du transitaire ou du courrier sont envoyées sur demande par le système. [0130] Dans un ou plusieurs modes de réalisation, une notification du suivi multi-bras est ajoutée pour aider le transbordement et les clients à obtenir des pré-alertes pour l'arrivée prévue à chaque bras de l'expédition. [0131] Dans un aspect, un processeur calcule la date de réception de marchandise (GR) pour un article de la ligne du bon de commande (POLI) basé sur les multiples cargaisons liées au POLI et les multiples GR liées au POLI saisies à un emplacement sur le terrain. [0132] Dans un aspect, de multiples livraisons liées à un article de la ligne du bon de commande (POLI) sont identifiées. Chacune des multiples livraisons possède une quantité de livraison est une date de sortie de marchandises (PGI). Chaque date PGI représente la date à laquelle les marchandises pour la livraison respective ont été physiquement déplacées d'un entrepôt vers une usine. Les dates PGI ont un ordre. De multiples envois, chacun lié à une livraison, sont identifiés. Chacun des multiples envois possède une quantité d'envoi. Des événements de multiples marchandises reçues (GR) pour les livraisons multiples liées au POLI sont identifiés. Chacun des multiples événements GR a une quantité GR et une date GR. Les dates GR ont un ordre. Une quantité requise pour le POLI est identifiée. Un processeur calcule un réseau GR Date 1 en : faisant correspondre les quantités de livraison liées aux POLI aux quantités GR des multiples événements GR liés au POLI. La correspondance est ambiguë parce qu'au moins une partie des quantités de livraison liées au POLI est égale et au moins une partie des quantités GR liées au POLI est égale. L'ambiguïté est résolue en donnant la préférence à l'alignement de l'ordre des dates PGI à l'ordre des dates GR. Pour chaque livraison, la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour chaque correspondance est enregistré dans le réseau GR Date 1. Le processeur calcule un réseau GR Date 2 en totalisant les quantités de livraison des livraisons liées à cet envoi, en faisant correspondre les quantités de livraison totalisées avec les quantités GR, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR dans le réseau GR Date 2. Le processeur calcule un réseau GR Date 3 en totalisant les quantités GR d'un groupe d'événements GR de sorte que le total corresponde à une quantité de livraison de l'une des multiples livraisons, la détermination d'un maximum pour les dates GR à partir des événements GR et en enregistrant comme maximum GR date 3, en changeant les dates GR des événements GR dans le groupe pour le maximum GR date 3, et, pour chaque livraison, l'enregistrement de la quantité de livraison, de la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée GR dans le réseau GR Date 3. Le processeur calcule un réseau GR Date 4 en totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities, la détermination que la summed GR quantities est égale à la quantité requise pour le POLI, la détermination d'un maximum pour les dates GR à partir des événements GR multiples et en l'enregistrant comme maximum GR date 4, en changeant les dates GR des événements GR multiples pour le maximum GR date 4, et, pour chaque livraison, l'enregistrement de la quantité de livraison, de la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée GR dans le réseau GR Date 4. Pour chaque envoi, une ATA Date est identifiée comme le temps réel de l'arrivée de la cargaison. La condition suivante est déterminée comme étant fausse pour au moins l'une des livraisons : (date GR de GR Date 1 > ATA Date et date GR de GR Date 1 > PGI Date). La condition suivante est déterminée comme étant fausse pour au moins l'une des livraisons : (date GR de GR Date 2 > ATA Date et date GR de GR Date 2 > PGI Date). La condition suivante est déterminée comme étant fausse pour au moins l'une des livraisons : (date GR de GR Date 3 > ATA Date et date GR de GR Date 3 > PGI Date). La condition suivante est déterminée comme étant fausse pour au moins l'une des livraisons : (date GR de GR Date 4 > ATA Date et date GR de GR Date 4 > PGI Date). Par conséquent, on détermine que le bon de commande est toujours ouvert. [0133] Dans un aspect, de multiples livraisons liées à un article de la ligne du bon de commande (POLI) sont identifiées. Chacune des multiples livraisons possède une quantité de livraison et une date de sortie de marchandises (PGI). Chaque date PGI représente la date à laquelle les marchandises pour la livraison respective ont été physiquement déplacées d'un entrepôt vers une usine. Les dates PGI ont un ordre. De multiples envois, chacun lié à une livraison, sont identifiés.
Chacun des multiples envois possède une quantité d'envoi. Des événements de multiples marchandises reçues (GR) sont identifiés pour les livraisons multiples liées au POLI. Chacun des multiples événements GR a une quantité GR et une date GR. Les dates GR ont un ordre. Une quantité requise pour le POLI est identifiée. Un processeur calcule un réseau GR Date 1 en faisant correspondre les quantités de livraison liées aux POLI aux quantités GR des multiples événements GR liés au POLI. La correspondance est ambiguë parce qu'au moins une partie des quantités de livraison liées au POLI est égale et au moins une partie des quantités GR liées au POLI est égale. L'ambiguïté est résolue en donnant la préférence à l'alignement de l'ordre des dates PGI à l'ordre des dates GR. Pour chaque livraison, la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour chaque correspondance sont enregistrés dans le réseau GR Date 1. Le processeur calcule un réseau GR Date 2 en totalisant les quantités de livraison des livraisons liées à cet envoi, en faisant correspondre les quantités de livraison totalisées avec les quantités GR, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR dans le réseau GR Date 2. Le processeur calcule un réseau GR Date 3 en totalisant les quantités GR d'un groupe d'événements GR de sorte que le total corresponde à une quantité de livraison de l'une des multiples livraisons, la détermination d'un maximum pour les dates GR à partir des événements GR et en enregistrant comme maximum GR date 3, en changeant les dates GR des événements GR dans le groupe pour le maximum GR date 3, et, pour chaque livraison, l'enregistrement de la quantité de livraison, de la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée GR dans le réseau GR Date 3. Le processeur calcule un réseau GR Date 4 en totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities, la détermination que la summed GR quantities est égale à la quantité requise pour le POLI, la détermination d'un maximum pour les dates GR à partir des événements GR multiples et en l'enregistrant comme maximum GR date 4, en changeant les dates GR des événements GR multiples pour le maximum GR date 4, et, pour chaque livraison, l'enregistrement de la quantité de livraison, de la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée GR dans le réseau GR Date 4, et, pour chaque envoi, la détermination d'une date ATA date comme étant l'heure réelle de l'arrivée de l'envoi. La condition GRDATE1 est déterminée comme étant vraie pour au moins l'une des livraisons : (date GR de GR Date 1 > ATA Date et date GR de GR Date 1 > PGI Date). La définition d'une date GR pour chacune de l'au moins une livraison pour laquelle la condition GRDATE1 est vraie pour la date GR respective pour la livraison dans le réseau GR Date 1. [0134] Dans un aspect, des articles de multiples livraisons liées à un article de la ligne du bon de commande (POLI) sont identifiés. Chacune des articles des multiples livraisons possède une quantité de livraison et une date de sortie de marchandises (PGI). Chaque date PGI représente la date à laquelle les marchandises pour l'article de livraison respective ont été physiquement déplacées d'un entrepôt vers une usine. Les dates PGI ont un ordre. De multiples cargaisons sont identifiées. Chacun des multiples envois possède une quantité d'envoi. Chaque envoi est lié à une livraison. Chaque livraison est liée à un article de livraison. Au moins l'une des livraisons est liée à une pluralité d'articles de livraison. Des événements de multiples marchandises reçues (GR) pour les multiples articles de livraisons liés au POLI sont identifiés. Chacun des multiples événements GR a une quantité GR et une date GR. Les dates GR ont un ordre. Une quantité requise pour le POLI est identifiée. Un processeur calcule un réseau GR Date 1 en faisant correspondre les quantités d'article de livraison liées aux POLI aux quantités GR des multiples événements GR liés au POLI. La correspondance est ambiguë parce qu'au moins une partie des quantités d'article de livraison liées au POLI est égale et au moins une partie des quantités GR liées au POLI est égale.
L'ambiguïté est résolue en donnant la préférence à l'alignement de l'ordre des dates PGI à l'ordre des dates GR. Pour chaque article de livraison, la quantité d'article de livraison, la date PGI pour la quantité d'article de livraison, la quantité GR et la date GR pour chaque correspondance sont enregistrées dans le réseau GR Date 1. Le processeur calcule un réseau GR Date 2 en totalisant les quantités d'article de livraison des articles de livraisons liées à cet envoi, en faisant correspondre les quantités d'article de livraison totalisées avec les quantités GR, et pour chaque livraison, l'enregistrement de la quantité d'article de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR dans le réseau GR Date 2. Le processeur calcule un réseau GR Date 3 en totalisant les quantités GR d'un groupe d'événements GR de sorte que le total corresponde à une quantité d'article de livraison de l'une des multiples livraisons, la détermination d'un maximum pour les dates GR à partir du groupe des événements GR et en l'enregistrant sous forme de maximum GR date 3, en changeant les dates GR des événements GR dans le groupe pour le maximum GR date 3, et, pour chaque article de livraison, l'enregistrement de la quantité d'article de livraison, de la date PGI pour la quantité d'article de livraison, la quantité GR totalisée et la date GR changée GR dans le réseau GR Date 3. Le processeur calcule un réseau GR Date 4 en totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities, la détermination que la summed GR quantities est égale à la quantité requise pour le POLI, la détermination d'un maximum pour les dates GR à partir des multiples événements GR et en l'enregistrant comme maximum GR date 4, en changeant les dates GR des événements GR multiples pour le maximum GR date 4, et, pour chaque article de livraison, l'enregistrement de la quantité d'article de livraison, de la date PGI pour la quantité d'article de livraison, la quantité GR totalisée et la date GR changée GR dans le réseau GR Date 4. Pour chaque envoi, une ATA date est identifiée comme l'heure réelle de l'arrivée de la cargaison. La condition GRDATE1 suivante est déterminée comme fausse pour au moins l'un des articles de livraison : (date GR de GR Date 1 > ATA Date et date GR de GR Date 1 > PGI Date). La condition GRDATE2 suivante est déterminée comme étant vraie pour au moins l'une des livraisons. (date GR de GR Date 2 > ATA Date et date GR de GR Date 2 > PGI Date). La date GR pour chacune des livraisons pour laquelle la condition GRDATE2 est vraie sont définies comme la date GR respective pour la livraison dans le réseau GR Date 2. [0135] Dans un aspect, de multiples livraisons liées à un article de la ligne du bon de commande (POLI) sont identifiées. Chacune des multiples livraisons possède une quantité de livraison et une date de sortie de marchandises (PGI). Chaque date PGI représente la date à laquelle les marchandises pour la livraison respective ont été physiquement déplacées d'un entrepôt ou une usine. Les dates PGI ont un ordre. De multiples envois, chacun lié à une livraison, sont identifiés. Chacun des multiples envois possède une quantité d'envoi. Des événements de multiples marchandises reçues (GR) pour les livraisons multiples liées au POLI sont identifiés. Chacun des multiples événements GR a une quantité GR et une date GR. Les dates GR ont un ordre. Une quantité requise pour le POLI est identifiée. Un processeur calcule un réseau GR Date 1 en faisant correspondre les quantités de livraison liées aux POLI aux quantités GR des multiples événements GR liés au POLI. Ici, la correspondance est ambiguë parce qu'au moins une partie des quantités de livraison liées au POLI est égale et au moins une partie des quantités GR liées au POLI est égale.
L'ambiguïté est résolue en donnant la préférence à l'alignement de l'ordre des dates PGI à l'ordre des dates GR. Pour chaque livraison, la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour chaque correspondance sont enregistrés dans le réseau GR Date 1. Le processeur calcule un réseau GR Date 2 en totalisant les quantités de livraison des livraisons liées à cet envoi, en faisant correspondre les quantités de livraison totalisées avec les quantités GR, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR dans le réseau GR Date 2. Le processeur calcule un réseau GR Date 3 en totalisant les quantités GR d'un groupe d'événements GR de sorte que le total corresponde à une quantité de livraison de l'une des multiples livraisons, la détermination d'un maximum pour les dates GR à partir des événements GR et en enregistrant comme maximum GR date 3, en changeant les dates GR des événements GR dans le groupe pour le maximum GR date 3, et, pour chaque livraison, l'enregistrement de la quantité de livraison, de la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 3. Le processeur calcule un réseau GR Date 4 en totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities, la détermination que la summed GR quantities est égale à la quantité requise pour le POLI, la détermination d'un maximum pour les dates GR à partir des événements GR multiples et en l'enregistrant comme maximum GR date 4, en changeant les dates GR des événements GR multiples pour le maximum GR date 4 ; pour chaque livraison, l'enregistrement de la quantité de livraison, de la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 4. Pour chaque envoi, une ATA date est identifiée comme l'heure réelle de l'arrivée de la cargaison. La condition GRDATE1 est déterminée comme étant fausse pour au moins l'une des livraisons : (date GR de GR Date 1 > ATA Date et date GR de GR Date 1 > PGI Date). La condition GRDATE2 suivante est déterminée comme étant fausse pour au moins l'une des livraisons : (date GR de GR Date 2 > ATA Date et date GR de GR Date 2 > PGI Date). La condition GRDA1E3 suivante est déterminée comme vraie pour au moins l'une des livraisons : (date GR de GR Date 3 > ATA Date et date GR de GR Date 3 > PGI Date). La date GR pour chacune de l'au moins une livraison pour laquelle la condition GRDATE3 est vraie pour la date GR respective pour la livraison dans le réseau GR Date 3. [0136] Dans un aspect, de multiples livraisons liées à un article de la ligne du bon de commande (POLI) sont identifiées. Chacune des multiples livraisons possède une quantité de livraison et une date de sortie de marchandises (PGI). Chaque date PGI représente la date à laquelle les marchandises pour la livraison respective ont été physiquement déplacées d'un entrepôt vers une usine. Les dates PGI ont un ordre. De multiples envois, chacun lié à une livraison, sont identifiés. Chacun des multiples envois possède une quantité d'envoi. Des événements de multiples marchandises reçues (GR) pour les livraisons multiples liées au POLI sont identifiés. Chacun des multiples événements GR a une quantité GR et une date GR. Les dates GR ont un ordre. Une quantité requise pour le POLI est identifiée. Un processeur calcule un réseau GR Date 1 en faisant correspondre les quantités de livraison liées aux POLI aux quantités GR des multiples événements GR liés au POLI. La correspondance est ambiguë parce qu'au moins une partie des quantités de livraison liées au POLI est égale et au moins une partie des quantités GR liées au POLI est égale.
L'ambiguïté est résolue en donnant la préférence à l'alignement de l'ordre des dates PGI à l'ordre des dates GR. Pour chaque livraison, la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour chaque correspondance sont enregistrés dans le réseau GR Date 1. Le processeur calcule un réseau GR Date 2 en totalisant les quantités de livraison des livraisons liées à cet envoi, en faisant correspondre les quantités de livraison totalisées avec les quantités GR, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR dans le réseau GR Date 2. Le processeur calcule un réseau GR Date 3 en totalisant les quantités GR d'un groupe d'événements GR de sorte que le total corresponde à une quantité de livraison de l'une des multiples livraisons, la détermination d'un maximum pour les dates GR à partir des événements GR et en enregistrant comme maximum GR date 3, en changeant les dates GR des événements GR dans le groupe pour le maximum GR date 3, et, pour chaque livraison, l'enregistrement de la quantité de livraison, de la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 3. Le processeur calcule un réseau GR Date 4 en totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities, la détermination que la summed GR quantities est égale à la quantité requise pour le POLI, la détermination d'un maximum pour les dates GR à partir des événements GR multiples et en l'enregistrant comme maximum GR date 4, en changeant les dates GR des événements GR multiples pour le maximum GR date 4, et, pour chaque livraison, l'enregistrement de la quantité de livraison, de la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 4. Pour chaque envoi, une ATA date est identifiée comme l'heure réelle de l'arrivée de la cargaison. La condition GRDA1E1 est déterminée comme étant vraie pour au moins l'une des livraisons : (date GR de GR Date 1 > ATA Date et date GR de GR Date 1 > PGI Date). La condition GRDA1E2 suivante est déterminée comme étant fausse pour au moins l'une des livraisons : (date GR de GR Date 2 > ATA Date et date GR de GR Date 2 > PGI Date). La condition GRDATE3 suivante est déterminée comme étant fausse pour au moins l'une des livraisons : (date GR de GR Date 3 > ATA Date et date GR de GR Date 3 > PGI Date). La condition GRDATE4 suivante est déterminée comme étant fausse pour au moins l'une des livraisons : (date GR de GR Date 4 > ATA Date et date GR de GR Date 4 > PGI Date). La définition d'une date GR pour chacune de l'au moins une livraison pour laquelle la condition GRDATE4 est vraie pour la date GR respective pour la livraison dans le réseau GR Date 4. [0137] Dans un aspect, un processeur reçoit et stocke des données logistiques concernant un article de la ligne du bon de commande (POLI). Les données logistiques comprennent une pluralité d'envois. Chaque envoi comprend des livraisons liées à un article de la ligne du bon de commande (POLI). Chacune des livraisons possède une quantité de livraison et une date de sortie de marchandises (PGI). Les données logistiques comprennent également une pluralité de services logistiques pour la pluralité des envois y compris les livraisons liées au POLI. L'un de la pluralité des envois, un envoi multi-mode, comporte une pluralité de services logistiques séquentiels. Les données logistiques comprennent également une pluralité de livraisons liée au POLI, dans laquelle le processeur identifie une quantité de marchandises reçues (GR), et une date GR pour chaque livraison. Le processeur permet un affichage de la date PGI et de la date GR pour l'envoi multimode. [0138] Les implémentations de l'invention peuvent comprendre un ou plusieurs des éléments suivants. Le processeur recevant et stockant des données logistiques concernant le POLI peut comprendre la réception des données provenant des fournisseurs de données logistiques choisis dans un groupe composé de transitaires et des courtiers des douanes. La pluralité des services logistiques séquentiels peut comprendre un premier mode de transport opéré par un premier fournisseur, le premier fournisseur transportant la cargaison multi-mode d'un premier endroit vers un deuxième endroit, et un deuxième mode de transport opéré par un deuxième fournisseur, différent du premier, le deuxième fournisseur transportant la cargaison multi-mode d'un deuxième endroit vers un troisième endroit. La détermination de la date GR pour chacune des livraisons peut impliquer le calcul des dates GR par le processeur pour les livraisons liées à la cargaison multi-mode basé sur la pluralité des livraisons liée au POLI. La pluralité des services logistiques séquentiels peut comprendre un service fourni par une compagnie de manutention de fret, un service fourni par une compagnie de courrier et un service fourni par un courtier des douanes logistique. La pluralité des services logistiques séquentiels peut être choisie dans un groupe composé d'un service fourni par une compagnie de manutention de fret, un service fourni par une compagnie de courrier et un service fourni par un courtier des douanes logistique. [0139] Le mot « couplé » utilisé ici veut dire une connexion directe ou une connexion indirecte. [0140] Le texte présenté ci-dessus décrit un ou plusieurs modes de réalisation spécifiques d'une invention plus large. L'invention est également réalisée dans une diversité de modes de réalisation alternatifs et n'est donc pas limitée à ceux décrits ici. La description précédente d'un mode de réalisation de l'invention a été présentée dans un but illustratif et descriptif. Elle n'est pas destinée à être exhaustive ou à limiter l'invention à la forme précise divulguée. Beaucoup de modifications et de variations sont possibles à la lumière des enseignements donnés ci-dessus. Il est envisagé que la portée de cette invention soit limitée non pas par la description détaillée, mais plutôt par les revendications ci-jointes.30

Claims (12)

  1. REVENDICATIONS1. Procédé comprenant : un processeur calculant la date de marchandises reçues (GR) pour un article de la ligne du bon de commande (POLI) basé sur les multiples envois liés au POLI et les multiples GR lié au POLI saisis dans un champ d'emplacement.
  2. 2. Procédé comprenant : l'identification de multiples livraisons liées à un article de la ligne du bon de commande (POLI), chacune des multiples livraisons ayant une quantité de livraison et une date de sortie de marchandise (PGI), chaque date PGI étant la date que les marchandises pour la livraison respective ont été physiquement déplacées d'un entrepôt vers une usine, les dates de PGI ayant un ordre ; l'identification de multiples envois chacun lié à une livraison, dans lequel chacun des multiples envois a une quantité d'envoi ; l'identification de multiples événements de marchandises reçues (GR) pour les multiples livraisons liées au POLI, où chacun des multiples événements GR a une quantité GR et une date GR, et où les dates GR ont un ordre ; l'identification d'une quantité requise pour le POLI; un processeur calculant un réseau GR Date 1 en : faisant correspondre les quantités de livraison liées à un POLI aux quantités GR des multiples événements GR liés au POLI, dans lequel la correspondance est ambiguë parce qu'au moins une partie des quantités de livraison liées au POLI est égale et au moins une partie des quantités GR liées au POLI est égale, la résolution de cette ambiguïté en donnant la préférence à l'alignement de l'ordre des dates de PGI par rapport à l'ordre des dates GR, pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, et la date GR pour chaque correspondance dans le réseau GR Date 1 le processeur calculant un réseau GR Date 2 en : totalisant les quantités de livraison des livraisons liées au même envoi, faisant correspondre les quantités de livraison totalisée aux quantités GR, etpour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour le réseau GR Date 2 le processeur calculant un réseau GR Date 3 en : totalisant les quantités GR d'un groupe d'événements GR de sorte que la somme corresponde à une quantité de livraison de l'une des multiples livraisons, déterminant un maximum des dates GR à partir du groupe d'événements GR et en l'enregistrant sous forme de maximum GR date 3, changeant les dates GR des événements GR dans le groupe pour 1() maximum GR date 3, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 3 ; le processeur calculant un réseau GR Date 4 en : 15 totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities ; déterminer que la summed GR quantities est égale à la quantité requise pour le POLI, déterminer un maximum des dates GR à partir des multiples événements GR et 20 l'enregistrer sous forme de maximum GR date 4, modifier les dates GR des multiples événements GR pour le maximum GR date 4, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le 25 réseau GR Date 4 ; pour chaque envoi, détermination d'une ATA date comme l'heure réelle de l'arrivée de la cargaison. la détermination que la condition suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date I > ATA Date et date GR de GR Date I > PGI Date) ; 30 la détermination que la condition suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 2 > ATA Date et date GR de GR Date 2 > PGI Date) ; la détermination que la condition suivante est fausse pour au moins l'une des livraisons :(date GR de GR Date 3 > ATA Date et date GR de GR Date 3 > PGI Date) ; la détermination que la condition suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 4 > ATA Date et date GR de GR Date 4 > PGI Date) ; et la détermination, par conséquent, que le bon de commande est toujours ouvert.
  3. 3. Procédé comprenant : l'identification de multiples livraisons liées à un article de la ligne du bon de commande (POLI), dans laquelle chacune des livraisons multiples a une quantité de livraison et une date de sortie de marchandise (PGI), chaque date PGI étant la date à laquelle les marchandises pour la livraison respective ont été physiquement déplacées d'un il) entrepôt vers une usine, les dates PGI ayant un ordre ; l'identification de multiples envois chacun lié à une livraison, dans laquelle chacun des multiples envois a une quantité d'envoi ; l'identification de multiples événements de marchandises reçues (GR) pour les multiples livraisons liées au POLI, où chacun des multiples événements GR a une quantité GR 15 et une date GR, et où les dates GR ont un ordre ; l'identification d'une quantité requise pour le POLI; un processeur calculant un réseau GR Date 1 en : faisant correspondre les quantités de livraison liées à un POLI aux quantités GR des multiples événements GR liés au POLI, 20 dans lequel la correspondance est ambiguë parce qu'au moins une partie des quantités de livraison liées au POLI est égale et au moins une partie des quantités GR liées au POLI est égale, la résolution de cette ambiguïté en donnant la préférence à l'alignement de l'ordre des dates de PGI par rapport à l'ordre des dates GR, 25 pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, et la date GR dans le réseau GR Date 1 le processeur calculant un réseau GR Date 2 en : totalisant les quantités de livraison des livraisons liées au même envoi, faisant correspondre les quantités de livraison totalisée aux quantités GR, etpour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour le réseau GR Date 2 le processeur calculant un réseau GR Date 3 en : totalisant les quantités GR d'un groupe d'événements GR de sorte que la somme corresponde à une quantité de livraison de l'une des multiples livraisons, déterminant un maximum des dates GR à partir du groupe d'événements GR et en l'enregistrant sous forme de maximum GR date 3, changeant les dates GR des événements GR dans le groupe pour maximum GR date 3, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 3 ; le processeur calculant un réseau GR Date 4 en : totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities ; déterminer que la summed GR quantities est égale à la quantité requise pour le POLI, déterminer un maximum des dates GR à partir des multiples événements GR et l'enregistrer sous forme de maximum GR date 4, modifier les dates GR des multiples événements GR pour le maximum GR date 4, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 4 ; pour chaque envoi, détermination d'une ATA date comme l'heure réelle de l'arrivée de la cargaison ; détermination que la condition GRDATE1 suivante est vraie pour au moins l'une des livraisons : (date GR de GR Date 1 > ATA Date et date GR de GR Date 1 > PGI Date) ; etla définition d'une date GR pour chacune de l'au moins une livraison pour laquelle la condition GRDATE1 est vraie par rapport à la date GR respective pour la livraison dans le réseau GR Date 1.
  4. 4. Procédé comprenant : l'identification de multiples articles de livraisons liées à un article de la ligne du bon de commande (POLI), chacune des multiples articles de livraisons ayant une quantité de livraison d'article et une date de sortie de marchandise (PGI), chaque date PGI étant la date à laquelle les marchandises pour l'article de livraison respective ont été physiquement déplacées d'un entrepôt ou une usine, les dates de PGI ayant un ordre ; l'identification de multiples envois, dans laquelle chacun des multiples envois a une quantité d'envoi, dans laquelle chaque envoi est lié à une livraison, chaque livraison est liée à un article de livraison, et au moins une des livraisons est liée à une pluralité d'articles de livraison ; l'identification de multiples événements de marchandises reçues (GR) pour les multiples articles de livraisons liés au POLI, où chacun des multiples événements GR a une quantité GR et une date GR, et où les dates GR ont un ordre ; l'identification d'une quantité requise pour le POLI; un processeur calculant un réseau GR Date 1 en : faisant correspondre les quantités d'article de livraison liées aux POLI aux quantités GR des multiples événements GR liés au POLI, où la correspondance est ambiguë parce qu'au moins une partie des quantités d'article de livraison liée au POLI est égale et au moins une partie des quantités GR liée au POLI est égale, la résolution de cette ambiguïté en donnant la préférence à l'alignement de la commande des dates de PGI à la commande des dates de GR, et pour chaque article de livraison, l'enregistrement de la quantité d'article de livraison, la date PGI pour la quantité d'article de livraison, et la date GR pour chaque correspondance dans le réseau GR Date 1 ; le processeur calculant un réseau GR Date 2 en : totalisant les quantités d'article de livraison des articles de livraisons liées au même envoi,faisant correspondre les quantités d'article de livraison totalisée aux quantités GR, et pour chaque livraison, l'enregistrement de la quantité d'article de livraison totalisée, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour le réseau GR Date 2 ; le processeur calculant un réseau GR Date 3 en : totalisant les quantités GR d'un groupe d'événements GR de sorte que la somme corresponde à une quantité d'article de livraison de l'une des multiples livraisons, déterminant un maximum des dates GR à partir du groupe d'événements GR et en 1() l'enregistrant sous forme de maximum GR date 3, changeant les dates GR des événements GR dans le groupe pour maximum GR date 3, et pour chaque livraison, l'enregistrement de la quantité d'article de livraison, la date PGI pour la quantité d'article de livraison, la quantité GR totalisée et la date 15 GR changée dans le réseau GR Date 3 ; le processeur calculant un réseau GR Date 4 en : totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities ; déterminer que la summed GR quantities est égale à la quantité requise pour le 20 POLI, déterminer un maximum des dates GR à partir des multiples événements GR et l'enregistrer sous forme de maximum GR date 4, changer les dates GR des multiples événements GR au maximum GR date 4, pour chaque article de livraison, enregistrement de la quantité d'article de livraison, 25 la date PGI pour la quantité d'article de livraison, la quantité GR totalisée, et la date GR changée dans le réseau GR Date 4 ; pour chaque envoi, détermination d'une ATA date comme l'heure réelle de l'arrivée de la cargaison ; déterminer que la condition GRDATE1 suivante n'est pas vraie pour au moins l'un des 30 articles de livraison : (date GR de GR Date 1 > ATA Date et date GR de GR Date 1 > PGI Date) ;déterminer que la condition GRDA1E2 suivante est vraie pour au moins l'une des livraisons (date GR de GR Date 2 > ATA Date et date GR de GR Date 2 > PGI Date) ; et la définition de la date GR pour chacune des livraisons pour laquelle la condition GRDA1E2 est vraie pour la date GR respective dans le réseau GR Date 2.
  5. 5. Procédé comprenant : l'identification de multiples livraisons liées à un article de la ligne du bon de commande (POLI), dans laquelle chacune des livraisons multiples a une quantité de livraison et une date de sortie de marchandise (PGI), chaque date PGI étant la date à laquelle les marchandises pour la livraison respective ont été physiquement déplacées d'un entrepôt vers une usine, les dates PGI ayant un ordre ; l'identification de multiples envois chacun lié à une livraison, où chacun des multiples envois a une quantité d'envoi ; l'identification de multiples événements de marchandises reçues (GR) pour les multiples livraisons liées au POLI, où chacun des multiples événements GR a une quantité GR et une date GR, et où les dates GR ont un ordre ; l'identification d'une quantité requise pour le POLI; un processeur calculant un réseau GR Date 1 en : faisant correspondre les quantités de livraison liées à un POLI aux quantités GR des multiples événements GR liés au POLI, dans lequel la correspondance est ambiguë parce qu'au moins une partie des quantités de livraison liées au POLI est égale et au moins une partie des quantités GR liées au POLI est égale, la résolution de cette ambiguïté en donnant la préférence à l'alignement de la commande des dates de PGI à la commande des dates de GR, et pour chaque livraison, l'enregistrement de la quantité de livraison, la PGI de la quantité de livraison, la quantité GR, et la GR pour chaque correspondance dans le réseau GR Date 1 ; le processeur calculant un réseau GR Date 2 en : totalisant les quantités de livraison des livraisons liées au même envoi, faisant correspondre les quantités de livraison totalisée aux quantités GR, etpour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour le réseau GR Date 2 le processeur calculant un réseau GR Date 3 en : totalisant les quantités GR d'un groupe d'événements GR de sorte que la somme corresponde à une quantité de livraison de l'une des multiples livraisons, déterminant un maximum des dates GR à partir du groupe d'événements GR et en l'enregistrant sous forme de maximum GR date 3, changeant les dates GR des événements GR dans le groupe pour 1() maximum GR date 3, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 3 ; le processeur calculant un réseau GR Date 4 en : 15 totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities ; déterminer que la summed GR quantities est égale à la quantité requise pour le POLI, déterminer un maximum des dates GR à partir des multiples événements GR et 20 l'enregistrer sous forme de maximum GR date 4, modifier les dates GR des multiples événements GR pour le maximum GR date 4, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le 25 réseau GR Date 4 ; pour chaque envoi, détermination d'une ATA date comme l'heure réelle de l'arrivée de la cargaison ; la détermination que la condition GRDATE1 suivante est fausse pour au moins l'une des livraisons : 30 (date GR de GR Date 1 > ATA Date et date GR de GR Date 1 > PGI Date) ; la détermination que la condition GRDATE2 suivante est fausse pour au moins l'une des livraisons :(date GR de GR Date 2 > ATA Date et date GR de GR Date 2 > PGI Date) ; la détermination que la condition GRDATE3 suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 3 > ATA Date et date GR de GR Date 3 > PGI Date) ; et définir une date GR pour chacune de l'au moins une livraison pour laquelle la condition GRDATE3 est vraie pour la date GR respective pour la livraison dans le réseau GR Date 3.
  6. 6. Procédé comprenant : l'identification de multiples livraisons liées à un article de la ligne du bon de commande (POLI), dans laquelle chacune des livraisons multiples a une quantité de livraison et une date de sortie de marchandise (PGI), chaque date PGI étant la date à laquelle les marchandises pour la livraison respective ont été physiquement déplacées d'un entrepôt vers une usine, les dates PGI ayant un ordre ; l'identification de multiples envois chacun lié à une livraison, où chacun des multiples envois a une quantité d'envoi ; l'identification de multiples événements de marchandises reçues (GR) pour les multiples livraisons liées au POLI, où chacun des multiples événements GR a une quantité GR et une date GR, et où les dates GR ont un ordre ; l'identification d'une quantité requise pour le POLI; un processeur calculant un réseau GR Date 1 en : faisant correspondre les quantités de livraison liées à un POLI aux quantités GR des multiples événements GR liés au POLI, dans lequel la correspondance est ambiguë parce qu'au moins une partie des quantités de livraison liées au POLI est égale et au moins une partie des quantités GR liées au POLI est égale, la résolution de cette ambiguïté en donnant la préférence à l'alignement de l'ordre des dates de PGI à l'ordre des dates de GR, et pour chaque livraison, l'enregistrement de la quantité de livraison, la PGI de la quantité de livraison, la quantité GR, et la GR pour chaque correspondance dans le réseau GR Date 1 ; le processeur calculant un réseau GR Date 2 en :totalisant les quantités de livraison des livraisons liées au même envoi, faisant correspondre les quantités de livraison totalisée aux quantités GR, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR et la date GR pour le réseau GR Date 2 le processeur calculant un réseau GR Date 3 en : totalisant les quantités GR d'un groupe d'événements GR de sorte que la somme corresponde à une quantité de livraison de l'une des multiples livraisons, déterminant un maximum des dates GR à partir du groupe d'événements GR et en 1() l'enregistrant sous forme de maximum GR date 3, changeant les dates GR des événements GR dans le groupe pour maximum GR date 3, et pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le 15 réseau GR Date 3 ; le processeur calculant un réseau GR Date 4 en : totalisant les quantités GR des multiples événements GR pour générer une summed GR quantities ; déterminer que la summed GR quantities est égale à la quantité requise pour le 20 POLI, déterminer un maximum des dates GR à partir des multiples événements GR et l'enregistrer sous forme de maximum GR date 4, modifier les dates GR des multiples événements GR pour le maximum GR date 4, et 25 pour chaque livraison, l'enregistrement de la quantité de livraison, la date PGI pour la quantité de livraison, la quantité GR totalisée et la date GR changée dans le réseau GR Date 4 ; pour chaque envoi, détermination d'une ATA date comme l'heure réelle de l'arrivée de la cargaison ; 30 la détermination que la condition GRDAIEI suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date I > ATA Date et date GR de GR Date I > PGI Date) ;la détermination que la condition GRDATE2 suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 2 > ATA Date et date GR de GR Date 2 > PGI Date) ; la détermination que la condition GRDAIE3 suivante est fausse pour au moins l'une des livraisons : (date GR de GR Date 3 > ATA Date et date GR de GR Date 3 > PGI Date) ; la détermination que la condition GRDATE4 suivante est vraie pour au moins l'une des livraisons : (date GR de GR Date 4 > ATA Date et date GR de GR Date 4 > PGI Date) ; et la définition de la date GR pour chacune de l'au moins une livraison pour laquelle la condition GRDATE4 est vraie pour la date GR respective pour la livraison dans le réseau GR Date 4.
  7. 7. Procédé comprenant : un processeur recevant et stockant des données logistiques concernant un article de la ligne de bon de commande (POLI), les données logistiques comprenant : une pluralité d'envois, chaque envoi comprenant des livraisons liées à un article de la ligne du bon de commande (POLI), dans laquelle chaque livraison comporte : une quantité de la livraison, et une date de sortie de marchandises (PGI) ; une pluralité de services logistiques pour la pluralité des envois comprenant des livraisons liées au POLI, l'un de la pluralité des envois, un envoi multi-mode, ayant une pluralité de services logistiques séquentiels ; une pluralité de livraisons liées au POLI, dans laquelle les éléments suivants sont déterminés pour chacune des livraisons : une quantité de marchandises reçues (GR), et une date GR; le processeur permettant un affichage de la date PGI et de la date GR pour l'envoi multimode ayant une pluralité de modes de transport.
  8. 8. Procédé selon la revendication 7, dans lequel le processeur recevant et stockant des données logistiques concernant le POLI comprend la réception des données provenant des fournisseurs de données logistiques choisis dans le groupe composé de transitaires et des courtiers des douanes.
  9. 9. Procédé selon la revendication 7 ou 8, dans lequel la pluralité des services logistiques séquentiels comprend: un premier mode de transport opéré par un premier fournisseur, le premier fournisseur transportant l'envoi multi-mode d'un premier endroit vers un deuxième endroit ; et un deuxième mode de transport opéré par un deuxième fournisseur différent du premier fournisseur, le deuxième fournisseur transportant l'envoi multi-mode d'un deuxième endroit vers un troisième endroit ; et
  10. 10. Procédé selon l'une quelconque des revendications 7 à 9, dans lequel la détermination de la date GR pour chacun des livraisons comprend : le processeur calculant les dates GR pour les livraisons liées à l'envoi multi-mode basé sur la pluralité des livraisons liée au POLI.
  11. 11. Procédé selon l'une quelconque des revendications 7 à 10, dans lequel la pluralité des services logistiques séquentiels comprennent : un service fourni par une compagnie de transitaire ; un service fourni par une compagnie de courrier ; et un service fourni par un courtier des douanes logistique.
  12. 12. Procédé selon l'une quelconque des revendications 7 à 11, dans lequel la pluralité des services logistiques séquentiels est choisie dans un groupe composé d'un service fourni par une compagnie de manutention de fret, un service fourni par une compagnie de courrier et un service fourni par un courtier des douanes logistique.
FR1560076A 2014-10-22 2015-10-22 Gestion d'une chaine d'approvisionnement Withdrawn FR3027708A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2014/061687 WO2016064381A1 (fr) 2014-10-22 2014-10-22 Gestion de chaîne logistique

Publications (1)

Publication Number Publication Date
FR3027708A1 true FR3027708A1 (fr) 2016-04-29

Family

ID=55697865

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1560076A Withdrawn FR3027708A1 (fr) 2014-10-22 2015-10-22 Gestion d'une chaine d'approvisionnement

Country Status (6)

Country Link
US (1) US10515332B2 (fr)
AR (1) AR101988A1 (fr)
CA (1) CA2961554A1 (fr)
FR (1) FR3027708A1 (fr)
GB (1) GB2546021A (fr)
WO (1) WO2016064381A1 (fr)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107924423B (zh) * 2015-12-18 2022-03-25 株式会社日立制作所 模型确定设备和模型确定方法
US20180075547A1 (en) * 2016-09-13 2018-03-15 Proppant Express Solutions, Llc Proppant tracking system
CN108764790A (zh) * 2018-05-21 2018-11-06 湖北迪天信息科技有限公司 一种汽车供应链协同管理平台
EP3864589A1 (fr) * 2018-10-10 2021-08-18 Bayer Aktiengesellschaft Appareil de planification de produit
US11593750B2 (en) * 2018-12-20 2023-02-28 KlearNow Corporation Managing and tracking shipments
CN113570098A (zh) * 2020-04-28 2021-10-29 鸿富锦精密电子(天津)有限公司 出货量预测方法、装置、计算机装置及存储介质
US20220198382A1 (en) * 2020-12-18 2022-06-23 Target Brands, Inc. Load tracking with supply chain management system and platform
US11687880B2 (en) 2020-12-29 2023-06-27 Target Brands, Inc. Aggregated supply chain management interfaces
US11824322B2 (en) 2021-02-16 2023-11-21 Ii-Vi Delaware, Inc. Laser device with non-absorbing mirror, and method
US11640580B2 (en) 2021-03-11 2023-05-02 Target Brands, Inc. Inventory ready date trailer prioritization system
CN113469630B (zh) * 2021-09-02 2021-11-30 北京每日优鲜电子商务有限公司 基于配送信息的货架摆放方法、装置、电子设备和介质
US11803805B2 (en) 2021-09-23 2023-10-31 Target Brands, Inc. Supply chain management system and platform

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001338165A (ja) 2000-05-29 2001-12-07 Nec Corp 通信ネットワークを利用した購入システム及び購入方法
US20050177435A1 (en) * 2001-11-28 2005-08-11 Derek Lidow Supply chain network
US20050119926A1 (en) * 2003-12-01 2005-06-02 Leon Turetsky Method and system for managing multi-national integrated trade and logistics and processes for efficient, timely, and compliant movement of goods across international borders
US8050956B2 (en) * 2004-03-08 2011-11-01 Sap Ag Computer-readable medium, program product, and system for providing a schedule bar with event dates to monitor procurement of a product
US20090138327A1 (en) 2005-02-01 2009-05-28 Toshiyuki Sakuma Delivery date answering program, delivery date answering method, and system for implementing the method
US7624024B2 (en) * 2005-04-18 2009-11-24 United Parcel Service Of America, Inc. Systems and methods for dynamically updating a dispatch plan

Also Published As

Publication number Publication date
CA2961554A1 (fr) 2016-04-28
US20170300851A1 (en) 2017-10-19
US10515332B2 (en) 2019-12-24
GB201704162D0 (en) 2017-05-03
AR101988A1 (es) 2017-01-25
WO2016064381A1 (fr) 2016-04-28
GB2546021A (en) 2017-07-05

Similar Documents

Publication Publication Date Title
FR3027708A1 (fr) Gestion d&#39;une chaine d&#39;approvisionnement
US8438119B2 (en) Foundation layer for services based enterprise software architecture
US20020095355A1 (en) Computer-implemented international trade system
US20160071055A1 (en) Freight services marketplace system and methods
McLaughlin et al. Using information technology to improve downstream supply chain operations: a case study
Vrijhoef Extended roles of construction supply chain management for improved logistics and environmental performance
Taylor An application of value stream management to the improvement of a global supply chain: a case study in the footwear industry
Bansal Technology scorecards: Aligning IT investments with business performance
Becker et al. Model-based potential analysis of the distribution logistics: a case study
Chudy et al. Sales and distribution in SAP ERP: Practical guide
Alt et al. Logistics Web Services for Collaborative Order Management
Loan et al. Last–Mile Delivery in B2C E-Commerce–Common Practices in Some Countries, But What Do They Mean for Businesses in Vietnam?
Schmitz The use of supply chains and supply chain management to improve the efficiency and effectiveness of GIS units
Payne et al. Electronic Data Interchange (EDI): Using Electronic Commerce to Enhance Defense Logistics
Vegas Blockchain: applications, effects and challenges in supply chains
Zinaida et al. Blockchain technologies in the conditions of digitalization of international business
Nguyen et al. Current status and solutions to develop e-logistics in Vietnam
US20240095658A1 (en) Integrated logistics ecosystem
Smith Closing the gap between information and payment flows in a digital transformation
US20220129477A1 (en) Systems and methods for managing event storage
Venosta et al. Reverse logistics in B2C e-commerce: a model to assess return costs
Kamranpour et al. Omnichannel Supply Chain Transformation for Third Party Logistics Providers
Mitra Effectiveness of C-express Ltd. delivery system and customer satisfaction
Ribeiro Logistics Network Optimization
Pinto Business Process Analysis in a Courier, Express and Parcel Logistics Provider

Legal Events

Date Code Title Description
TP Transmission of property

Owner name: HALLIBURTON ENERGY SERVICES, INC., US

Effective date: 20160708

PLFP Fee payment

Year of fee payment: 2

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

TP Transmission of property

Owner name: LANDMARK GRAPHICS CORPORATION, US

Effective date: 20191113

ST Notification of lapse

Effective date: 20210605