| 出版日期：1999-09-06 总期号：855 本年期号：65 |
|
 |
如何解决电子商务的2000年问题
edi中的2000年问题 电子数据交换(edi)是不同的商业实体的计算机应用之间使用一种标准的格式来交换数据和文件。在北美,edi是基于x12标准的。这个标准得到了美国国家标准委员会（ansi）的批准。这些标准的基本创建模块是数据元素。这些元素被组合起来形成一个数据段，数据段再组合起来形成交换集，如810（发票）交换集等。在x12标准中，用来表示日期的绝大部分通用的数据元素是data element ＃373。在1997年2月，这个数据元素被定义为6位的数字，即yymmdd格式。 这就是x12标准为什么会给edi带来2000年问题的原因。由于edi是一种交换商业信息的标准方法，因此日期的问题显得尤为重要。在这种情况下，一种最直接的解决办法就是使用8位数字的日期表示方式，即将date数据元素用yyyymmdd格式表示。但事实上，这种修改并非易事。 x12如何解决2000年问题 x12委员会确定edi的日期格式在全北美都是通用的。为了理解解决x12的2000年问题，首先要理解x12标准中data数据元素的发展过程。 x12最初的日期表示方法是开发专用的data数据元素，如： d/e＃32 delivery date d/e245 invoice date 这种表示方法很快就出现了一个问题：为了防止标准数据库被特写的date数据元素覆盖，就需要使用一个通用date数据元素，因此就创建了数据元素＃373,date?和＃374,date/time,date/time qualifier。专用的date数据元素和通用的date数据元素都是采取yymmdd格式，那时没有考虑到用8位数字表示日期的问题。 这些最早的开发人员提供了下列几种表示日期的方法，分别是： 1.在特写的数据段（如在发票的起始段）使用专用的invoice date数据元素，如invoice date（d/e ＃245）。 2.在特定的段使用通用的date数据元素，通过使用一种对数据元素的语义注释date/time qualifier来解释date的属性。elements bsi02和bqt04－05就是使用该方法的两个例子。 3.使用通用的?date/time ?reference(dtm)段，它包括了通用的date和date/time qualifuer数据元素。 这三种执行同样功能的方法的出现表明当时在x12标准开发过程中存在分岐。这个分岐产生的原因对于解决2000年问题是非常关键的。 x12标准开发者倾向于使用通用的date数据元素来表示日期。 x12组织解决2000年问题的第一个比较重要的举措发生在1991年。这涉及到数据元素＃624，century。这是一个可选的数据元素，用来提供年份的前两个数字（如19或20）。这个元素被添加到通用的dtm段的末尾。这样就允许用户通过使用 date和century元素用8位数字表示日期。使用这种方法，1997年4月10日将表示为： dtm02 element 970410 dtm05 element 19 虽然这并不是一个最理想的方案，因为它强迫日期被分割为两个元素，century元素的可选特性允许那些不想进行修改的人不使用这种方法。这使得它更容易得到批准。在未来几年中，cenury元素将被加到许多edi段中。 同时，那些爱好通用edi标准的人也在寻找更激进的解决方案。在欧洲和亚洲广泛使用的edifact标准被人们视为是通用edi标准开发的一种模型。edifact标准处理日期的方法通过另外加上数据元素＃1250,date tme period foemat qualifer和＃1251,date time period format等集成到x12标准中。这些数据允许用户确定一个日期的格式，包括使用yymmdd格式或yyyymmdd格式。 这种方案的好处是提供了选择两种日期表示格式的灵活性，以及在一个元素中保存日期的能力。 然而，在1991～1992年，人们仍然认为应该避免用户对日期的记录格式作强制性的修改。因此，这个方案一般只在较新的x12标准中实现，尤其是在那些由金融、卫生和保险机构开发的标准中实现。 之后，直到1996年，解决edi 2000年问题的工作才重新开始。这时，计算机系统的2000年问题已经引起了全球的重视，x12也认识到了这个问题的严重性，原来的几种date选择方案的出现被认为是缺乏连续性，尤其是century方案需要将日期分割成两个元素来表示不便于实施。 1996年10月，x12的领导层对x12团体发布了一条命令——同意edi?标准中的计算机2000年问题的连续解决方案。下面方法有可能成为最终方案： 1.通用的date数据元素和date/time reference (dtm)段是解决2000年问题的最好工具，因为它们代表了x12标准中的日期的最通常的表示方法。 2.其它的提供日期的方法（特写的date、century数据元素、date time period format数据元素）被允许保留，但不会继续扩大使用范围。 这个方法后来被集成到特写的数据维护（data maintenance）建议中并交给整个x12团体进行投票。 这个建议（dm ＃114196)提出了如下意见： 1.修改数据类型dt，既允许使用6位数字的yymmdd格式，也允许使用8位数字的yyyymmdd格式。 2.修改通用date数据元素的最小/最大组合为6/6到6/8。 从表面看，这是一个简单的提议，但x12对此达成一致是非常不容易的。它将允许那些反对修改日期的记录格式的人继续使用6位数字的date，而同时又要满足那些需要8位数字解决2000年问题的那部分人。为了容纳日期格式的变化，需要对edi翻译器进行修改，以便于对通用date数据元素的长度格式进行区分。 1996年11月，整个x12团体对data maintenance ＃114196进行了投票，并得到了92％的赞成票。然而，在标准组织中，8％的反对率就意味着建议不能通过。在这个历史背景下，在1997年2月，x12决定开发自己的协议来解决与x12标准相关的2000年问题。 x12建议的方案 在1997年3月，x12?委员会面临很大的压力来开发一个能够为各方所接受的方案。 这次会议提出了如下方案： 1.将所有的date元素的最小/最大标记修改为6/6到8/8。这将要求对所有特定的date数据元素和通用的date数据元素的格式从yymmdd修改为yyyymmdd。 2.去掉century数据元素所有的例程。 这个提议提交给整个x12团体进行投票，投票者注意到了这个建议的许多不同之处： 1.以前的建议允许那些不需要修改的人继续使用yymmdd格式，而这个方案要求所有使用1997年12版本的x12?标准的人必须使用yyyymmdd格式。 2.这个方案去掉了在4010版本中有效的century数据元素。 3.将最小/最大指示标志改为8/8将受到众多edi翻译器公司的赞同。 在芝加哥的x12会议上，技术评估委员会召开了开放论坛(open forum)来讨论这个方案。该方案被x12于1997年6月6日接受。 2000年问题的应用级方案 完全解决2000年问题意味着修改原有的计算机系统以适应edi标准提供的解决方案，即将date格式修改为yyyymmdd格式。 这个方案实施起来非常困难。它不但需要确定哪些地方使用了date元素，而且需要将所有date元素的长度从6位修改成8位。 对计算机系统的应用程序进行检查需要对编程语言很熟悉，而且对成千上万行的代码进行分析也是很不容易的。何况对数据记录的修改也不是一件容易的工作。除非date域是数据记录的最后一个域，对date域长度的修改将会影响所有与之相关的记录。 下面我们举一个例子说明这个问题。一个现有的数据记录的结构如下： 第1～6列 记录号 第7～20列 账单号 第21～26列 运货日期 (yymmdd格式) 第27～28列 运货方法代码 第29～68列 运货方法描述 第69～70列 运货载体代码 第71～80列 运货载体号码 将这个数据记录修改成可以容纳8位日期格式不仅影响运货日期这一栏，而且影响相应的四个栏，如： 第1～6列 记录号 第7～20列 账单号 第21～28列 运货日期 (yymmdd格式) 第29～30列 运货方法代码 第31～70列 运货方法描述 第71～72列 运货载体代码 第73～82列 运货载体号码 对运货日期格式的这种修改，将会导致所有使用了该记录的程序的变化以及所有因此受影响的应用。不仅是使用了运货日期的需要修改，使用后面四个域的所有应用都要作相应的变化。 由于评估和修改遗传计算机系统来处理8位长度的日期的成本可能会很高昂，因此有一些公司正在寻求解决计算机2000年问题的其它方法。其中有一种方法被称为50－99,00－49方法。这个方法是基于修改日期年份以19开头的假设的，也就是当日期后两位数字是0－49时，假设日期的前两位数字是20；当后两位数字是50－99时，假设日期的前两位数字是19。 这种方案的好处是它不需要对日期格式作任何修改，因此不需要太大的成本。日期继续以yymmdd格式存储，但是计算机比较日期的格式按yyyymmdd执行。 但这种方案也有缺点，通过修改这种假设，这个方案只是将2000年问题推迟了50年。到2050年，又需要将所有年份的前两位数字都改为20。不过，如果你的数据所包含的日期范围不超过100，这个方案实施起来要比全部将日期格式变到8位数字记录日期要容易得多。 |
||||||||||||||||
