Mikel

[转载]51地图API离线包下载 – gisvip – 博客园. 最近都在各种离线包, 也提供个51地图的离线包,供大家学习研究. 51地图吸取了Google Maps、Yahoo Maps 和国内同行的优点, 由原来的使用经纬度直投,瓦片大小200*200 转为Web墨卡托,瓦片大小256*256 不过51地图瓦片数据源的编码规则还是很不一样的.值得研究哈 51地图的图片存放规则是从左下开始编号，即左下角为0，0开始 目前官方的api存在bug, http://api.51ditu.com/docs/mapsapi/examples/LTMaps/handleMouseScroll_at_center_mapcartoon.htm 就是如果使用了鼠标中键的动画的话, 在点鱼骨架上的向东,南,北,西 会提示错误. 同样这个离线包也存在这个bug 用法: 在iis中主目录指向51map ie中输入 http://127.0.0.1/index.htm 就可以访问了哈 从51地图API迁移到MapABC地图API http://wenku.baidu.com/view/9bb3e47202768e9951e738ba.html 离线包下载http://files.cnblogs.com/gisvip/51map.rar 请勿商用,只供大家学习交流.51地图还是很不错的.支持国产 商用请联系灵图公司,产生一起问题后果自负 更多交流 请到GISVIP社区交流 http://bbs.gisvip.com

关于库存表的设计，有两种思路，不知那种更严格，应该用哪个，请大家看看： 关于库存表的设计，有两种思路，不知那种更严格，应该用哪个，请大家看看： １．建立一个库存表，这个库存表不是实时的，而是每个月结帐时生成的月末的库存，这个表有个会计期字段，每月一个库存．查询实时库存时，用这个库存表做为期初值，然后加上本月增加数量，再减去本月减少的数量．就是当前的库存数量． 这是论坛上很多人建议的做法，可是这种方法有几个问题如何办呢？ a.每种材料的成本如何得到到，我用的是移动加权法．数量好办，每次根据上月末的库存算一下就行了．可是成本如何得到呢？总不能也用移动加权的公式一个材料一个材料的算吧．我的库中有几千种材料呀． ２．建立一个实时的库存表，反映当前的最新状态．同时建一个出入库明细帐．每次出库和入库时记录当时的结存数，和成本．同时将这个结存数和成本写入到实时库存表中去，这样查询库存和成本时比较方便． 这种方法的主要特点是，每次出入库时都将当时的库存数和成本记到明细帐中去，同时也写入实时库存表中去．这样成本也很容易得到．

. 日志式的管理是一种流水帐式的登记方式，其核心思路是对所有操作进行记录，特征是只登记不修改与删除。   一. 日志结构     单据名称：如：入库单，出库单，调整单等   单据编号：某一特定单据的编号   库存状态：记录各种单据对库存的影响方式为加或减   操作类型：记录当前操作是审核还是撤审。如同样是减库存，也要分是撤审的减库存还是退货的减库存或者调拨仓库的减库存   登记时间：是记录产生加减库存的日期。它在日库存统计起重要作用   物料编码：库存管理中会对每个材料进行唯一编码，以便库存进行管理   物料名称：如 已有物料编码，其名称只是对编码的详细中文注释。如工厂对物料编码不能不能理解，信息化基础很差，那么中文名称将是工厂操作人员通俗的理解方式，系统在此 做预留也就是可以满足此类用户的需求，库存在统计时同样可以按物料名称来统计。物料名称因此可以广义的理解为用户可接受的扩展属性。如：幅宽，规模，颜 色，尺码等。只要是用户可以记忆的信息，都可以归入名称范畴。   发生数量：是一个正数字。本次数量通过发生数量*库存状态来产生。   创建人和创建时间： 通常是记录本单的审核人和审核时间。它与登记时间是有区分的，由于库存统计时对时间的界定一般有两种方式，一种是按审核时间来进行统计库存，另一种是按单 据发生时间来统计，两种方式主要区别是发生时间则用户可自行调整，审核时间要求人员操作及时准确。所以通常用户都会采用第一种方式。   二. 日志式结构的优点与缺点   1. 优点：   (1) 所有影响库存的单据全部统一在一张表里进行管理，查询方便。还要方便进行导出备份。   (2) 在做库存查询与统计时的速度优于散在各处相加再进行统计的方式。   (3) 如果日志完整，可根据日志反向生成各种单据。配合第一条优点，可快速进行单据还原。   2. 缺点：   (1) 日志信息目前只适合记录库存增减，不适合记录业务流向。   (2) 日志量庞大，使用一段时间后，做通库查询速度与性能降低。   (3) [...]

