仓库ERP系统如何 *** 作的

步骤如下：

1、手机打开仓库erp管理系统，完成登录。

2、接下来需要点击入库，如下图所示。

3、接下来需要添加入库，如下图所示。

4、接下来需要确定添加入库，如下图所示。

5、接下来需要返回首页，点击出库。

6、接下来需要添加出库，如下图所示。

7、确定添加出库，完成仓管erp系统入库出库 *** 作。

首先，ERP不是具体软件的名称，它是一个软件的类别，就像 *** 作系统有WINDOWS，有UNIX，ERP也有很多品牌，比如SAP，ORACLE，BAN，QAD，等等。
另外，ERP系统里会包含十几个到上百个模块（因品牌而异），其中一定会有存货管理模块，但没有“仓库ERP系统”的说法。
至于怎么用，那不同的ERP系统会有不同的 *** 作方法不同的程序界面，没有统一的 *** 作步骤。
同时，ERP是一个系统，大多数的 *** 作是自动完成的，比如，当系统下达一个车间订单后，它会自动按照物料清单生成发料单，仓库管理员只要按单发料，并把发料信息输入到ERP系统即可。
同样采购单会生成收货单；客户订单会生成发货单；产品完工下线会生成完工入库单；仓库盘点后需要输入盘盈盘亏数量；其他还有半成品线边库，转移仓库，库位，货架等等概念。
总之，你要用哪个ERP就要让它的生产商的顾问对你进行培训，或者你自己拿培训资料自学，或者让会使用的同事教你。你想在这里碰到一个你的那种ERP的顾问，然后让他免去一天几百美金的培训费，免费教你，我觉得可能性不大。

ERP,现在存在的ERP很多,就是有些公司的业务管理也叫ERP,首先,你要清楚公司用的是什么品牌的软件再根据说明书,或者实施顾问学习一下一般仓库管理比较简单,主要是得到一些汇总表,分库表,出入库表等报表

一、发货流水线安排

流水线仅供参考，考虑到场地的限制，最终目的是合理利用场地，缩短 *** 作路线，提高效率。

二、审单打单方案

一般来说，在双11活动开始后1小时就可以开始审单了。可以在ERP中设置无备注自动审单功能(页面上要说明无备注优先发货)，审单人员只审有备注的、智能快递匹配不到的异常订单。然后按照订单总件数打单，先打单件，再2件，3件，以此类推。还有，不要忘记异常单处理，检查未审订单、检查已审未打印订单、检查已打印未发货订单。

三、配货

配货的时候，尽量一货对应货区，根据备货单上的货位提示，去对应的货位，缩短拣货路程，减少重复路线，提高准确率。PS：配货员随身带笔，没配到货的做好标记。

四、验货

验货步骤是不能少的一个重要环节，而是否需要批量验货，可根据实际情况进行设置。

验货区分未验、已验、配货错误、订单错误 四种，第三种返给配货员，第四种返给审单员核查，系统增加了声音提示，注意异常声音;相同件数的一起验货，在分给打包员时说明这一批都是几件的，防止打包错件数;可以根据情况，设置是否需要称重，如果不称重系统这时就回传物流单号到前端系统了。

五、打包

打包者要清楚这一批都是几件的，防止件数打包错，这些都要事先规划好。

六、称重

已称重和未称重的包裹注意区分开，称重完的包裹不要随意乱扔，注意整理整齐，面单都朝上，方便快递员签收。

可以按时间段堆放已称重的包裹，防止有人取消订单。称重员要对最后环节负责，系统未称重包裹不要让快递提走了，已称重包裹不要让其他人翻出来拆了。

仓库的设置一般分为实物和系统两部份。实物为货物在库房里真实放置的方法，一般企业会将货物在物理上分为材料、半成品、成品、车间现场库等。如果企业很大，材料也可能分为多个库房。对于系统里的设置一般情况下和实物是一致的，但有时也会虚拟出一些库房。比如企业在车间是没有半成品库房的，但是在进行ERP管理时，会有半成品的出入库管理，因此会设定一个半成品库房，只是这个库房的入库和出库同时发生而已。上了系统之后，对于库房的要求基本上为及时性和准确性。在进行出入库业务时（一般有单据来体现），一定要在单据上明确业务日期、仓库、物料编码、数量、计量单位等，有些企业在系统内会要求 *** 作员同时录入单价或金额。只要保证这些数据的准确性就可以，同时要及时的录入，否则系统中的库存数就不准确了。有些企业为了保证数据及时准确会采用条形码来管理。

