跳转至内容
  • 版块
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • 默认(Flatly)
  • 不使用皮肤
折叠

Odoo 中文社区

G

george_sze

@george_sze
关于
帖子
9
主题
3
群组
0
粉丝
0
关注
0

帖子

最新 最佳 有争议的

  • OpenERP的MRP运算的核心对象--Procurement Order
    G george_sze

    看了8.0后怎么感觉完全不一样了。。。找不到supply method,取代的是Supply Chain Information?
    product里不选router就表示是MTS?
    但是需求单里又有2个地方Preferred Routes和rule。这个rule就是supply rule?真有点搞晕了。。。。

    [quote author=digitalsatori link=topic=2923.msg11246#msg11246 date=1338769425]
    需求的来源和转化
    ==========

    我们在上回介绍了需求单运行时如何因为产品的Supply Method(供应方式)的不同而转化为不同的业务单据(生产单,采购单)以满足Proc所代表的需求,以及如何自动定时来运算需求。如果我们还做了上回介绍中提到的一个试验,那么还会进一步了解到如果产品类型为Service(服务),Supply Mechod(供应方式)为生产的产品所对应的Proc会转化为任务单。这个理解起来也是顺理成章:任务单用以满足对服务的需求。产品类型中还有一个被称为Consumable的,这类产品实际上不会产生需求转化,不参与需求运算。可以简单理解为这种产品有无限库存,随需随取,无需生成采购/生产等单据来满足需求,一般用以定义那些低值易耗的原料,比如生产中需要的螺丝,我们会定期采购大量的螺丝而无需根据生产需求来计算其用量。其实说到这里我们就感受到了需求的来源这个话题,也能基本回答上一回中为什么对以Supply Method为生产的产品运行其相关Proc会在生成生产单的同时又生成了大量与此生产单相关的Proc. 这是因为生产过程会产生对原料的需求,也就是说生产就是一个需求的来源。可是,我们在上回的最后问的是:"需求的最终来源是什么?生产是一个需求的来源,可是生产的目的最终还是用来满足客户的需求。所以,客户的需求是需求的最终来源,在OpenERP里就是销售订单。销售订单的确认即会生成需求单Proc.

    再来看看需求类型的问题。其实对于类型的划分按照不同的标准划分就有不同的答案。我这里所想要涉及的Proc的类型划分是在产品定义和Proc定义上都出现的一个字段:Procurement Method. 这里有两个可选项:Make To Order(MTO) 和 Make To Stock(MTS)。我们一般将之翻译为"面向订单的生产"/"面向库存的生产",其实这个翻译不够准确,Make在这里不仅是生产的意思。我们也看到了在前几回的Proc介绍中MTO类型的Proc会转化为采购单而与生产无关。我个人将OpenERP中的MTO理解为"直接需求",MTS理解为"间接需求"或"面向库存的需求" 或 "计划性需求"。那么她们之间到底有什么不同呢?

    这里是关键点:[b]MTO能通过运行处理直接生成其他的业务单据(比如:采购单,生产单,任务单)[/b],这在之前的操作中已经了解。[b]而MTS则比较特殊,他本身不会生成其他业务单据,但是它的存在可能会导致其他的MTO类型的Proc的产生[/b]. 我们这就通过创建一个销售订单来证实:销售订单是否会生成需求单,MTS类型的需求单是否"有可能"导致其它MTO类型的需求单的生成:

    用以下内容创建一张销售订单:
    客户:            China Export
    订单行:
    订单行1-      产品:PC1        数量:10,    Procurement Method: [b]MTO[/b]
    订单行2-      产品:Keyboard    数量:30,    Procurement Method:[b]MTS[/b]
    [b]注:Procurement Method 在订单行窗口的Extra Info页中,其默认值来自于产品表单上的Procurement Method的设定,这里注意将PC1从默认的MTS改为MTO[/b]

    [attachimg=1]

    [attachimg=2]

    好了我们的客户同时订了两个不同的产品,我们也为其定义了不同的需求类型,记住订单号:SO014, 然后确认订单。然后到Procurement Exception菜单项这里,点击Clear以清除默认的过滤条件,然后在Source Document中输入SO014,查询与SO014订单相关的Proc:

    [attachimg=3]

    的确,当订单确认后两个订单行分别生成了相应的Proc,其上的产品,数量,Procurement Method都与订单行一致。如果我们运行这些Proc会怎么样呢?on order(MTO)类型的Proc我们已经做过试验,不出意外的话,会生成一张生产单,和一些生产所需原料的需求单。而from stock(MTS)类型的Proc还不知道会如何反应。点击"Compute Scheduler",在弹出窗口中再点击"Compute Schedulers"。然后返回Procurement Exception菜单项,仍然查询SO014相关的Proc:

    [attachimg=4]

    会发现的确如前预料,PC1相关的MTO类型的Proc运行后生成了生产单MO/00011,而该生产单又生成了大量的以SO0014:MO/0011为源单据的需求单(绿色框所示)。可是,但是,可但是,我们from stock的Proc却坚决的毫不犹豫的又给了我们一个Exception.  其错误原因倒也写得详细:"库存不足,未定义最小库存规则" 。从这个错误似乎能推出OpenERP对 这个MTS类型的Proc的处理过程:面向库存的需求,当然首先检查库存是否能满足本需求的要求,当库存不足时产生Exception,同时其又似乎尝试做库存补货的操作以使库存量能满足Proc,但是这里又碰到了没有设置补货规则(最小库存规则)的问题。

    如果大家还记得第二回中的内容,我们提到过"最小库存规则"这个说法。这里要提醒一点:我们这里讨论的Proc话题基于的是目前最新的OpenERP V6.1 发行版本,V6.0x及以下的版本最小库存的设定在Warehouse-Configuration-Automatic Procurement-Minimum Stock Rule, 而不会如6.1这样在产品定义界面中出现。我们这就为Keyboard设置最小库存规则:

    [attachimg=5]

    这里的我们对仓库为:Your Company, Stock Location(存货地点)为:Stock设置了最小订货规则。这里的Minimun Quantity和Maximun Quantity的意思是:当库存数量不足10个时,该规则要求补货至最大库存量,即100个。所以Minimun Quantity是前提条件,而最大库存量是计算实际补货需求量的基础。由此我们可以推测出:库存规则的设定,就会衍化出物料需求。根据我们之前强调的“哪里有物料需求哪里就有需求单”的口诀,当这个库存规则条件满足(Minimum Quantity),就会产生物料需求,从而会产生需求单。再来"Compute Schedulers",然后再来搜索SO0014相关的Proc。

    发现那个from stock(MTS)类型的Proc仍然是Exception状态,但是仅仅是库存不足的错误提示,而没有了之前未设置库存规则的抱怨了。可是在列表中没有发现有新生成的需求单。其实,新的需求单已经悄然生成,只是不再与SO014这个销售订单有任何直接关系,所以你无法通过源单据为SO014来过滤该Proc. 我们换为查找产品为"Keyboard"的所有Proc:

    [attachimg=6]

    你会发现一个源单据为OP/00013 的Proc而其需求类型为MTO。这证实了我们之前所说:"MTS类型的需求单本身不会生成其他业务单据,但是它的存在可能会导致其他的MTO类型的Proc的产生." 再来注意一下源单据号,这里的OP代表Order Point, 看来这个需求单的确是因为激发了库存规则(即Order Point)而产生的。至此,我们了解了产品设置界面上:Product Type, Procurement Method,Supply Method, Minmun Stock Rule 之间的关系和对Proc的影响,以及需求的终极来源为销售订单,销售订单的确认导致需求的确认,每个订单行会生成对应的Proc 。

    我们接下来还需要了解需求产生的数量,地点,时间,它们在Proc上的反映,以及OpenERP对它们的处理。而要讲清楚这些问题,我们首先必须理解OpenERP的一个独特设计:复式库存计算, 敬请期待。
    [/quote]


  • 系统上线之前如何清空业务数据
    G george_sze

    登录的时候没有找到选择数据库的地方,是不是因为装了ecommerce模块就看不到了?

    [quote author=卓忆 link=topic=16680.msg29257#msg29257 date=1414893571]
    第一个问题:
    你都设置好之后,备份一下数据库,
    以后要清空 数据 就恢复一下 这个 备份过的数据库(恢复的时候可以改名)

    第二个问题:
    一个odoo 本身就支持多个数据库的,
    登录的时候可以选择。
    [/quote]


  • 系统上线之前如何清空业务数据
    G george_sze

    比如同一套配置,如何弄两套数据库?
    只能是两个完全独立的OE目录?


  • 系统上线之前如何清空业务数据
    G george_sze

    系统上线之前如何清空业务数据。
    保留配置和代码,只清空业务数据,比如订单 库存 发票等


  • 如何计算移动平均价
    G george_sze

    试了下采购和销售模块,可用性还是很不错的
    销售定价方面比较弱,没有condition控制。如果能有个定价策略的framework,然后自行创建各种RULE就好了。

    另外想做个demo,但是不熟悉系统代码找不到头绪求帮助。
    比如某产品A 是通过采购入库,但是每批次的采购价格不同(先不考虑condition而直接是手输入采购价格)
    如何把这个移动平均价计算出来,并显示在订单上?  我应该去哪里写代码?

    PS: 移动平均价=交易时点总库存价值/总库存数量 =(交易前总库存价值+或-本次交易)/ (交易前总库存数量+或-本次交易数量)


  • 【已解决】加了一个e-commerence的模块,然后就无法登陆了。求助
    G george_sze

    自己解决了
    打开pgadmin.exe 后找到res_user 表,右键view data。然后自己改一个账号密码
    active表示激活的账号


  • 【已解决】加了一个e-commerence的模块,然后就无法登陆了。求助
    G george_sze

    我在用openerp的时候加了一个e-commerence的模块,然后就无法登陆了
    主页上有login ,忘记当初建db时候的密码了。
    密码的话在哪里可以重置么?或者pg数据库哪个表可以查看到?


  • GreenOpenERP -- 绿色版 OpenERP for windows/linux , 源码运行 解压即用
    G george_sze

    WIN7 64位可以使用,但是pgadmin 里的默认服务器要密码才能登录。
    试过openpgpwd / admin 无效


  • 记录学习openerp:设置员工和薪资
    G george_sze

    OE 有工资回算功能么?

  • 登录

  • 没有帐号? 注册

  • 登录或注册以进行搜索。
  • 第一个帖子
    最后一个帖子
0
  • 版块
  • 标签
  • 热门
  • 用户
  • 群组