[转载]InfoQ: 大型网站复杂业务持续重构之道——全程领域建模实践. 人物介绍：   Jack Chen ——“宠物商店”的首席架构架构师，拥有丰富的软件设计与建模经验，但对新生事物持怀疑态度。   王总——“宠物商店”的总经理，从美国留学后回国创立“宠物商店”网站。一路来唾手可得的成功让他养成了固执专横的行事作风。   Spark —— Jack Chen的大学同学，一家商业软件公司的高级咨询顾问。最近热衷于宣扬“领域驱动设计”的最佳实践。   引子   就象大家所听说过的那些神奇小子创业故事一样，几只从大西洋游回的海龟找到了一个伟大的idea——在互联网上开办在线商店销售宠物。幸亏的是他们 找到了投资者而且发展的很不错。但是随着时间的推移，当初“完美”的技术架构随着越来越多的装进篮子的需求后变得不堪重负。作为公司首席架构师的Jack Chen已经被这几个月“鸡毛蒜皮”的需求折磨失眠好几天啦。   Jack Chen周一一早就被兴奋的王总给喊进了办公室，立即就被王总扔出来的idea吓傻了。   “我有一个很cool的想法，我们可以在线为宠物医院提供在线预约的服务业务。而不仅仅是卖掉它们，你知道这意味着什么吗？这是一个年产值上百亿的市场！！！”。   “可是王总，我们的系统不能支持这种非实物的服务预订销售，它可能对我们原有的网站形成巨大的冲击，我们需要三个月的时间对这个业务进行全方面的评估…”   Jack Chen立即就被气势汹汹的王总打断了，“三个月的评估？我需要在两个月内就给我上线这个新业务。我们的投资人非常认可我的idea，并要求我们立即把这个项目上线，它可能会帮助我们提高明年的IPO价格。你明白吗？ DO IT ASAP！”   评估   “好吧，也许这个该死的王胖子是对的。我们这个将技术与业务混在一起的乱摊子也是到了该整理整理的时候。”自言自语发了半小时牢骚后的Jack Chen终于恢复到正常状态上来了，我想我应该看看我们现在是什么样子的，为了支持这个该死的“在线为宠物医院提供在线预约的服务”的需求我们需要做出哪 些改变。于是Jack Chen在白板上很快的就画出了下面的Use Case图来。     图1 原宠物商店UseCase汇总图   为了支持“在线预约”这种特殊的产品，它会影响到大部分的Use Case，具体列举如下：   商品信息需要增加“预约时间”这个属性，客户在下订单时会把它作为标识一个预约的关键要素。 “在线预约”是个虚拟的商品，它可不需要真的需要去检货和包装发货，如果真的那么做啦，我就太傻了。 每个宠物医院每天都只能接受一定数量的预约，从这个概念上来说，它与实物商品有类似的库存概念。可是我该怎么去表达它们呢？ 最要命的是：我真的要把这些所有受影响的Use Case都翻出来去让它们支持虚拟物品的业务吗？我怎么可能在2个月内完成这些重构？   [...]

[转载]工作流在多组织架构下费用报销的应用 – zdming – 博客园. 由于以前是各事业部有各自的报销流程，虽然整合在同一系统中，但其实是不同的流程，如集团报销流程、各事业部报销流程等，造成这一情况的原因是：公司分布 地域比较广泛，组织机构庞大，如：总公司下有集团财务，总公司除财务还有信息，公共事务等部门；各事业部有事业部财务，各事业部还有其他职能部门；各区域 有区域财务，另区域下设有区域办，同时管理所辖门店；另外加一个大型物流中心。所以，目前公司需要整合以前的费用报销流程，使之规范化。 按上述描述分析，以前在进行费用报销时，完全是按照行政组织进行路由。这种组织架构，在只有一个财务管理中心直管全司的情况下，完全没有问题。但是，根据公司目前实际情况，那么必须对组织构架模型进行扩展。 具体是想引入工作流引擎，在同一流程中实现不同组织下的费用报销。因为目前公司组织机构比较复杂，不同的组织，财务管理中心也不一样。各事业部财务管理下辖机构所有财务业务，最后信息汇报到集团财务归档。 所以在系统中，将会引入辅助组织架构（虚拟组织架构），即：财务线（财务类型组织）的财务组织架构、人事线（人力资源类型组织）的人力资源组织架构等。一 个辅助组织必须与一个主组织（行政组织架构）关联，一个主组织可关联多个辅助组织，但同一类型辅助组织，只允许关联一个。 部分表组织如下 完成组织架构模块改造，下一步就是改造工作流引擎。 工作流引擎相对来说变动会比较少，主要的变化点在人员路由模块。可查看此文章，1.2.3、设置处理者。 在此模块中，加入可按组织机构类型寻找用户。如组织类型设置为财务组织，处理者设置为报销会计，那么当流程行进到此节点，就会寻找提交人所处组织设置的财务组织，如果本级组织中没有进行设置，那么将到上级组织中寻找，直接找到为止。 这样，在不同的组织设置不同的财务组织，在用户进行费用报销时，系统就会自动找到财务中心。 优点：系统配置灵活，可随时更换不同财务中心。统一流程，便于管理，以往相同流程在系统中可能需要设置多个，除费用报销外，另一个常见的就是请假流程，需要不同的人力资源部进行备案归档，按此方案，只需要一个流程，不需要写任务代码就可以完成。 缺点：组织架构初始化工作量。 节点处理者部分结构 以上是我在多组织架构下费用报销流程大概的做法，目前流程运行比较顺畅。