专利名称：零部件供应管理系统的数据处理方法
技术领域：
本发明涉及零部件供应管理系统的数据处理方法，用于通过密切联系零部件采购方(用户)和零部件生产方(供应商)在所要求的时限内供应所需量的零部件而不会短缺。本发明尤其涉及零部件供应管理系统的显示方法，或用于零部件供应管理系统的显示方法或仿真方法。
为此，供应商接收用户的零部件使用预报信息(“预报”)，根据预报提前生产用户所需的零部件，并在邻近用户的库存点储备这些零部件。因此，供应商准备好满足用户的要求，以便在预定的交货时间内交付预定量的预定种类的零部件然而，对于通用零部件，预报出货量往往偏多，而对于非通用零部件，预报出货量往往偏少。因此，用户不总是向供应商发出符合预报量的定单，实际上，往往出现这样的情况，即预报量与实际定购量之间有很大的出入。
在预报量超过实际定购量的情况下，供应商被迫库存过量的零部件。相反，如果实际定购量超过预报量，那么将出现供应商不能供应用户所要求的零部件的问题。
此外，库存点储备的零部件量未必是单次交付的量。然而，如果突然要求定购过量的零部件，那么可能获得定单所需的量，但是，这会打乱所计划的零部件的顺利交货，从而造成下次供应时和下下次供应时所要供应的零部件的短缺。出现这种情况时，不清楚是什么造成了所需零部件的短缺供应是超过预报量的用户的定单问题，还是供应商没有将预报量的零部件运送到库存点的问题。此时，无论在哪种情况下，总是由供应商(较弱的一方)来承担损失问题。
本发明的一个目的在于，提供了零部件供应管理系统的一种数据处理方法，该方法通过解决其中的固有问题可以补充完善上述常规系统，并且该方法可以根据情况的要求，通过使得在用户与供应商之间密切地交换信息来对待用户的要求。
本发明的另一个目的在于，提供了零部件供应管理系统的一种利用网络的数据处理方法。
本发明的还有一个目的在于，提供了零部件供应管理系统的一种显示方法，该方法可以明确用户和供应商所应承担的责任。
本发明的一个目的在于，提供了零部件供应管理系统的一种仿真方法，该方法可以确定用户和供应商采取的最佳路径。
此外，供应方服务器最好展现含有生产安排信息、储备预报信息和补充信息的显示屏，并将该显示屏发送给用户方服务器。
再者，最好根据零部件使用预报信息，在等于或大于将零部件从供应商供应给用户的所需时间的第一时间段内，确定生产安排信息。
再者，最好根据零部件使用预报信息和储备预报信息，在小于第一时间段的第二时间段内，确定补充信息。
此外，如果储备预报信息中所指示的量达不到定单信息中所指示的量，那么供应方服务器最好将定单信息与储备预报信息进行比较，并在显示屏上发出一个警报。
再者，供应方服务器最好得到与供应商根据零部件使用预报信息答应交付给用户的零部件量相应的交付约定量信息和与供应商答应为用户储备的零部件量相应的储备约定量信息，并在显示屏上显示这些信息。
再者，供应方服务器最好根据交付约定量信息和定单信息得到表示用户方定单情况的过多使用量信息，并在显示屏上显示这一信息。
此外，供应方服务器最好根据生产安排信息和补充信息得到表示供应方零部件供应情况的信息，并在显示屏上显示这一信息。
再者，供应方服务器最好通过网络接收发自用户方服务器的紧急运送信息，并根据该紧急运送信息修改储备预报信息。
再者，紧急运送信息最好包括关于运送办法的信息。
此外，供应方服务器最好通过网络将生产安排信息、储备预报信息和补充信息发送给用户方服务器，以形成一个显示屏。
再者，供应方服务器最好得到与供应商根据零部件使用预报信息答应交付给用户的零部件量相应的交付约定量信息和与供应商答应为用户储备的零部件量相应的储备约定量信息，并通过网络将该信息发送给用户方服务器。
再者，供应方服务器最好根据生产安排信息和补充信息得到表示供应方零部件供应情况的信息，并通过网络将该信息发送给用户方服务器。
在根据本发明的零部件供应管理系统的显示方法中，由于根据“预报”数据得到“生产安排量”数据和“出货约定储备量”数据，和根据“出货约定储备量”数据得到“补充量”数据，因此，可以及时处理用户所要求的零部件定单预报量中的变化。
此外，在根据本发明的零部件供应管理系统的显示方法中，由于在大于将零部件从供应商供应给用户所需的时间的第一时间段内实现零部件的生产安排(得到“生产安排量”数据)，并且由于在小于第一时间段的第二时间段内实现补充(得到“补充量”数据)，因此，可以及时处理用户所要求的零部件定单预报量中的变化。注意，将零部件从供应商供应给用户所需的时间被称为是与“生产时间段”数据+“所要求的时间段”数据相应的时间段。此外，第一时间段与“确定时间段”数据相应，而第二时间段与“所要求的时间段”数据相应。
再者，在根据本发明的零部件供应管理系统的显示方法中，由于根据均由用户所提供的“预报”数据和“固定定单”数据来实现交货预报，因此，如果作出不能按用户的要求完成交货的预报，则显示一个警报。
再者，在根据本发明的零部件供应管理系统的显示方法中，由于得到了“过多使用量累积”数据和“短缺量累积”数据，因此，可以明确哪一方应对恶化的零部件交付情况负责是用户还是供应商。
图2是说明根据本发明的零部件供应管理系统的数据处理方法的总处理流程的流程图。
图3是说明“预报”数据的一例数据结构的图解。
图4是说明“固定定单”数据的一例数据结构的图解。
图5是说明“紧急运送信息”数据的一例数据结构的图解。
图6是用于得到“出货约定量”数据、“出货约定储备量”数据、“生产安排量”数据和“计划仓储的生产安排量”数据的流程图。
图7是用于得到“出货准备的储备量”数据、“补充量”数据和“计划仓储的补充量”数据的流程图。
图8是用于得到“过多使用量累积”数据和“交货目标”数据的流程图。
图9是用于得到“短缺量累积”数据的流程图。
图10是用于得到“计划仓储的紧急运送量”数据的流程图。
图11是说明用于根据本发明的零部件供应管理系统的数据处理方法的一例交付情况显示屏的图解。
图12是说明用于根据本发明的零部件供应管理系统的数据处理方法的另一例交付情况显示屏的图解。
图13是说明用于根据本发明的零部件供应管理系统的数据处理方法的一例交付情况显示屏的图解。
图14是说明用于根据本发明的零部件供应管理系统的数据处理方法的另一例交付情况显示屏的图解。
图15是说明用于根据本发明的零部件供应管理系统的数据处理方法的一例交付情况显示屏的图解。
图16是说明用于根据本发明的零部件供应管理系统的数据处理方法的另一例交付情况显示屏的图解。
图17是说明用于根据本发明的零部件供应管理系统的数据处理方法的一例交付情况显示屏的图解。
图18是说明用于根据本发明的零部件供应管理系统的数据处理方法的另一例交付情况显示屏的图解。
供应方服务器10包括一个显示单元11；一个处理器单元12，用于发送和接收各种数据并执行各种过程；一个主存储单元13，用于存储各种数据等；和一个输入单元14，用于输入各种数据和执行各种操作的输入。另外，用户方服务器20包括一个显示单元21；一个处理器单元22，用于发送和接收各种数据并执行各种处理；一个主存储单元23，用于存储各种数据等；和一个输入单元24，用于输入各种数据和执行各种操作的输入。
首先，供应商生产诸如电子元件等零部件。然后，供应商将所生产的零部件运送到邻近用户所在地的库存点(仓库等)暂时存放。因此，供应商根据从用户接收到的定单准备及时交付零部件。注意，服务器可以布置在库存点。这样，就可以通过网络1将各种数据从这一库存点方服务器发送到供应方服务器10。
图2是说明根据本发明的零部件供应管理系统的数据处理系统中的总处理流程的流程图。下面将参照图2来描述该系统的总处理流程。图2中所示的总处理流程主要由处理器单元12根据事先存储在供应方服务器10中的主存储单元13中的主程序来执行，而在用户方服务器20中，总处理流程主要由处理器单元22根据事先存储在主存储单元23中的主程序来执行。
首先，用户利用输入单元24输入“预报”数据、“固定定单”数据或“紧急运送信息”数据。然后，通过网络1将“预报”数据、“固定定单”数据或“紧急运送信息”数据发送到供应方服务器(步骤201)。各种数据的细节将在后面描述。
接着，供应方服务器10接收“预报”数据、“固定定单”数据或“紧急运送信息”数据(步骤202)。
然后，将所接收到的“预报”数据、“固定定单”数据和“紧急运送信息”数据存入存储装置13(步骤203)。
随后，供应方服务器10根据存储在主存储装置13中的参数和所存储的各种数据，计算出“出货约定储备量”数据、“出货准备的储备量”数据、“过多使用量累积”数据、“短缺量累积”数据、“出货约定量”数据、“生产安排量”数据、“计划仓储的生产安排量”数据、“补充量”数据、“计划仓储的补充量”数据和“计划仓储的紧急运送量”数据(步骤204)。这些参数和计算方法将在后面描述。
接着，再将所计算出的各种数据存入到主存储装置13中(步骤205)。
随后，将基于“固定定单”数据的“交货目标”数据发送到库存点(步骤206)。然后，根据这一“交货目标”数据将储备在库存点的零部件交付给用户。
接着，根据各种所接收到的数据以及通过计算所得到的各种数据，形成交付情况显示屏(步骤207)。交付情况显示屏的细节将在后面描述。
随后，通过网络1将所形成的交付情况显示屏发送到用户方服务器20(步骤208)。
接着，用户方服务器20接收交付情况显示屏(步骤209)并在显示单元21上显示出交付情况显示屏。用户可以通过交付情况显示屏证实零部件交付预报。此外，在证实所接收到的交付情况显示屏的同时，用户还可以为以后的定单发送“预报”数据、“固定定单”数据和“紧急运送信息”数据。于是，重复类似的步骤。
注意，在图2中所示的流程中，当交付情况显示屏从供应方服务器10发送到用户方服务器20时，供应方服务器10只发送预定数据，而用户方服务器20一旦接收到预定数据，就可以根据事先存储在用户方服务器20中的软件产生交付情况显示屏。
图3是说明“预报”数据的一例数据结构的图解。下面，将利用图3来描述“预报”数据。如图所示，“预报”数据由预报发布日期数据301、预定交付数据302和预报数据303构成。这里，图中所示的数据结构表示，用户在1999年第36周预报了如下定单第42周100个、第43周100个、第44周100个、第45周60个、第46周50个、第47周50个、第48周50个和第49周50个。
尽管图3描述了1999年第42周至第49周这8周的数据，然而，所描述的数据并不局限于8周的数据，而可以传达任何时段的数据。此外，在图3中，尽管交付期数据被描述成以周为单位的数据，然而，也可以根据情况，将以天为单位、以周为单位或以任何其他时长为单位作为时间段基准。再者，图3中，尽管“预报”数据用个数表示，然而，它也可以用件数来表示。
图4是说明“固定定单”数据的一例数据结构的图解。下面，将利用图4来描述“固定定单”数据。如图所示，“固定定单”数据由固定定单发布日期数据401、预定交付数据402和定单数据403构成。这里，数据这样构成，用户在1999年第42周发出了如下正式的零部件固定定单第43周150个和第44周180个。
尽管图4描述了1999年第43周和第44周这2周的数据，然而，所描述的数据并不局限于2周的数据，而可以附上任何时段的数据。此外，在图4中，尽管交付期数据被描述成以周为单位的数据，然而，也可以根据情况，将以天为单位、以月为单位或以任何其他时长为单位作为时间段基准。再者，图4中，尽管“固定定单”数据用个数表示，然而，它也可以用件数来表示。
图5是说明“紧急运送信息”数据的一例数据结构的图解。下面，将利用图5来描述“紧急运送信息”数据。如图所示，“紧急运送信息”数据由紧急运送信息发布日期数据501、预定交付数据502、运送数据503和运送办法数据504构成。这里，数据这样构成，请求空运10个到库存点，以便在1999年第43周被仓储。
尽管图5描述了1999年第43周这1周的数据，然而，所描述的数据并不局限于1周的数据，而可以附上任何时段的数据。此外，在图5中，尽管交付期数据被描述成以周为单位的数据，然而，也可以根据情况，将以天为单位、以月为单位或以任何其他时长为单位作为时间段基准。再者，图5中，尽管“运送”数据用个数表示，然而，它也可以用件数来表示。再者，也可以采用其他运送手段如船只和货车作为其他运送办法。
下面，将描述各种参数。各种参数包括有“确定时间段”数据、“储备时间段”数据、“生产时间段”数据、“所要求的时间段”数据和“交付时间段”数据。此外，各种参数都事先存入主存储单元12中。
“确定时间段”是一个用于确定这样的时限的参数，在该时限内，确定“生产安排量”等(这将在后面描述)。“储备时间段”数据是一个用于确定“出货约定储备量”的参数。“生产时间段”数据是一个关于生产目标零部件所要求的时间段的参数。“所要求的时间段”数据是这样一个参数，它涉及将零部件从供应商运送到库存点所要求的时间段并用于确定这样的时限，在该时限内，确定“补充量”等。“交付时间段”数据是一个关于将零部件从库存点交付给用户所要求的时段段的参数。
在下文中所要进行的描述中，“确定时间段”数据事先被置为6周，“储备时间段”数据事先被置为4周，“生产时间段”数据事先被置2周，“所要求的时间段”数据事先被置为3周，而“交付时间段”数据事先被置为0周。注意，由于“确定时间段”数据是一个用于确定这样的时限的数据，即在该时限内，确定零部件的生产安排，因此，希望该数据等于或大于“生产时间段”数据+“所要求的时间段”数据。此外，这些参数是一些可以根据情况自由地被设置的参数，因此，它们并不局限于以上所指定的值。
下面，将描述通过计算所得到的各种数据。
“出货约定量”数据是一个表示供应商已答应在与“确定时间段”数据相应的周内发运给用户的零部件量的数据。例如，假定，现在是1999年第36周而“确定时间段”为6周，那么，1999年第42周将揭示零部件的出货约定量。
“出货约定储备量”数据是一个表示供应商已与用户商定在与“确定时间段”数据相应的周初某一时刻仓储在库存点的零部件量的数据。此外，所要仓储在库存点的零部件量是指针对与“储备时间段”数据相应的时间段(这里为4周)的一个量。
“生产安排量”数据是一个表示指定要由供应商来生产的零部件量的数据。
“计划仓储的生产安排量”数据是一个表示何时将指定要生产的零部件仓储在库存点的数据，并且该数据可根据“生产时间段”数据和“所要求的时间”数据得到。
“出货准备的储备量”数据是这样一个数据，它表示实际上要在有关的周初某一时刻储备在库存点的零部件量，或作为仿真结果希望要在有关的周初某一时刻储备在库存点的零部件量。注意，在后一种情况下，零部件量被放在括号中描述。
“补充量”数据是一个表示指定要补充生产的零部件量的数据。
“计划仓储的补充量”数据是一个表示何时将指定要补充生产的零部件仓储在库存点的数据，并且该数据可根据“生产时间段”数据和/或“所要求的时间段”数据得到。
“过多使用量累积”数据是一个表示从用户接收到的“固定定单”数据的累积的数据，它超过了表示供应商已与用户商定发运给用户的零部件量的“出货约定量”数据。
“短缺量累积”数据是一个表示供应不足的零部件量的累积的数据，如果零部件没有象“生产安排量”数据和“补充量”数据所表示的那样仓储在库存点的话。
“计划仓储的紧急运送量”数据是一个表示何时将要紧急运送的零部件储备在库存点的数据，并且该数据可根据“所要求的时间段”数据得到。
下面，将参照图6至10，描述通过计算得到各种数据的方法。图6至10中所示的各个过程主要由处理器单元12根据存储在主存储单元13中的各个程序来执行。
图6是用于得到“出货约定量”数据、“出货约定储备量”数据、“生产安排量”数据和“计划仓储的生产安排量”数据的流程图。
首先，被读出的“确定时间段”数据(这里为6周)和“储备时间段”数据(这里为4周)事先都存储在主存储单元13中(步骤601)。
接着，判断是否存在最新的与“确定时间段”数据相应的“预报”数据(步骤602)。如果没有相应的数据，则这一流程结束。如果有相应的数据，则实际上将最新的相应的“预报”数据作为“出货约定量”数据(步骤603)。注意，这可以这样来改变，即根据到目前为止已有的“预报”数据和“固定定单”数据的趋势来确定“出货约定量”。
然后，根据“储备时间段”数据得到“出货约定储备量”数据(步骤604)。在与“确定时间段”相应的周为第42周而“储备时间段”数据为4周的情况下，将第42周至第45周这4周的“预报”数据相加，便得到“出货约定储备量”数据。
然后，根据“预报”数据和“确定时间段”数据得到“计划的生产安排量”数据(步骤605)。注意，“计划的生产安排量”数据是一个用来便于得到“生产安排量”数据的数据。具体地说，可从下列表达式得到“计划的生产安排量”数据。在该表达式中，“n”表示系统自从启动以来过去了几周，而“a”表示系统启动时的那周。
第[a+(n-1)]周的“计划的生产安排量”数据＝ (第k周的“出货约定量”数据)+第[a+(n-1)]周时作出的第[a+(n-1)+7]周的“预报”数据+第[a+(n-1)]周时作出的第[a+(n-1)+8]周的“预报”数据+第[a+(n-1)]周时作出的第[a+(n-1)+9]周的“预报”数据 (第k周的“生产安排量”数据)。
其中，如果第[a+(n-1)]周的“计划的生产安排量”数据的值变成负数，则令它为0。此外，当n＝1时， (第k周的“生产安排量”数据)＝0。
然后，判断自从系统启动以后的当前时刻是否落在“确定时间段”数据内(步骤606)。这里是，判断自从供应方服务器10最初开始从用户方服务器20接收到“预报”数据等以后的当前时刻是否落在6周内。
如果当前时刻落在“确定时间段”数据内，则流程进至步骤607。在步骤607中，实际上将“计划的生产安排量”数据作为“生产安排量”数据。此外，还将与“生产时间段”数据+“所要求的时间段”数据相应的周的“计划仓储的生产安排量”数据作为“生产安排量”数据。例如，假定“生产时间段”数据为2周而“所要求的时间段”数据为3周，那么表示应在5周内仓储与“生产安排量”数据相应的一定量的零部件。换言之，考虑到作出零部件的生产安排、然后进行零部件的生产、直到将所生产的零部件运送到库存点后所需的时间，来确定所估计的仓储零部件的时限。
此外，在步骤606中，如果判定当前时刻没有落在“确定时间段”数据内，则流程进至步骤608。在步骤608中，从主存储单元13中读出“出货约定储备量”数据和“过多使用量累积”数据。然后，根据均是在步骤605中得到的“计划的生产安排量”数据和“过多使用量累积量”数据，得到“生产安排量”数据。具体地说，如果“过多使用量累积”数据为负数，那么，“生产安排量”数据＝“计划的生产安排量”数据+“过多使用量累积”数据。而如果“过多使用量累积”数据为0或正数，那么，“生产安排量”数据＝“计划的生产安排量”数据。再者，在步骤608中，还可以利用步骤607中所用的同样的过程得到“计划仓储的生产安排量”数据(步骤609)，然后，图6中的流程结束。
图7是用于得到“出货准备的储备量”数据、“补充量”数据和“计划仓储的补充量”数据的流程图。
首先，从主存储单元13中读出“确定时间段”数据和“所要求的时间段”数据(步骤701)。类似地，从主存储单元13中读出“计划仓储的生产安排量”数据、“计划仓储的补充量”数据、“计划仓储的紧急运送量”数据和“出货约定储备量”数据(步骤702)。
接着，判断是否存在与“确定时间段”数据相应的“预报”数据或“固定定单”数据(步骤703)。例如，假定当前时刻是1999年第36周而“确定时间段”数据为6周，那么判断是否存在第42周的“预报”数据或“固定定单”数据。如果没有相应的数据，则这一流程结束。
如果有相应的数据，那么接着可以根据“预报”数据或“固定定单”数据以及“计划仓储的生产安排量”数据、“计划仓储的补充量”数据、“计划仓储的紧急运送量”数据和“出货约定储备量”数据得到“出货准备的储备量”数据。即，将第(X-1)周的“出货准备的储备”数据减去第X周的“预报”数据或第X周的“固定定单”数据(无论哪个更大)，再将第(X-1)周的“计划仓储的生产安排量”数据、第(X-1)周的“计划仓储的补充量”数据和“计划仓储的紧急运送量”数据与相减所得到的结果相加，得到第X周的“出货准备的储备量”数据。换言之，将库存点现有的储备量减去本周从库存点发运的零部件量或本周内将要从库存点发运的零部件量，再将本周已仓储的零部件量或本周内将要仓储的零部件量与相减所得到的量相加，估算出库存点的储备量。“出货准备的储备量”可以每周都被模拟。此外，例如，假定当前时刻是第40周而“所要求的时间段”为3周，那么，“出货准备的储备量”可以只在第41至第43周这3周被模拟。
然后，判断与“所要求的时间段”数据相应的周的“出货约定储备量”-“出货准备的储备量”是否为负数(步骤705)。例如，假定当前时刻是第40周而“所要求的时间段”为3周，那么，应考虑到第43周的“出货约定储备量”-“出货准备的储备量”。即，将供应商已答应在库存点仓储的零部件量与此后根据“预报”中的变化所模拟的储备预报进行比较，判断该时刻库存点的零部件量是否短缺。
首先，供应方服务器10根据作为来自用户的零部件使用预报信息的“预报”数据，得到与生产和运送的目标相应的“生产安排量”。然后，根据作为通过此后所进行的模拟所得到的储备预报信息的“出货准备的储备量”数据，得到与零部件的生产和/或运送的目标相应的“补充量”数据，据此，可以尝试调整准备仓储到库存点的零部件量。
如果满足步骤705中所述的条件，那么将与“出货准备的储备量”-“出货约定储备量”所得到的不足量相应的零部件量作为“补充量”数据(步骤706)。即，指定零部件的生产和/或运送，以便又为库存点提供与“补充量”数据相应的零部件量。
然后，根据“所要求的时间段”数据和/或“生产时间段”数据得到“计划仓储的补充量”数据(步骤707)，于是，图7中所示的流程结束。补充时，可想而知，当与“所要求的时间段”数据相应的时间过后，已生产出的零部件被仓储在库存点，然而，可想而知，当与“计划仓储的补充量”数据+“所要求的时间段”数据相应的时间过后，必须生产出的零部件被仓储在库存点。此后，认为“计划仓储的补充量”数据需要与“生产时间段”数据+“所要求的时间段”数据相应的时间，但该数据也可以随情形要求变更。
图8是用于得到“过多使用量累积”数据和“交货目标”数据的流程图。注意，只有当接收到相应的周的“固定定单”数据时，才能激活图8中所示的过程。
首先，从主存储单元13中读出相应的周的“固定定单”数据和“出货准备的储备量”数据(步骤801)。
接着，判断是否(“出货准备的储备量”数据-“固定定单”数据＞0)(步骤802)。
如果满足步骤802中的条件，那么流程进至步骤803，在此，实际上将“固定定单”数据作为“交货目标”数据。根据“交货目标”数据，实际上将指定量的零部件从库存点交付给用户。注意，利用其他参考，也可以采用实际上不将“固定定单”数据作为“交货目标”数据的方法。例如，用户可以单独地根据“固定定单”数据来说明与通过详细说明“固定定单”数据所得到的数据相似的“交货目标”数据。
然后，计算出每周的(“交货目标”数据-“出货约定量”数据)，并将计算结果的累积作为“过多使用量累积”(步骤804)。如果“过多使用量累积”数据为正数，则表示用户发出了超过供应商答应的“出货约定量”数据的固定定单。反之，如果“过多使用量累积”数据为负数，则表示用户发出了小于供应商答应的“出货约定量”数据的固定定单。
此外，如果不满足步骤802中的条件，那么流程进至步骤805，在此，显示一个警报(步骤805)。在显示警报的情况下，所显示的警报表示还没有在库存点准备好出货的与用户所发出的固定定单相应的零部件量。
图9是用于得到“短缺量累积”数据的流程图。
首先，从主存储单元13中读出“计划仓储的生产安排量”数据、“仓储的生产安排量累积”数据、“计划仓储的补充量”数据和“仓储的补充量累积”数据(步骤901)。这里，“仓储的生产安排量累积”数据表示已仓储在库存点的零部件量。例如，在1999年第41周的“计划仓储的生产安排量”数据为360个的情况下，如果360个零部件实际上在第42周仓储在库存点，那么“仓储的生产安排量累积”为360个。
接着，分别计算出每周的(“计划仓储的生产安排量”-“仓储的生产安排量累积”)+(“计划仓储的补充量”-“仓储的补充量累积”)，并将计算结果的累积值作为“短缺量累积”数据(步骤902)。也就是说，如果“短缺量累积”数据为正数，则表示供应商没有在库存点储备其量与“生产安排量”数据和“补充量”数据相应的零部件量。
本系统中，“仓储的生产安排量累积”数据和“仓储的补充量累积”数据是由掌握库存点方的实际情况的供应方的操作员从输入单元14输入的，然后将输入数据存入主存储单元13中。然而，服务器可以配置在库存点方，因此，数据可以从该服务器输入，以便被发送到供应方服务器10。此外，在本系统中，图9中所示的流程只有当“仓储的生产安排量累积”数据和“仓储的补充量累积”数据被输入时才能被激活。
图10是用于得到“计划仓储的紧急运送量”数据的流程图。
首先，从主存储单元13中读出“所要求的时间段”数据和“紧急运送信息”数据(步骤1001)。
接着，根据与“紧急运送信息”数据中所含的运送办法数据(参照图5中的504)相应的“所要求的时间段”数据，得到“计划仓储的紧急运送量”数据。“所要求的时间段”数据此前已被描述为事先被置为船运时所需的3周。然而，空运所需的“所要求的时间段”数据可以被置为1周，而一流空运所需的“所要求的时间段”数据可以被置为3天。这里，根据具体运送办法确定何时将紧急运送的零部件仓储在库存点，并得到“计划仓储的紧急运送量”数据。注意，图10中所示的流程只有当接收到“紧急运送信息”数据时才能被激活。
图10中的流程是这样进行的，当接收到“紧急运送信息”数据时，自动得到“计划仓储的紧急运送量”数据。然而，在零部件的生产安排或补充已经被指定的情况下，可以指定为赶在将零部件仓储在库存点的时限之前。也就是说，根据“紧急运送信息”数据，改变“计划仓储的生产安排量”数据或“计划仓储的补充量”数据的仓储的计划时限，以便超前。再者，根据这一变化，还将按照图7中所示的流程来改变“出货准备的储备量”数据。
图11-18是说明用于根据本发明的零部件供应管理系统的数据处理方法的交付情况显示屏的一些例子的图解。下面，将按时间序列描述根据所接收到的“预报”数据、“固定定单”数据和“紧急运送信息”所形成的这几种交付情况显示屏。
这里，在供应方服务器10与用户方服务器20之间交换数据是在1999年第36周启动的，以便从1999年第42周开始进行零部件的实际交付。也就是说，这一系统要从1999年第36周被启动。再者，这里，“确定时间段”数据事先被置为6周，“储备时间段”数据被置为4周，“生产时间段”数据被置2周，船运“所要求的时间段”数据被置为3周，空运“所要求的时间段”数据被置为1周，而“交付时间段”数据被置为0周。注意，“所要求的时间段”数据通常被置为3周(船运)。
图11表示1999年第36周的情况，如1101所示，此时已接收到1999年第42周至第49周的“预报”数据。此外，尚未接收到“固定定单”数据和“紧急运送信息”。1102表示根据该数据所形成的交付情况显示屏。
1101和1102的最上面的行分别表示1999年的周。即1101表示从1999年第42周至1999年第49周，而1102表示从1999年第34周至1999年第43周。下文中，图12至18中的情况都是这样。
在有关的周从用户接收到的最新的“预报”数据在1102中用“当前预报”行来表示。此外，已从用户接收到的“固定定单”数据和“紧急运送信息”数据在1102中用“固定定单”和“紧急运送信息”行来表示。另外，“非出货指定量”是表示尚未指定要交付给用户的固定定单的零部件的零部件量数据，而“交付指定量-出货约定量”是表示将“交付指定量数据”数据减去“出货约定量”数据所得到的值的数据。
在第36周，与“确定时间段”数据(6周后)相应的周是第42周。因此，根据图6中所示的流程，通过计算得到“出货约定量”为100个和“出货约定储备量”为360个。也就是说，第42周的“预报”数据100个实际上被作为“出货约定量”数据。此外，将第42周至第45周这4周的“预报”数据相加，于是将相加所得到数据作为第42周的“出货约定储备量”360个(100+100+100+60)。
此外，根据图6中所示的流程，通过计算得到第36周的“计划的生产安排量”为360个。也就是说，由于本系统在第36周被启动，因而，a＝36，而在第36周，n＝1。因此，第36周的“计划的生产安排量”数据＝100(第36周所确定的第42周的“出货约定量”数据)+100(第43周的“预报”数据)+100(第44周的“预报”数据)+60(第45周的“预报”数据)-0(因为n＝1)＝360个。
再者，根据图6中所示的流程，通过计算可以得到第41周的“计划仓储的生产安排量”为360个。也就是说，表示第36周安排生产的零部件此后被生产和运送，并将在第41周仓储在库存点，在第41周之前有5周(＝“生产时间段”数据+“所要求的时间段”数据)。
此外，在第36周时，由于图7至10中所示的流程的激活条件不满足，因此，无法通过计算得到“出货准备的储备量”数据、“补充量”数据、“计划仓储的紧急运送量”数据、“过多使用量累积”数据、“计划仓储的紧急运送量”数据和“短缺量累积”数据。此外，将上述所形成的交付情况显示屏1102发送到用户方服务器20。
图12表示比图11中的情况晚1周的1999年第37周的情况。如1201所示，可以看到，此时已接收到第42周至第49周的“预报”数据。
在第37周，与“确定时间段”数据(6周后)相应的周是第43周。因此，通过计算得到第43周的“出货约定量”为60个和“出货约定储备量”为240个。也就是说，第43周的“预报”数据60个被作为第43周的“出货约定量”数据。此外，将第43周至第46周这4周的“预报”数据相加，从而得到第43周的“出货约定储备量”为240个(60+60+60+60)。
此外，根据图6中所示的流程，通过计算得到第37周的“计划的生产安排量”为0个。也就是说，由于本系统在第36周被启动，因而，“a”＝36，而在第37周，“n”＝2。因此，第37周的“计划的生产安排量”数据＝100(第42周的“出货约定量”数据)+60(第37周所要确定的第43周的“出货约定量”数据)+60(第44周的“预报”数据)+60(第45周的“预报”数据)+60(第46周的“预报”数据)-360(第36周的“生产安排量”数据)＝-20个。由于该值为负数，因此，第37周的“计划的生产安排量”数据为0个。再者，由于“过多使用量累积”数据为0个，因此，根据“生产安排量”数据＝“计划的生产安排量”数据，第37周的“生产安排量”数据为0个。
再者，根据图6中所示的流程，通过计算可以得到第42周的“计划仓储的生产安排量”数据为0个。
此外，在第37周时，由于图7至10中所示的流程的激活条件不满足，因此，无法通过计算得到“出货准备的储备量”数据、“补充量”数据、“计划仓储的紧急运送量”数据、“过多使用量累积”数据、“计划仓储的紧急运送量”数据和“短缺量累积”数据。此外，将上述所形成的交付情况显示屏1202发送到用户方服务器20。
图13表示比图12中的情况晚1周的1999年第38周的时刻。如1301所示，可以看到，此时已接收到第42周至第49周的“预报”数据。
在第38周，与“确定时间段”数据(6周后)相应的周是第44周。因此，通过计算得到第44周的“出货约定量”数据为50个和“出货约定储备量”数据为270个。
此外，根据图6中所示的流程，通过计算得到第38周的“计划的生产安排量”数据为70个。也就是说，由于本系统在第36周被启动，因而，“a”＝36，而在第38周，“n”＝3。因此，第38周的“计划的生产安排量”数据＝100(第42周的“出货约定量”数据)+60(第43周的“出货约定量”数据)+50(第38周所要确定的第44周的“出货约定量”数据)+50(第45周的“预报”数据)+50(第46周的“预报”数据)+120(第47周的“预报”数据)-360(第36周的“生产安排量”数据)-0(第37周的“生产安排量”数据)＝70个。再者，由于“过多使用量累积”数据为0个，因此，根据“生产安排量”数据＝“计划的生产安排量”数据，第38周的“生产安排量”数据为70个。
再者，根据图6中所示的流程，通过计算可以得到第43周的“计划仓储的生产安排量”为70个。
此外，在第38周时，由于图7至10中所示的流程的激活条件不满足，因此，无法通过计算得到“出货准备的储备量”数据、“补充量”数据、“计划仓储的紧急运送量”数据、“过多使用量累积”数据、“计划仓储的紧急运送量”数据和“短缺量累积”数据。此外，将上述所形成的交付情况显示屏1302发送到用户方服务器20。
图14表示比图13中的情况晚1周的1999年第39周的时刻。如1401所示，可以看到，此时已接收到第42周至第50周的“预报”数据。
在第39周，与“确定时间段”数据(6周后)相应的周是第45周。因此，通过计算得到第45周的“出货约定量”数据为10个和“出货约定储备量”数据为130个。
此外，根据图6中所示的流程，通过计算得到第39周的“计划的生产安排量”数据为0个。也就是说，由于本系统在第36周被启动，因而，“a”＝36，而在第39周，“n”＝4。因此，第39周的“计划的生产安排量”数据＝100(第42周的“出货约定量”数据)+60(第43周的“出货约定量”数据)+50(第44周的“出货约定量”数据)+10(第39周所要确定的第45周的“出货约定量”数据)+10(第46周的“预报”数据)+10(第47周的“预报”数据)+100(第48周的“预报”数据)-360(第36周的“生产安排量”数据)-0(第37周的“生产安排量”数据)-70(第38周的“生产安排量”数据)＝-90个。由于该值为负数，因此，第39周的“计划的生产安排量”数据为0个。再者，由于“过多使用量累积”数据为0个，因此，根据“生产安排量”数据＝“计划的生产安排量”数据，第39周的“生产安排量”数据为0个。
再者，根据图6中所示的流程，通过计算可以得到第44周的“计划仓储的生产安排量”数据为0个。
再者，由于第42周晚了3周，并且落在“预定时间段”数据内，因此，根据图7中所示的流程，通过计算可以得到“出货准备的储备量”(360)个。将该值置于括号中的原因是因为它是一个预定值。这里，由于在计算时，如第42周的情况所示，假定了“固定定单”数据和“交付指定量”数据分别为50个，因此，这些值在第42周中各自的行中用括号中的值来表示，但未必总是这样来表示。
再者，根据第42周的“出货约定储备量”数据与“出货准备的储备量”数据的差，通过计算得到第39周的“补充量”数据为0个和第44周的“计划仓储的补充量”数据为0个。
此外，在第39周时，由于图8至10中所示的流程的激活条件不满足，因此，无法通过计算得到“过多使用量累积”数据、“计划仓储的紧急运送量”数据和“短缺量累积”数据。此外，将上述所形成的交付情况显示屏1402发送到用户方服务器20。
图15表示比图14中的情况晚1周的1999年第40周的时刻。如1501所示，可以看到，此时已接收到第42周至第50周的“预报”数据。
在第40周，与“确定时间段”数据(6周后)相应的周是第46周。因此，通过计算得到第46周的“出货约定量”数据为5个和“出货约定储备量”数据为105个。
此外，根据图6中所示的流程，通过计算得到第40周的“计划的生产安排量”数据为0个。也就是说，由于本系统在第36周被启动，因而，“a”＝36，而在第40周，“n”＝5。因此，第40周的“计划的生产安排量”数据＝100(第42周的“出货约定量”数据)+60(第43周的“出货约定量”数据)+50(第44周的“出货约定量”数据)+10(第45周的“出货约定量”数据)+5(第40周所要确定的第46周的“出货约定量”数据)+10(第47周的“预报”数据)+20(第48周的“预报”数据)+70(第49周的“预报”数据)-360(第36周的“生产安排量”数据)-0(第37周的“生产安排量”数据)-70(第38周的“生产安排量”数据)-0(第39周的“生产安排量”数据)＝-105个。由于该值为负数，因此，第40周的“计划的生产安排量”为0个。再者，由于“过多使用量累积”数据为0个，因此，根据“生产安排量”数据＝“计划的生产安排量”数据，第40周的“生产安排量”数据为0个。
再者，根据图6中所示的流程，通过计算可以得到第45周的“计划仓储的生产安排量”数据为0个。
再者，由于第42周和第43周晚了3周，并且落在“预定时间段”数据内，因此，根据图7中所示的流程，通过计算分别可以得到第42周的“出货准备的储备量”(360)个和第43周的“出货准备的储备量”(290)个。这里，“出货准备的储备量”(290)个是根据第41周的“计划仓储的生产安排量”360个和第42周的“预报”数据70个利用表达式(360-70＝290)所得到的。
再者，根据第43周的“出货约定储备量”数据与“出货准备的储备量”数据的差，通过计算得到第40周的“补充量”数据为0个和第45周的“计划仓储的补充量”数据为0个。
此外，在第39周时，由于图8至10中所示的流程的激活条件不满足，因此，无法通过计算得到“过多使用量累积”数据、“计划仓储的紧急运送量”数据和“短缺量累积”数据。此外，将上述所形成的交付情况显示屏1502发送到用户方服务器20。
图16表示比图15中的情况晚1周的1999年第41周的时刻。如1601所示，可以看到，此时已接收到1999年第43周至第50周的“预报”数据和第43周的“固定定单”数据。此外，如1601所示，尚未接收到1999年第43周的“紧急运送信息”数据。另外，如“交付指定量”数据的那行中所示，可以看到，已指定第42周有110个零部件要交付给用户。再者，参见“仓储的生产安排量累积”数据的那行，可以看到，360个零部件实际上已仓储在库存点。
在第41周，与“确定时间段”数据(6周后)相应的周是第47周。因此，通过计算得到第47周的“出货约定量”数据为10个和“出货约定储备量”数据为235个。
此外，根据图6中所示的流程，通过计算得到第41周的“计划的生产安排量”为30个。也就是说，由于本系统在第36周被启动，因而，“a”＝36，而在第41周，“n”＝6。因此，第41周的“计划的生产安排量”数据＝100(第42周的“出货约定量”数据)+60(第43周的“出货约定量”数据)+50(第44周的“出货约定量”数据)+10(第45周的“出货约定量”数据)+5(第46周的“出货约定量”数据)+10(第41周所要确定的第47周的“出货约定量”数据)+20(第48周的“预报”数据)+100(第49周的“预报”数据)+105(第50周的“预报”数据)-360(第36周的“生产安排量”数据)-0(第37周的“生产安排量”数据)-70(第38周的“生产安排量”数据)-0(第39周的“生产安排量”数据)-0(第40周的“生产安排量”数据)＝30个。再者，由于“过多使用量累积”数据为正数，因此，根据“生产安排量”数据＝“计划的生产安排量”数据，第41周的“生产安排量”数据为30个。
再者，由于第42周至第44周晚了3周，并且落在“预定时间段”数据内，因此，通过计算可以得到第42周至第44周的“出货准备的储备量”数据分别为360个、(250)个和(240)个。第43周的“出货准备的储备量”(250)个是将实际上已仓储在库存点的360个减去“交付指定”数据110个利用公式(360-110＝250)所得到的。此外，假定，第43周的“预报”数据80个已被交付，而第43周的“计划仓储的生产安排量”数据70个已被仓储，那么，利用公式(110-100＝10)，根据第49周的“出货准备的储备量”(250)个可得到第44周的“出货准备的储备量”(240)个。
再者，根据图7中所示的流程，将第44周的“出货约定储备量”数据270个与“出货准备储备量”数据(240)个进行比较，“出货准备的储备量”数据少了30个，因此通过计算可以得到“补充量”数据为30个和“计划仓储的生产安排量”数据为30个。
再者，根据图8中所示的流程，由“固定定单”数据-“出货约定量”数据(110-100＝10)可以得到“过多使用量累积”数据为10个。此外，由于在第42周“出货准备的储备量”数据-“固定定单”数据未变为负数，因此不显示警报。
再者，根据图9中所示的流程，通过计算出(“计划仓储的生产安排量”数据-“仓储的生产安排量累积”数据)+(“计划仓储的补充量”数据-“仓储的补充量累积”数据)，可以得到第42周的“短缺量累积”数据为0个((360-360)+(0-0)＝0)。
此外，在第42周时，由于没有接收到“紧急运送信息”数据，因此，图10中的流程未被激活，从而不能计算出“计划仓储的紧急运送量”数据。此外，将上述所形成的交付情况显示屏1602发送到用户方服务器20。
图17表示比图16中的情况晚1周的1999年第42周的时刻。如1701所示，可以看到，此时已接收到1999年第45周至第50周的“预报”数据和1999年第43周和第44周的“固定定单”数据。此外，如1701所示，此刻尚未接收到“紧急运送信息”数据。另外，参见“交付指定量”数据的那行，可以看到，还指定了第43周要交付150个零部件。
在第42周，与“确定时间段”数据(6周后)相应的周是第48周。因此，通过计算得到第48周的“出货约定量”数据为20个和“出货约定储备量”数据为275个。
此外，根据图6中所示的流程，通过计算得到第42周的“计划的生产安排量”数据为50个。也就是说，由于本系统在第36周被启动，因而，“a”＝36，而在第42周，“n”＝7。因此，第42周的“计划的生产安排量”数据＝100(第42周的“出货约定量”数据)+60(第43周的“出货约定量”数据)+50(第44周的“出货约定量”数据)+10(第45周的“出货约定量”数据)+5(第46周的“出货约定量”数据)+10(第47周的“出货约定量”数据)+20(第42周所要确定的第48周的“出货约定量”数据)+100(第49周的“预报”数据)+105(第50周的“预报”数据)+50(第51周的“预报”数据)-360(第36周的“生产安排量”数据)-0(第37周的“生产安排量”数据)-70(第38周的“生产安排量”数据)-0(第39周的“生产安排量”数据)-0(第40周的“生产安排量”数据)-30(第41周的“生产安排量”数据)＝50个。再者，由于“过多使用量累积”数据为正数，因此，根据“生产安排量”数据＝“计划的生产安排量”数据，第42周的“生产安排量”数据为50个。
再者，由于第42周至第45周晚了3周，并且落在“预定时间段”数据内，因此，通过计算可以得到第42周至第45周的“出货准备的储备量”数据分别为360个、250个、170个和(-10)个。
再者，根据图7中所示的流程，将第45周的“出货约定储备量”数据130个与“出货准备的储备量”数据(-10)个进行比较，“出货准备的储备量”数据少了140个，因此通过计算可以得到第42周的“补充量”数据为140个和第47周的“计划仓储的补充量”数据为140个再者，根据图8中所示的流程，将第43周的90个(150-60)加上第42周的10个，可以得到“过多使用量累积”数据为100个。此外，由于在第44周“出货准备的储备量”数据-“固定定单”数据变为负数(170-180＝-10)，因此在各自的行中显示警报如闪烁的指示灯。
再者，根据图9中所示的流程，将第42周的0个加上第41周的0个，经计算可以得到第43周的“短缺量累积”数据为0个。
此外，在第42周时，由于没有接收到“紧急运送信息”数据，因此，图10中的流程未被激活，从而不能计算出“计划仓储的紧急运送量”数据。此外，将上述所形成的交付情况显示屏1702发送到用户方服务器20。
观察图17中的情况，由于在第44周用户所要求交付的零部件量(180个)大于可以在库存点准备好的零部件量(170个)，因此不能满足“固定定单”数据。这里，可根据“过多使用量累积”数据和“短缺量累积”数据来考虑造成这种情况的原因。首先，第43周的“过多使用量累积”数据为100个，可以看到，“固定定单”数据大大超过了基于从用户处接收到的“预报”数据的“出货约定量”数据。相反，第43周的“短缺量累积”数据为0个，据此可以看到，供应商保证将与“生产安排量”数据和“补充量”数据相应的一定量的零部件仓储在库存点。因此，显然，应由用户对“出货准备的储备量”数据不符合“固定定单”数据的情况负责。
与图17类似，图18表示作为当前时刻的1999年第42周。不过，图18表示这样的情况，即在其显示单元21上显示图17中1707所指示的交付情况显示屏的用户将发送如1801所指示的“紧急运送信息”数据。
当供应方服务器10接收到“紧急运送信息”数据时，通过计算得到第43周的“计划仓储的紧急运送量”数据为10个。这是因为，当第42周的“紧急运送信息”数据的“运送办法”数据是与空运相应的数据时，“所要求的时间段”数据是1周。此外，应当注意，附加的第43周的“计划仓储的紧急运送量”数据10个改变了第44周和第44周以后的“出货准备的储备量”数据。
因此，形成了图18中1801所指示的交付情况显示屏，以便发送给用户方服务器20。
此外，图18中的重要的一点是将这10个空运到库存点的费用问题。通常，通过海路将零部件从供应商运送到库存点需要3周。再者，海路运送费事先包含在零部件的定价中。这里，问题是由谁来支付空运所带来的费用。过去，由于根据供应商和用户的状况的差别来判断，因此，通常由供应商来支持这一额外的费用。然而，通过使用根据本发明的系统，就可以很清楚地知道紧急运送的原因。正如前面所述，应由用户对所发生的紧急运送情况负责。
注意，图11至18中所用的交付情况显示屏只是一些例子，它们可以进行各种修改。例如，在上述例子中，各种数据是按周进行计算的，以形成交付情况显示屏，然而，数据处理也可以变成按天或按月来进行。此外，系统最好应用于电子零部件供应管理，不过，系统也可以应用于非电子零部件的零部件的供应管理。
权利要求
1.零部件供应管理系统的一种数据处理方法，该系统具有供应方服务器和用户方服务器，这两个服务器都易于与网络连接，这种方法包括如下步骤在所述供应方服务器，通过所述网络接收来自所述用户方服务器的零部件使用预报信息和定单信息；存储所述零部件使用预报信息和所述定单信息；根据所述零部件使用预报信息得到生产安排信息，所述生产安排信息用来启动零部件的生产安排和零部件的运送；根据所述零部件使用预报信息或所述定单信息得到储备预报信息；和根据所述零部件使用预报信息和所述储备预报信息得到补充信息，所述补充信息用来启动零部件的补充和零部件的运送。
2.权利要求1的数据处理方法，其中，所述供应方服务器展现含有所述生产安排信息、所述储备预报信息和所述补充信息的显示屏，并将所述显示屏发送给所述用户方服务器。
3.权利要求1的数据处理方法，其中，根据所述零部件使用预报信息，在等于或大于将零部件从供应商供应给用户的所需时间的第一时间段内，确定所述生产安排信息。
4.权利要求1的数据处理方法，其中，根据所述零部件使用预报信息和所述储备预报信息，在小于所述第一时间段的第二时间段内，确定所述补充信息。
5.权利要求2的数据处理方法，其中，如果所述储备预报信息中所指示的量达不到所述定单信息中所指示的量，那么所述供应方服务器将所述定单信息与所述储备预报信息进行比较，并在所述显示屏上发出一个警报。
6.权利要求2的数据处理方法，其中，所述供应方服务器得到与供应商根据所述零部件使用预报信息答应交付给用户的零部件量相应的交付约定量信息和与供应商答应为用户储备的零部件量相应的储备约定量信息，并在所述显示屏上显示所述交付约定量信息和所述储备约定量信息。
7.权利要求6的数据处理方法，其中，所述供应方服务器根据所述交付约定量信息和所述定单信息得到表示用户方定单情况的过多使用量信息，并在所述显示屏上显示所述过多使用量信息。
8.权利要求2的数据处理方法，其中，所述供应方服务器根据所述生产安排信息和所述补充信息得到表示供应方零部件供应情况的信息，并在所述显示屏上显示所述信息。
9.权利要求1的数据处理方法，其中，所述供应方服务器通过所述网络接收发自所述用户方服务器的紧急运送信息，并根据所述紧急运送信息修改所述储备预报信息。
10.权利要求9的数据处理方法，其中，所述紧急运送信息包括关于运送办法的信息。
11.权利要求1的数据处理方法，其中，所述供应方服务器通过所述网络将所述生产安排信息、所述储备预报信息和所述补充信息发送给所述用户方服务器，以形成一个显示屏。
12.权利要求11的数据处理方法，其中，所述供应方服务器得到与供应商根据所述零部件使用预报信息答应交付给用户的零部件量相应的交付约定量信息和与供应商答应为用户储备的零部件量相应的储备约定量信息，并通过所述网络将所述交付约定量信息和储备约定量信息发送给所述用户方服务器。
13.权利要求11的数据处理方法，其中，所述供应方服务器根据所述生产安排信息和所述补充信息得到表示所述供应方零部件供应情况的信息，并通过所述网络将所得到的所述信息发送给所述用户方服务器。
14.权利要求11的数据处理方法，其中，所述供应方服务器根据所述生产安排信息和所述补充信息得到表示供应方零部件供应情况的信息，并通过所述网络将所得到的所述信息发送给所述用户方服务器。
15.权利要求11的数据处理方法，其中，所述供应方服务器通过所述网络接收发自所述用户方服务器的紧急运送信息，并根据所述紧急运送信息修改所述储备预报信息。
16.权利要求15的数据处理方法，其中，所述紧急运送信息包括关于运送办法的信息。
全文摘要
本发明提供了零部件供应管理系统的一种数据处理方法,以便通过保持用户与供应商之间的密切关系来供应既不过多也不短缺的零部件量。在这种数据处理方法中,供应方服务器(10)通过网络(1)接收来自用户方服务器(20)的零部件使用预报信息和定单信息,存储零部件使用预报信息和定单信息,根据零部件使用预报信息得到生产安排信息,根据零部件使用预报信息或定单信息得到储备预报信息,和根据零部件使用预报信息和储备预报信息得到补充信息。
文档编号G06Q30/06GK1362931SQ01800335
公开日2002年8月7日 申请日期2001年2月23日 优先权日2000年2月25日
发明者登内英宪, 小松由起夫 申请人:如碧空株式会社