基础设置要点简介之基础数据

基础数据通常是指与具体业务关系不大且具有全局性、基础性的一些基本数据，例如日历Calendar、币种Currency、汇率Rate、单位UOM、地点Location等等。这些基础数据的系统设置有些比较简单如“币种”，有些与真实世界的情况相似如“日历”，有些则可能比较抽象复杂如“地点”等等，情况多种多样。以下择其要者，作简要说明。

（一）关于“日历”。EBS中的日历设置，实际包括两大类，一类是与会计工作相关的，包括“会计日历”、“会计事务处理日历”等，它们的使用范围较小，有专门用途，一般是在总账模块设置（这里不赘述）。一类是工作日日历，它与企业的日常业务工作相关，使用范围广泛，大多数涉及库存组织的业务模块都可能与之相关，如下图35所示：

 

需要注意的是，在新设置工作日日历或更新已存在工作日日历后，需要通过在工具栏的“建立”功能启动一个后台并发程序，以最终完成设置工作。

（二）关于“币种”。各国或地区的“货币”是一种客观存在，EBS系统已经预置几乎所有企业可能使用到的币种，必要时还可以添加。用户可以决定哪些币种需要启用，以及维护其使用时的“精确度”。如下图36所示：

 

（三）关于“汇率”。企业对于不同币种汇率转换的管理是一项重要的基础性工作，它对企业的经营结果有重要影响。为方便该项工作的开展，EBS系统专门提供了一个名为“币种管理器”的工具，如下图37所示：

 

企业可以根据工作需要设定多个“汇率类型”（系统初始预置了Corporate值），并为之维护“每日汇率”或基于帐套的“期间汇率”。汇率的维护可以按一段时间范围来进行，也可以通过外部的“电子表格”导入数据。

（四）关于“单位”。计量单位虽然也可以看作是一种客观存在，但单位与基本单位之间的转换关系，则可能是与具体物料相关的（例如鸡蛋1斤=15个，鸭蛋1斤=10个等，转换系数不同）。由于EBS的物料是定义在库存组织INV上的，故单位及转换关系也是基于INV设置的。如下图38所示：

 

EBS的单位转换，提供了不考虑具体物料的“标准转换”，例如1米=100厘米等，也提供了基于不同物料的在同一“单位分类”（如长度、重量、体积等）内部的转换，例如牛奶 1箱=20盒，茶叶 1箱=10盒等；以及不同物料在不同“单位分类”之间的转换，例如牛奶 1公斤=4盒，茶叶 1公斤=2盒等。

（五）关于“地点”。EBS中所谓“地点”的概念不仅非常抽象，而且十分重要，因为系统相关业务处理功能如“接收、发运、人员分配”等等都与“地点”密切相关。EBS中的所谓“地点”原意实际上涉及三个词：Location、Address、Site。译成中文都可称“地点”，也是导致其理解困难的重要原因之一。如下图39所示：

 

Address（地址）比较好理解，它表示一个地理坐标概念，例如“北京市朝阳区安定路甲3号”等，EBS系统以一个“说明性弹性域”来精确描述，非常方便。各个国家的Address表述方式可能不同（如中国与美国有差别），故系统有所谓“中国式地址”、“美国式地址”之分等等。

Location（地点）的系统涵义则理解比较抽象，系统定义的名称可以看作是与一个具体Address相关联的一个或多个不同“称谓代号”，例如与上述Address“北京市朝阳区安定路甲3号”关联的Location“鸟巢、国家体育场、奥林匹克公园、奥运主会场”等等。也可以是一个不与具体地址Address相关联但大家都明白的称谓代号，例如Location“天.安.门、首都机场”等等。

EBS系统最初使用比较“简短”的Location代替比较“冗长”的Address，仅仅是为了方便IT“标准化”处理的需要。但在以后的发展过程中，系统设计逐步赋予Location更多与业务处理功能相关的“属性”，为了区分这些不同属性，系统以Site（站点）来加以区分，如图39中所示，一个Location可以具有“发运到Ship-to”、“接收至Receiving”、“开票到Bill-to”、“内部Internal”等等不同系统功用。

更进一步，EBS系统使用“地点”来实现采购申请、接收、运输清单和人员的分配，以及确定内部组织与内部客户、供应商的关联关系；使用同一供应商的不同Site来区分定义供应商所具有的不同“业务控制”属性；使用同一客户所具有的不同Location—Site组合来区分定义客户所具有的不同业务功能（OM的某些业务功能必须将客户的外部Address—Location组合与系统内部Location关联方才有效）等等；详情以后相关模块再进一步讨论。

总之，搞清楚EBS系统Address、Location、Site的三者关系，对于理解掌握系统功能十分重要，其核心与关键是不能将比较抽象的Location或Site与比较具体的Address等量齐观，两者虽有一定关系，但Location或Site更多地是从系统实现的需要出发，而做的某种“形而上”表达。