不久前谷歌发布了自己了浏览器--chrome,中文名就叫:谷歌浏览器,对于网络上早已有点评论,我就不说了,我只是想说说自己的使用心得: 第一:简洁,启动速度快,比起IE浏览器和火狐来说,谷歌浏览器的启动速度都要快很多. 第二:打开网页的速度快,都说火狐的速度快,但火狐就个人的使用来看,只是个别网页快一点,或者说刚使用的时候比较快,使用一些时间后,速度也一样变慢,甚至比IE7更慢.而且对于某些JAVASCRIPT支持并不好. 但谷歌浏览器真的很快. 第三:对javascript的支持也非常好,这也是谷歌浏览器速度快的原因,解析的非常好,这都是javascript的引擎的功劳.
  越来越不能忍受ERP系统安装时间过久的情况,越来越不能忍受操作系统的冗余和呆慢,如果你现在问我,未来到底是B/S 的天下,还是C/S的天下,那我肯定要说:B/S,老兄等着瞧吧.  随着下一代互联网的到来(带宽再也不是问题),随着RIA的日愈兴起(利用Brower交互更加方便,安全与功能并存),随着云计算概念的实际化(让所有的负担交纷给"云"吧),从这一时刻起,我们就再也不想忍受微软PC操作系统了,再也不想忍受装个操作系统之后,还需要装各种各样的程序,花个一两天的时间.其实我只想简简单单的启动电脑,弹出一个Brower,然后,OK,我需要什么?有一个引导界面就可以了.我可以打开任何只要我有权限打开的程序,这多么棒呀.我的数据可以放在网上,也可以放在本地,这个对我来说没有任何影响.
现在越来越多的企业重视起自己的仓库来了,所以购买金蝶K/3进销存的企业真不少. 进销存也是一个企业实施生产管理,成本管理的第一步,如果一个企业的进销存都不完善,企业更深层次的管理也将免谈了. 好了,今天不说进销存的重要性,今天想说说的是自己对仓库系统数据表的一点点认识. 仓库系统的数据都会放到哪些表当中: 1.icstockbillentry:出入库单据分录表,实仓库的出入库单据录入的数据都统一放在这张表上. 2.icinvinitial:存货初始数据表:当我们初始化录入数据时,数据就是放在这张表当中.
总结一下自己的生产计划流程图:(呵呵,虽然有现成的,但自己总结一下,总是踏实一点)  
       客户的产品代码突然提出要马上更换,因为属于代工企业,所以客户的产品代码和客户的客户的产品代码是保持一致的.        客户的客户产品代码因为某种原因要变换了,一下子有800,当时听到这个问题,吓坏了我,这可咋办?让他们一个个去替换?不可能了,人家都天天用.看来只能改数据库了.又是改数据库,真是危险哦.      
虽然经常用,但有时竟然一下就忘记,还是记下来好: 一:迷你版,标准版报表日期函数: &[会计年度]:年份 &[报表期间]:月份 &[最大日期]:每月月底 二:专业版,K/3报表日期函数: 一个函数搞定 &[rptdate("yyyy-mm-dd")]
        星期天,去了朋友那里玩,朋友在一家大型制造企业搞ERP开发,朋友的企业也购买了金蝶ERP,但有些功能达不到要求,所以有一些方面还需要自己开发.        首先讲到的就是B/S和C/S架构,现在主要的ERP系统都是B/S架构,那么以后的ERP系统会不会走向C/S架构呢?随着丰富的互联网应用的兴起,比如ajax,flex/flash,sliverlight等等的如日中天,还有网络宽带的数量级提高,这些都也许将改变ERP系统传统的B/S架构.金蝶也推出了了在线的软件服务,虽然只是雏形,还看不到什么盈利,但是我想,通过技术的不断改进,一定会有所突破的.       当然我们还谈到了金蝶ERP的行业性,比如说,我们在电子,塑胶,五金的制造行业常常做的比较好,但一遇上服装类,印刷类的制造行业时,常常是水土不服,因为服装类和印刷类行业的产品特点多,产品生命周期短.尤其我们就谈到了服务中款式的不同颜色的管理,我们都知道金蝶ERP是可以通过辅助属性来管理颜色的,遗憾的是辅助属性仅仅是一个分类,目前还无法做到真正的辅助属性区别,因为尤其是在做成本核算时,并不会将辅助属性考虑在其中,