1 自增长primary key 采用自增长primary key主要是性能。早期的数据库系统，经常采用某种编号，比如身份z号码，公司编号等等作为数据库表的primary key。然而，很快，大家就发现其中的不利之处。 比如早期的医院管理系统，用身份z号码作为病人表的primary key。然而，第一，不是每个人都有身份z；第二，对于国外来的病人，不同国家的病人的证件号码并不见得没有重复。因此，用身份z号码作为病人表的primary key是一个非常糟糕的设计。考虑到没有医生或者护士会刻意去记这些号码，使用自增长primary key是更好的设计。 公司编号采用某种特定的编码方法，这也是早期的数据库系统常见的做法。它的缺点也显而易见：很容易出现像千年虫的软件问题，因为当初设计数据库表的时候设计的位数太短，导致系统使用几年后不能满足要求，只有修改程序才能继续使用。问题在于，任何人设计系统的时候，在预计某某编号多少位可以够用的时候，都存在预计不准的风险。而采用自增长primary key 则不存在这种问题。同样的道理，没有人可以去记这些号码。 使用自增长primary key另外一个原因是性能问题。略有编程常识的人都知道，数字大小比较比字符串大小比较要快得多。使用自增长primary key可以大大地提高数据查找速度。 2 避免用复合主键 (compound primary key) 这主要还是因为性能问题。数据检索是要用到大量的 primary key 值比较，只比较一个字段比比较多个字段快很多。使用单个primary key 从编程的角度也很有好处， sql 语句中 where 条件可以写更少的代码，这意味着出错的机会大大减少。 3 双主键 双主键是指数据库表有两个字段，这两个字段独立成为主键，但又同时存在。 数据库系统的双主键最早用在用户管理模块。最早的来源可能是参照 *** 作系统的用户管理模块。 *** 作系统的用户管理有两个独立的主键： *** 作系统自己自动生成的随机 ID (Linux, Windows 的 SID), login id。这两个 ID 都必须是唯一的，不同的是，删除用户 test 然后增加一个用户 test, SID 不同，login id 相同。采用双主键主要目的是为了防止删除后增加同样的 login id 造成的混乱。比如销售经理 hellen 本机共享文件给总经理 peter, 一年后总经理离开公司，进来一个普通员工 peter ，两个peter 用同样的 login id, 如果只用 login id 作 *** 作系统的用户管理主键，则存在漏洞：普通员工 peter 可以访问原来只有总经理才能看的文件。 *** 作系统自己自动生成的随机 ID 一般情况下面用户是看不到的。 双主键现在已经广泛用在各种数据库系统中，不限于用户管理系统。 4 以固定的数据库、表应付变化的客户需求 这主要基于以下几个因素的考虑： ◆41 大型EPR系统的正常使用、维护需要软件厂商及其众多的合作伙伴共同给客户提供技术服务，包括大量的二次开发。 如果用户在软件正常使用过程中需要增加新的表或者数据库，将给软件厂商及其众多的合作伙伴带来难题。 ◆42 软件升级的需要。 没有一个软件能够让客户使用几十上百年不用升级的。软件升级往往涉及数据库表结构的改变。软件厂商会做额外的程序将早期版本软件的数据库数据升级到新的版本，但是对于用户使用过程中生成的表进行处理就比较为难。 ◆43 软件开发的需要。 使用固定的数据库库表从开发、二次开发来说，更加容易。对于用户使用过程中生成的表，每次查找数据时都要先查表名，再找数据，比较麻烦。 举例来说，早期的用友财务软件用Access作数据库，每年建立一个新的数据库。很快，用户和用友公司都发现，跨年度数据分析很难做。因此这是一个不好的设计。在 ERP 中，很少有不同的年度数据单独分开。一般来说，所有年份的数据都在同一个表中。对于跨国公司甚至整个集团公司都用同一个 ERP 系统的时候，所有公司的数据都在一起。这样的好处是数据分析比较容易做。 现在大多数数据库系统都能做到在常数时间内返回一定量的数据。比如，Oracle 数据库中，根据 primary key 在 100万条数据中取 10 条数据，与在1 亿条数据中取 10 条数据，时间相差并不多。 5 避免一次取数据库大量数据，取大量数据一定要用分页 这基本上是现在很多数据库系统设计的基本守则。ERP 系统中超过 100万条数据的表很多，对于很多表中的任何一个，一次取所有的会导致数据库服务器长时间处于停滞状态，并且影响其它在线用户的系统响应速度。 一般来说，日常 *** 作，在分页显示的情况下面，每次取得数据在 1-100 之间，系统响应速度足够快，客户端基本没有特别长的停顿。这是比较理想的设计。这也是大型数据库系统往往用 ODBC, ADO 等等通用的数据库联接组件而不用特定的速度较快的专用数据库联接组件的原因。因为系统瓶颈在于数据库( Database) 方面(数据量大)，而不在于客户端(客户端每次只取少量数据)。 在B/S 数据库系统中，分页非常普遍。早期的数据库系统经常有客户端程序中一次性取大量数据做缓冲。现在已经不是特别需要了，主要原因有： ◆51 数据库本身的缓冲技术大大提高 大部分数据库都会自动将常用的数据自动放在内存中缓冲，以提高性能。 ◆52 数据库联接组件的缓冲技术也在提高。 包括ADO 在内的一些数据库联接组件都会自动对数据结果集(result set)进行缓冲，并且效果不错。比较新颖的数据库联接组件，比如 Hibernate 也加入了一些数据结果集缓冲功能。 当然，也有一些数据库联接组件没有对数据结果集进行缓冲，比如 JDBC Driver，不过几年之内情况应该有所改观。也有些不太成功的数据缓冲，比如 EJB 中的实体Bean，性能就不尽如人意，实体Bean数据也是放在内存中，可能是因为占用内存过多的缘故。 相对来说，今天的程序员写客户端数据缓冲，能够超过以上两个缓冲效果的，已经比较难了。

---