需要重新整理:        首先当然要好好整理一下思绪,很多的计划需要重新的拟定,对于k/3已经有一些时间没有花精力去学习了,需要首先整理一下:       整理财务,供应链,生产管理,计划管理,成本管理的流程,例出其中的重要点,难点及其细节问题.       整理财务,供应链,生产管理,计划管理,成本管理的数据库及其其中对应数据表的逻辑关系,一些常见的或可能忽视的数据库问题.
好久没写博客了,一直都不知道写什么好,因为不知道以后的路会如何? 在这家代理商工作将近两年了,两年来,几乎所有的东西都是自摸的,想想前些日子,天天起早贪黑,东奔西跑,公司就两个服务的,客户的分厂在河源有,在深圳有,我一个人负责ERP项目的实施,上线,天天跑来跑去, 有的时候一待就是一个星期半个月.那些日子的高压力就不说了.几乎每天7点起床,干活到9点——10点,9点客户全公司的人都快走光了,我一个还在那里搞,如果不是保安要锁门了,我还不知道) 两年说长不长说短也不短,和同学聊天,都觉得要么能够学到东西,要么薪水不错(我想大部分人也是这样想)
案例:客户的产品有两种包装方式,在录入销售订单时需要指定其中的一种BOM.所以采用了客户BOM,此案例不涉及到特征件,属于比较简单初级的应用.如有错误之处,还请指出. 这三层的BOM,如果展开看看会有多长,客户BOM维护起来可真不容易啊! 
不可否认,k/3比其它一些ERP的界面要整洁,漂亮一些,可是,可能因为这一点也导致了K/3 操作灵活性的降低. 这就是k/3无法同时打开两个以上的操作界面. 仓库人员,经常面对一堆不同类型的单据,如外购入库,产品入库,其他入库,生产资料,销售出库等.他们还需要同时打开不同的报表,他们不得不疲惫的"奔波"于这些界面之间. 物控生产部门的人员,同样如此,他们经常需要采购,生产,销售的数据,可是,由于同样的原因,他们一样的"疲惫". 有的时候连我们自己都觉得,为什么这么繁琐? 希望这个缺陷总部的开发人员能够改正,k/3的界面不仅要整洁,漂亮,规范,还希望能够加上一点点的易操作性.
客户BOM好似鸡肋:        刚刚为客户产品会同时有两种包装方式觉得采用客户BOM可以有效的解决,可是刚刚欣喜之余,却又突然发现,客户BOM不能默认标准BOM。        我想,在多数企业有同一个产品会有两种BOM的的情况下,多是一种是比较经常出现的,另一种只是在某些情况会出现,所以在多数情况下可以默认为标准BOM,当需要时,再选择另一种BOM方式。       
其实以前就发现了这个问题. 不过看来现在这个问题挺严重的了,因为客户的仓库特多,在打印盘点报表的时候,发现设置的页眉页脚,退出来后不能自动保存,再次进入又得重新设置一下.  自己估计着是不是有一张表存储了这些页眉页脚,当退出来后,表中的内容会自动复原.但没法跟踪出来,不知哪位朋友知道?告知一下解决办法.
最近,很多家客户的账套同时出现日志文件太大的现象,操作和备份都受到影响,客户又不愿意把账套中的日志删除掉了,所以就只好动用了日志压缩的方式,如何正确的进行账套日志压缩呢?话不多说,直接入题.语法如下: dbcc shrinkfile(fileID,target_size)或者dbcc shrinkfiles(name,target_size)fileID和name分别为账套日志的文件id号和账套日志的文件名称target_size为需要压缩到的日志大小,单位默认为MB)账套的日志信息可以通过以下语句来获得select
放上一视频:    如果速度比较慢 请点击下载(请稍候 格式:|时长:)
更多 »