Odoo 中文社区

是的。

经测试可以automated action 中写这样的Python语句对新创建或变更的资料进行有效性检查，实现自定义validation的功能！
这个Warning是界面文档上没有提到的可用内部异常变量！

if object.name == '33':
  raise Warning('validation fail')

p.s
要是能再整合业务规则BRM之类的就更好了。

因为是在users表里增加了栏位，新模块加载未安装前可能会报用户表里的新栏位不存在的错误，这时可以直接在数据库里先手工增加这些栏位就可以了。

SAP中有个SQL跟踪的功能对开发很有帮助，在Odoo中虽然可以启用SQL调试参数或者在数据库配置文件中启用SQL语句日志功能，但这些功能要么不能按用户帐号，模块或数据表（model)过滤，不是很方便。
参考OCA中的connector项目，做了一个简单的SQL trace 模块，贴出来分享一下。
[b]init.py[/b]

import sqltrace
import sqltrace_hook
import res_users

[b]openerp.py[/b]

{
    'name': 'SQL trace',
    'version': '1.0',
    'author': 'xxx',
    'website': '',
    'category': 'xxxx',
    'sequence': 100,
    'summary': 'SQL trace',
    'images': [
            ],
    'depends': [
        'mail',
    ],
    'description': """
    SQL Trace
    """,
    'data': ['res_users_view.xml'
    ],
    'test': [
    ],
    'installable': True,
    'auto_install': False,
    'application': True,
}

[b]sqltrace_hook.py[/b]

from openerp.osv import orm
import datetime


_search_original = orm.BaseModel._search


def _search(self, cr, user, args, offset=0, limit=None, order=None, context=None, count=False, access_rights_uid=None):
    start = datetime.datetime.now()
    result = _search_original(self, cr, user, args, offset, limit, order, context, count, access_rights_uid)
    duration = datetime.datetime.now() - start
    if context:  # make sure context is ready
        sql_trace = context.get("sql_trace", False)  # default no trace
        sql_module = context.get("sql_module", 'Empty')  # in case global context not ready
        sql_model = context.get("sql_model", 'Empty')
        if sql_module == 'Empty':
            check_module = False
        elif not sql_module:    # leave module emtpy to trace all modules
            check_module = True
        else:
            check_module = self._module in sql_module
        if sql_model == 'Empty':
            check_model = False
        elif not sql_model:  # leave model empty to trace all models
            check_model = True
        else:
            check_model = self._name in sql_model
        if sql_trace and check_module and check_model:
            query = self._where_calc(cr, user, args, context=context)
            self._apply_ir_rules(cr, user, query, 'read', context=context)
            order_by = self._generate_order_by(order, query)
            from_clause, where_clause, where_clause_params = query.get_sql()
            where_str = where_clause and (" WHERE %s" % where_clause) or ''
            limit_str = limit and ' limit %d' % limit or ''
            offset_str = offset and ' offset %d' % offset or ''
            query_str = 'SELECT "%s".id FROM ' % self._table + from_clause + where_str + order_by + limit_str + offset_str
            cr.execute("""INSERT INTO sqltrace (module,model,statement,user_id,sql,parameters, result, duration, date_update)
                                VALUES (%s,%s, %s, %s,%s, %s, %s ,%s, (now() at time zone 'UTC'))""",
                                (self._module, self._name, 'select', user, query_str, reduce(lambda x, y: str(x)+' ,'+str(y),
                                where_clause_params or ['']), str(result or ['']), duration.seconds))
    return result
orm.BaseModel._search = _search

[b]sqltrace.py[/b]
from openerp import models, fields, api, _


class SQLTrace(models.Model):
    """ workstation """
    _name = 'sqltrace'
    _description = 'SQL Trace'

    module = fields.Char()
    model = fields.Char()
    statement = fields.Char()
    user_id = fields.Many2one('res.users')
    sql = fields.Text()
    parameters = fields.Text()
    result = fields.Text()
    date_update = fields.Datetime()
    duration = fields.Float()

[b]res_users.py[/b]

from openerp import models, fields, api, _

class res_users(models.Model):
    _inherit = 'res.users'

    context_sql_trace = fields.Boolean('Activate SQL Trace?')
    context_sql_module = fields.Char('Modules for SQL Trace')
    context_sql_model = fields.Char('Models for SQL Trace')

res_users_view.xml
<openerp>
    <data>
        <record model="ir.ui.view" id="sqltrace_user_view">
            <field name="name">sqltrace.user.view.inherit</field>
            <field name="model">res.users</field>
            <field name="inherit_id" ref="base.view_users_form"/>
            <field name="priority" eval="20"/>
            <field name="arch" type="xml">
                <field name="tz" position="after">
                    <group string="SQL Trace" name="SQLTrace">
                        <field name="context_sql_trace"/>
                        <field name="context_sql_module"/>
                        <field name="context_sql_model"/>
                    </group>
                </field>
            </field>
        </record>
    </data>
</openerp>


重点分享
1. 在用户表中增加的栏位以context_开头的话，就会被自动加到全局的context中，有缓存的作用
2. 因为_search会在context可用前被调用，所以需要判断context是否可用
3. 解析SQL语句内容的部分从原models.py中的_search抄过来的

http://www.mindissoftware.com/archive/

很专业，很有深度，

Blog Posts

    12 Nov 2014 » Odoo Product Model

    08 Nov 2014 » Understand Odoo Model Part 2

    07 Nov 2014 » Understand Odoo Model Part 1

    06 Nov 2014 » Understand Odoo Environment

    03 Nov 2014 » Replacing Decorated Methods in Python

    31 Oct 2014 » Guide to Odoo Community Association Quality Tools Part 2

    28 Oct 2014 » Guide to Odoo Community Association Quality Tools Part 1

    25 Oct 2014 » An Example Using boto Amazon MWS Package

    19 Oct 2014 » Guide to boto Amazon MWS Python package

    17 Oct 2014 » How to save and load module configuration in Odoo

    16 Oct 2014 » Odoo Module Configuration Implementation

    11 Oct 2014 » Summary of Amazon Marketplace Web Service

    09 Oct 2014 » Create Odoo 8.0 Ubuntu Docker Image

    15 Sep 2014 » Type, Metaclass, Class, and Instance in Python

    11 Sep 2014 » Run and Debug Odoo using PyCharm in Ubuntu

    09 Sep 2014 » Report an Odoo logging bug in Windows

    08 Sep 2014 » Debug Odoo using PyCharm in Windows

    07 Sep 2014 » Odoo Logging Configuration, Usage and Implementation

    06 Sep 2014 » Python Package and Import

    04 Sep 2014 » Odoo connector events

    02 Sep 2014 » Python Decorator Tutorial

    31 Aug 2014 » Build a new addon in Odoo V8 part 2

    27 Aug 2014 » Build a new addon in Odoo V8 Part 1

    26 Aug 2014 » Script to add a user and set password in Ubuntu

    23 Aug 2014 » Create Odoo V8 Docker image from GitHub source code using shell script

    20 Aug 2014 » Install Odoo nightly build from a Docker image

    19 Aug 2014 » Create Odoo Docker image from GitHub source code

    17 Aug 2014 » Install Odoo V8 in Ubuntu from GitHub source code

潜水好久了，今天分享一个东东，花了老鼻子劲，最终只用了几行代码就搞定的功能。

背景与需求
一个车间的生产订单看板系统，各个大的工作站要用大屏幕显示本工作站及前后工作站相关工单的状态（每个工作站工单分为等待，在制与已完成），用文字显示如下
        前一个工作站                              本工作站                    下一个工作站
等待        在制    已完成              等待        在制    已完成      等待        在制    已完成

问题是这些电子显示屏上的工单状态会因为在其它操作电脑上进行的工单状态变更而需要自动刷新

解决方案（过程）
1.首先想到了action里的auto_refresh参数，经实验不起作用，再经进一步google，以及代码检查（现有web里的代码只有定义这个参数，没有使用这个参数的地方），发现该选项根本就是用于之前GUI界面，并且只针对form视图
2.后来想到可以使用浏览器或插件实现自动刷新，试了firefox的reload every，经实验，其它网页可自动刷新，odoo的界面，特别是看板视图--不行
3.最后想到是否可以在界面上做一个定时的长轮询，不过想想也不靠谱，因为定时去服务器检查有没有更新的内容，工作站多了，时间间隔短的话，会大量消耗服务器的资源。效果不理想

最终解决方案
后来发现Odoo本身已实现了实时消息机制（里面有一个bus模块)，另外在年度大会上有一个anybox的公司也基于socketio整了一个实时推送的模块。找到了感觉，最后的方案主要思路应该就是
1. 在服务器端（Python)，在工单变更（新增，变更或删除）时，产生一个资料变更通知（事件），并利用现成的bus，发送给指定(直接取表名）的频道（chanel)
2. 在网页端，监听该频道的事件，判断当前视图是否为kanban,并取得当前的kanban对象，调用其do_reload方法，实现刷新（因为从来没写过javascript程序，如何取得当前kanban视图对象成了最大的拦路虎，好在有firebug，可以在启用调试模式并打开当前看板视图的情况下，在firebug里通过研究整个DOM对象树，最后总算搞成了！）

实际的代码（有点简陋，但经初步测试可以达到要求，贴出来一方面是分享，另一方面还希望得到高手的指点）
在此之前安装了一个anybox公司在bitbucket代码管理网站上的web_notification模块（主要是增加官方的bus模块).

后台Python
@api.model
    def create(self,vals, context=None):
        res = super(kanban_OrderTracking, self).create(vals)
        bus = self.env['bus.bus']
        message = {
            'subject': 'ordertracking',
            'body': 'ordertracking created',
            'mode': 'notify',
        }
        bus.sendone('ordertracking', message) 
        return res

前端JS
(function() {
    openerp.web.WebClient.include({
        declare_bus_channel: function() {
            this._super();
            var self = this,
                channel = 'ordertracking';
            this.bus_on(channel, function(message) {               
                if (this.action_manager.inner_widget.active_view == "kanban") {
                    this.action_manager.inner_widget.views["kanban"].controller.do_reload();                   
                }
            });
            this.add_bus_channel(channel);
        },
    });
})();

另外，该分享也在官方论坛里有，https://www.odoo.com/forum/help-1/question/how-to-auto-refresh-kanban-view-67582

有感于新odoo的论坛，文档管理，邮件等含大量文本内容的搜索标准功能中只能用SQL中的Like加通配符% ，也就是说只能模糊查询特定字符串，而不能真正像搜索引擎那样用时搜索多个关键字。幸好7.0版本中有个全文检索的模块。下载下来经过一番折腾，终于在绿色版的8.0上装上了，也基本能用了，现分享一些心得，也提出一些改善需求
要改2个文件，3 个地方
1 fts_base下的_openerp_.ini
里的update_xml 改为data, 变这样 'data': ["fts_proxy.xml", 'wizard/fts_config.xml'],

2.fts_base.py
2.1 因为pool里没有DB属性了，第40行 去掉.DB, 变成这样        cr = self.pool.cursor()
2.2 因为使用to_tsquery时如果输入多个关键字其中有空格的话，系统会报错，查询字符串不会法， 改为 plainto_tsquery就可以了(fts_proxy里也要改）

除了fts_base，我还安装了fts_document,fts_mail,装上后要重启系统，就会在setting configure 下多一个full text 的配置菜单，点那个对应的生成索引按钮，等一会儿后在对应的ir_attachment，mail_message表里面会增加一个存放索引字串的栏位，一个对应的索引和触发器，就可以去message旁边那个full text search顶层菜单上搜索已启用全文搜索功能的内容了（正如FTS文档所说，可以将实现跨模块统一全文检索，类似ERP内的google)。

昨晚折腾了很久，终于初步将此全文检索功能扩展到论坛模块，也就是直接在论坛模块就可实现全文搜索问题，答案及评论。
主要的思路及做法如下
1.继承fts_base,在forum_post表上增加全文检索栏位
class Fts_Forum(fts_base):
    _model = 'forum.post'
    _indexed_column = 'content'
    _title_column = 'name'
2.继承forum post,扩展search函数，获取搜索文本，参考fts base直接使用全文检索的SQL语句取得ID清单，
特别的地方有两个，
    1.是默认情况下因为传到search函数中的filter已经有parent_id = blank的内容（此类记录表示是回复answer）,需要去掉这种条件，不然就搜不到答案里的内容，
    2.论坛的评论comment并不保存在forum_post表里，而是保存在mail_message里的，所以在search函数中如果要同时搜索评论，还要去mail_message表中全文检索一下，再合并。
代码即文档，见附件


目前的问题
1. 索引不支持中文，在windows 7上还不知道怎么安装zhparser
2. fts base的全文检索出来的清单不支持双击跳转到显示对应的resource，如文档，邮件或论坛
3. 还需要增加对问题标题及邮件主题的全文检索
4. 其实可以考虑做成通用的全文检索，增加ORM定义时一个全文检索栏位属性，最终实现在定义search view时可以使用全文检索栏位，ORM可以自动转换为对应的全文检索SQL语句，用这样的方式使全文检索变成ORM的一部分。

注，本人非专职程序员，大家多提意见，多交流。

对于在线帮助，内容上最好能够介绍有哪些资料校验逻辑，哪些关键栏位信息被自动处理了，数据都保存到哪里去了，会自动触哪些工作流等，另外最好内容允许用户能够修改，就像WIKI一样。
个人觉得ERP的在线帮助往往是很重要的一环。

最近几天在网上在线runbot trunck试了一下新版本7.0,销售订单创建为主，有以下几点测试发现
1.在销售订单创建时，增加很多行时，在[b]订单行界面上缺少以下实用功能[/b]
  按行号，物料号等进行定位的功能，
  从已存在行直接复制的功能
  直接由文本文件或excel复制整行粘贴功能
2.简化后的全局搜索功能只支持订单头，而不支持订单行，如按物料号，物料描述等，往往对订单的查询更多地是按具体的订单行里的信息进行检索
3.订单的[b]输出列表[/b]只有订单头的信息，而没有将订单头与订单行合并在一起，需要具体进入每张订单去查明细，很不方便，更重要的是输出列表不支持在线变更栏位是否显示，过滤，增加栏位等功能
4.没有程序在线帮助功能
5.快捷方式只支持在程序层级，而不支持具体单据

总之，新版本确实更清爽更简洁，但是作为完

procurement order可以翻成需求單，procurement type翻成需求類別似乎不妥。

看了老肖的新貼子后，覺得將Procurement 譯為補貨應該比獲取貼切一點，當然補貨會與另一個專門的補貨replenish會混淆，不過在OE的文檔里好像沒有用那個詞，所以建議就用補貨吧。

好像我也很適合的。

庫位                        產品
物理庫位->OPENERP->存貨      -20 輛自行車
夥伴庫位->客戶->歐洲客戶 +20 輛自行車 
已改。

將procurement 改為獲取的修改量比較大，需要一點時間。
另外庫位改為存貨位置還要再考慮下。

希望大家[color=blue][b]再[/b][/color]多提寶貴意見，我會爭取持續完善，希望本人的此份處女作能夠成為一個真正能用的東西。

修改版-續4

20.8 排程
主生產計畫,有時也叫MPS(Master Production Schedule主生產排程),用來對收到及發出物料產生預測.
注:MPS,供應與生產
OPENERP區分生產,採購與供應.
生產是指製造,採購是指從另一方取得貨物,而供應則包括以上兩者.因此最好是將MPS叫做Master Procurement Schedule主供應排程,OPENERP就是這樣做的.
提示:產品交易
也稱生產計畫.此工具對大生產性交易產品也非常有用.也可以用它進行採購和生產相關的庫存管理.
要使用生產計畫功能,必須安裝 庫存_計畫模塊

20.8.1 銷售預測
要進行生產計畫,首先要定義庫存管理的周期,有些公司作日計畫,有些則是周或月計畫.
提示:庫存管理間隔
在生產計畫中管理庫存的間隔時間之選擇取決于需多長時間完成一個生產循環.一般會有日,周,月等情況.如果需要幾天時間組裝產品,極有可能定義一個周計畫.如果一次製造循環要花幾個月,那么就可以定一個月計畫.

進到菜單 銷售->配置->庫存與銷售期間->庫存與銷售期間.接下來會跳出一個窗口允許自動定義用於庫存管理的下個期間.

圖20.26:定義庫存管理期間
上述定義之後銷售人員可以使用菜單 銷售->銷售預測->銷售預測 按產品與期間錄入銷售預測數據.預測可以是數量也可以是金額.對於金額預測OPENERP會基於預計金額自動計算出相應的數量.當然在保存之前可以根據需要對數量進行手工調整.

圖20.27:維護銷售預測以幫助創建主生產計畫

20.8.2 生產計畫
接下來物流經理要計畫每期的收貨(製造與或採購)與出庫(消耗或出貨). 菜單路徑為 倉庫->庫存計畫->主供應排程
OPENERP會為每個期間之產品提供以下信息
  .預估期末存貨. 計算邏輯為上期末存貨(譯者注)-預計出庫+預計入庫
  .已結案記錄: 來自生產與已確認採購
  .本期預計入庫:計算公式:計畫入庫-截止存貨
  .計畫入庫: 由物流經理手工錄入
  .已結案出庫. 包括製造耗用以及出貨給客戶
  .出庫預測.計算公式:計畫出庫- 截止存貨
  .計畫出庫: 由物流經理手工錄入
  .銷售預測: 代表銷售人員所作銷售預測的匯總

圖20.28:主生產排程
物流經理可以基於生產計畫中的入庫及出庫預測來分析其相關產品未來庫存的影響.生產計畫檢查并確保特定產品的庫存不會低于設定的庫存水平.
也可以開啟以前期間的生產計畫.這種情況下OPENERP是在預估報表中按期間顯示實際庫存移動明細.
如果尚未為產品定義自動供應規則,可以在任意時間基於生產計畫中的預測啟動供應. 與此相關的操作方法是在主供應排程畫面點擊 未達入庫供應. OPENERP按預測的金額對供應進行計畫.

20.9 管理批次與可追溯性
OPENERP的複式記帳使可以作很高級的追溯性分析.所有的操作都被以庫存移動的形式記錄下來了,因此可以很容易地找出庫存移動中產生偏差的原因.
注:向上及向下追溯
向上追溯是指由從供應商處接收的原材料循移動鏈直至產成品出貨給客戶.(請注意此處的名稱有點易混淆-有時這種情況也被認為是向下追溯. 可以將此理解為什麽地地方使用了它- 被使用了)
向下追溯以另外一個方向跟蹤產品,是從客戶到各個不同的原材料供應商.( 請注意此處的名稱有點易混淆-有時這種情況也被認為是向上追溯. 可以將此理解為什麽地地方供應了它)

20.9.1 庫存移動
使用菜單 倉庫->追溯->庫存移動 可以追蹤一個產品或特定庫位的過去的庫存交易.可以使用各種欄位進行過濾以找出產品相關的訂單,生產活動或源庫位及目標庫位.

圖20.29:庫存移動歷史
每次庫存移動均有特定的狀態,各種可能的狀態如下
  .草稿:此類移動在系統內還未有實際作用.此交易尚未被確認
  .已確認:移動即將完成,因此它會被計算到預期存貨里,因為已為移動相關產品作了預留,你不知道它是否會被正常處理完成.(譯者注,此處有點繞)
  .已驗證:此移動即將完成且此交易必須的原物料也已被預留.
  .已完成:庫存移動已完成且被作為實際存貨的一部份
  .等待:在來自訂單的情況下,此狀態意味著庫存移動因等待其它移動的結束被暫停.
  .已取消:庫存移動沒有執行,因此實際庫存與預期庫存都不會考慮它.
出貨單,產品收貨及內部分揀清單都只是對有相類似屬性庫存移動進行分組的單據,也可以使用菜單 倉庫->追溯->包裝 來看看這些單據的歷史記錄.

20.9.2 批號
OPENERP也可以管理批號,有以下兩類批號
  .生產批次(批號)適用于離開相同生產區域的獨特產品或由相同產品組裝而成的組裝件.它們通常由貼在產品上的條形碼進行標識,批號可以是供應商號碼或公司號碼.
  .追蹤號:是邏輯批次用以識別包含一組產品的容器.相關的實際應用案例,如放有許多不同產品的棧板上的棧板號.
這些批號可用於所有庫存移動,特別是貨運入庫,內部移動以及出貨.

圖20.30:輸入產品收貨行
在操作中輸入批號時,要么使用現有批號或創建一個新批號.生產批號(批號)用於單個產品.追蹤號可以不同產品上使用多次,因此可以在一個棧板上或盒子里混合不同的產品.
注:簡化視圖
在簡化視圖模式下,看不到追蹤號:該欄位被隱藏了.要使用擴展視圖模式,請將 可用性-擴展視圖 用戶組分派給當前用戶.
也可以在產品表單上指定哪些操作中批號是必輸的.這樣就可以強制用戶為製造操作,收貨以及出貨包裝輸入批號了.
不需要為一組不同的產品一個一個地編唯一的批號.只需要選定包含許多新產品的移動單,然後點擊產品批號拆分按鈕.接下來給定一個前綴(如果需要),OPENERP會啟動一個嚮導在前綴基礎上添加一個序列號生成一個完整的批號.此序列號可能就對應于一組預先打印好已貼在每個產品上的條形碼.

圖20.31:批號拆分

20.9.3 追溯
如果如上所述為庫存移動輸入了批號,就可以針對特定的批號作追溯了. 相關菜單為 倉庫->追溯->生產批號,或 倉庫->追溯->包裝
提示:產品捷徑
從產品表單,右邊的工具條提供了以下有用信息
  . 最小庫存規則
  . 各庫位存貨
  . 產品銷售
  . 物料清單

可以使用批號,日期或產品等過濾條件搜尋一個特定的批號.一旦看到此批號的表單, 在表單上可執行以下動作
  . 向上追溯:從供應商直至客戶
  . 向下追溯:從客戶到供應商
  . 在所有物理及虛擬庫位中的存貨

圖20.32:面向訂單生產之向上追溯

圖20.33:面向庫存生產之向下追溯

20.10 按憑證簿管理
可以像按憑證簿管理會計一樣通過憑證簿來管理庫存.此方式最大的優勢是可以用不同的方式定義憑證簿以滿足公司的需求.
例如,一個大公司可能希望按部門或倉庫組織其出貨.那麼可以為每個部門創建一個憑證簿和分派一名經理.對應于其在公司內的職務不同的用戶可以使用相應的憑證簿.這種方式可以更好地組織信息.
有大量運輸業務的公司可以按運貨車輛組織其憑證簿.那麼不同的運輸訂單就可以被分派給代表運貨車輛的憑證簿.當車輛離開公司時,就可以將此憑證簿中所有的運單一并進行確認.

20.10.1 各種憑證簿
激活銷售管理的發票憑證簿重配置選項或安裝銷售_憑證簿模塊就可以使用各種不同的憑證簿了.在OPENERP中有3個與此有關的新概念
  .發票憑證簿
  .訂單憑證簿
  .出貨憑證簿
發票憑證簿(銷售->配置->銷售->發票類別)用於分派採購訂單和/或出貨訂單給指定的發票憑證簿.可以對憑證簿中的任何事項進行一次性開票并且可以按憑證簿控制開票金額.例如可以創建如下憑證簿:每日發票,周末發票和每月發票.也可以在夥伴表單中默認顯示發票憑證簿. 根據需求,可以設定開票方式為集中開票(一客戶一發票)或單獨開票(單獨發票).
訂單憑證簿看起來像訂單,它會自動將記錄于其中的內容自動地轉換到對應的訂單中.這種功能讓可以按各種方式對訂單進行分類,比如按部門,按銷售員或者按類別.一個銷售員可以使用自己的憑證簿從所有她負責的訂單中篩選出該憑證簿中的訂單以輕鬆了解對應訂單需要進行的工作.
提示:默認值
要在其自己的憑證簿中錄入所有的訂單,銷售人員可以使用創建訂單時設定的欄位默認值.
最后的出貨憑證簿.用於將每個項次過帳到一個出貨憑證簿.例如可以按出貨日期創建相應憑證簿(如星期一出貨,下午出貨)或這些憑證簿代表出貨車輛(如卡車1,卡車2)一天的出貨.

20.10.2 使用憑證簿
接下來會講解如何在實際工作中使用憑證簿來進行庫存管理工作.安裝銷售_憑證簿模塊后,請先看看夥伴清單.在每個夥伴的銷售與採購子頁面里有個特別的開票方式欄位

圖20.34:夥伴表單中的開票方式
可以在此為一個夥伴創建一個新的發票憑證簿.可以決定在憑證簿中生成發票之後是單獨開票還是合并一起開票.創建第二個發票憑證簿 月底發票 ,可將其分派給另一個夥伴.

圖20.35:定義一個發票憑證簿
請再為此兩個夥伴的一些訂單輸入一些數據.輸入完訂單數據后,夥伴表單中的開票方式欄位內容會自動帶到訂單中來.
請再來看看銷售訂單 歷史 子頁面中已創建的裝箱清單. .系統已自動顯示開票方式信息.請確認此清單中各個不同的訂單.
在每天下班前,主管開票的人可以按憑證簿顯示一份清單. 進到菜單 銷售->發票->發票行. 選擇發票憑證簿,這時系統會將所有待開票訂單在一個清單中顯示出來.可以點擊 生成發票按鈕(畫面上齒輪狀圖標)以自動執行開票動作.
提示:確認發票
默認情況下,生成的發票只是草稿狀態,以便在將發票發送給客戶前可以進行修改.當然也可以從清單中選擇所有發票并選擇 確認草稿發票 進行一次性確認.
在月底發票管理做的是同樣的工作,只不過是在月底發票憑證簿中罷了.
也可以錄入憑證簿以一次性確認或取消所有訂單.同樣也可以進行多個報價并將它們分派給一個憑證簿,再一次性確認或取消它們.

圖20.36 訂單憑證簿視圖
20.11 庫存管理的高級元素
在此部份我們講解以下庫存管理與控制細節
20.11.1 需求計算/排程
需求計算是指計算引擎根據為產品定義的規則對產品進行計畫,排定優先級以及啟動自動供應.
注:需求計算
需求計算常常被叫做排程
需求計算默認每天自動執行一次,也可以通過菜單 製造->排程->計算排程手動執行它. 需求計算利用在產品,供應商以及公司中定義的參數決定各種不同的產品訂單,出貨以及採購的優先順序.

20.11.2 及時生產
排程默認每天自動執行一次.應該將此執行安排在晚上很少有人使用系統的時候以避免排程運算影響系統的性能.可以通過菜單 管理->配置->排程->排程動作 設定排程的開始時間.選擇被稱作 運行MRP排程 的規則并修改其下次執行的日期與時間.有些公司希望不斷地對錄入的訂單進行計畫而不是等到下一天產生供應訂單.模塊MRP_及時生產就是做這個工作的.安裝好此模塊后,在每個需求(會產生生產或採購訂單)被確認后系統就會進行實時的計畫.
如果錄入了一個面向訂單生產產品的銷售訂單后,系統會立即產生一個對供應商的報價請求.
提示:自供應商出貨
Sale_supplier_direct_delivery(基於供應商直接出貨的銷售,有的系統也稱此為第三方交貨)模塊允許供應商直接交產品交給客戶.在撰寫本文時此模塊尚在addons_extra(外掛模塊:其它)中.產品遵循為其單獨配置的邏輯且只影響被標記為面向訂單生產的產品.
此模式不是任何時候都有實際意義.每個訂單會在被確認之時立即得以處理.因此如果一個訂單將在3個月后出貨,排程會在訂單被確認后為其在存貨中進行預留.這種情況下使相關產品對其它訂單可用應該更為合理.
如果一個採購訂單的發票控制被配置為 來自訂單,排程會立即創建對應的供應商詢價請求.考慮到提前期你可能更傾向于延後幾周以合并未來的訂單進行統一採購.
總結以上,我們可以看出及時生產模塊的一些副作用是
  .訂單間的優先級管理得不好
  .產生多餘的存貨(譯者注:此處不好理解, 根據上文,提前產生了需求?).

20.11.3 計畫
大部分的OPENERP單據可以在計畫視圖中進行變更.對出貨與收貨也一樣.在任何時候都可以將它們放到日曆視圖中以對出貨與收貨進行計畫.

圖20.37 計畫客戶產品出貨
裝箱單上的計畫日期被定義在每個庫存移動行上,如果有一個裝箱單包含許多不一定在同一天出貨的產品.裝箱單中最大與最小日期就對應于裝箱單的庫存移動行之最早與最晚日期
如果在日曆視圖上移動一個裝箱單,庫存移動單行中的計畫日期也會自動變更(移動).

20.11.4 管理部份交貨
部份交貨,有時也稱欠交訂單是由OPENERP自動產生的.當確認一個對客戶的出貨或來自供應商的收貨時,OPENERP會要求確認出貨或收貨數量.
如果不修改建議的數量,OPENERP會確認并完成出貨或收貨有關的訂單.如果修改數量,OPENERP會自動以剩下的數量生成第二張出貨或收貨單.第一張單會被確認,而第二張會處於等待出貨(或收貨)狀態.

圖20.38 出貨數量確認屏幕
在打開當前出貨清單中有個欠交訂單欄位,裏面記錄的是已出貨給客戶的前一張出貨單號, 每天都可以據此快速找出那些部份交貨訂單以便優先處理它們.

20.11.5 供應商產品收貨
OPENERP支持3種方式控制自供應商收貨之數據錄入
  . 手工錄入
  . 使用系統預先生成的收貨單
  . 獨立于收貨單從所有待收產品進行選擇,

在”推動你的採購”章節有更細節的關於採購訂單配置如何影響收貨的內容.

20.11.6 收貨之手工數據錄入
請選擇菜單 倉庫->倉庫管理->進口貨物 點擊新增按鈕 就可以手工錄入收貨信息.

圖20.39:產品收貨之手工數據錄入

20.11.7 確認預生成收貨單
如果使用OPENERP中的採購訂單,在採購訂單確認時系統就會自動生成產品收貨單.而不再需要輸入任何資料,只要確認已訂數量與收貨數量是否一致即可.
通過菜單 倉庫->倉庫管理->進口貨運 會看到OPENERP生成的所有待收貨產品清單,使用恰當的過濾條件,利用按狀態分組等功能就可以找到在特定狀態下的各種待收貨單據.

圖20.40:待收貨清單
接下來可以使用供應商名稱或參考訂單號來定位具體的收貨單.選擇收貨單并確認數量.如果顯示的數量與控制表單中的不一樣,OPENERP會以剩餘數量自動生成另一張待處理的收貨.可暫時不用理會這張生成的收貨,或者如果知道供應商再也不會將短少的數量送貨了,就可以取消生成的收貨單.

20.11.8 通過選待收產品進行確認
上述方式對於收貨與原始訂單相符的情況特別適用.然而,如果供應商送貨時并不必然與訂單一致時,通過選擇產品而不是訂單來進行收貨顯然就容易多了.可通過菜單 倉庫->產品移動 ->接收產品 來手工創建一個新產品收貨.OPENERP會打開供應商的所有待收與已收產品清單,可以自動地添加部份或者全部的產品到收貨單中.可以基於狀態對待收產品進行過濾并進行確認.這種數據錄入方式特別適用于在同一時間針對多個訂單進行收貨.

20.11.9 產品路由
如果希望實現依據產品本身決定自供應商或公司倉庫至客戶的產品路由,應該安裝庫存_庫位模塊.

圖20.41:在產品表單中管理自一個庫位到另一個庫位的移動路徑
產品路由允許為每個產品單獨配置物流規則.比如,當一個特定的產品到達倉庫時,可以自動將其送至待驗(庫位).要實現此功能,必須在產品表單上配置相應規則,規則由以下欄位構成
  .源庫位: 產品來自此庫位
  .目標庫位: 產品被送達此庫位
  .移動類別:自動,手動,自動但無附加步驟
  .移動提前期
  .操作名稱:一個用於由OPENERP自動生成移動單中自由定義的文本.

有以下兩種主要的物料流
  .推式流
  .拉式流
推式流特別適用于產品到達特定庫位后一定會立即或隔幾天后移動到另一個庫位的情況.標準的倉庫管理模塊已經支持在庫位上定義推式流,但不能為單個產品定義推式流.
與推式流不同,拉式流不處理產品移動,它處理的是供應訂單.被拉動的是一個需求,不是直接的產品.
以下將要講解的是在這些庫位間為產品定義的物料流
  .一個租賃產品
  .一個從中國採購,接下來通過港到港海運的產品
  .一個進入為庫房前必須先待驗的產品
案例 1:一個租賃產品
一個租賃產品是指交貨給客戶后,一段時間之後需歸還的產品.當租賃產品出貨給客戶時,OPENERP會以租賃到期日為預計收貨日的一張新收貨單.因此當租賃到期時,只需要對系統內已產生待收產品清單進行確認即可.請按以下方式為產品配置一個規則

表20.11:租賃產品案例
欄位 值
源庫位
目標庫位
移動類別
提前期
操作 客戶
存貨
手動
15天
產品退回
將該產品出貨給客戶時,OPENERP會為產品歸還自動生成的個草稿狀態的收貨單. 此收貨單之到期日是15天之後.基於此系統可以實時地顯示預計存貨以及存貨趨勢圖.

案例 2: 管理海運進口
要管理產品通過海運,再經過海關環節的複雜物流,請為各個步驟建立對應的’供應商’庫位,然後創建庫位間移動規則以對應實際物流過程.
讓我們來拿一個從中國採購并最終進入在比利時布魯塞爾店鋪的案例來看.海運進口需大約7周,期間必須經歷以下步驟
  .從供應商出貨至上海港: 2天
  .從上海海運至安特卫普港:1個月
  .安特卫普港海關:2周
  .從安特卫普港通過卡車運至店鋪:3天
應該在每次產品移動時錄入相關單據以便及時知曉在某一時刻該產品處在什麽位置,以及預計什麽時候會到店鋪.要做到這些,請為這些中間步驟創建以下庫位
  . 上海港
  . 安特卫普港
  . 安特卫普海關
最后,請在產品表單中創建以下規則,規則的意思是當採購產品時,產品不會直接進入店鋪,而是先到上海港.在此案例中我們將店鋪配置為可以接收所有產品稱為來料的庫位
表20.12 將產品自動移動到上海港的規則
欄位 值
源庫位
目標庫位
移動類別
提前期
操作 來料
上海港
自動且無附加步驟
2天
送至上海港
基於上述規則,OPENERP會將本來的普通收貨(收貨至來料庫位)變更為由供應商運送至外部港口,因為如果人工進行此步操作,工作量會太大,所以此處將該移動設定為自動進行的.
接下來,還要在產品表單上創建規則以便將其從一個庫位移到另一個庫位
表20.13 將產品手動從上海港移動到安特卫普港
欄位 值
源庫位
目標庫位
移動類別
提前期
操作 上海港
安特衛普港
手動
30天
海運至安特衛普港
表20.14 將產品手動從安特衛普港移至安特衛普海關
欄位 值
源庫位
目標庫位
移動類別
提前期
操作 安特衛普港
安特衛普海關
手動
15天
安特衛普海關
表20.15手動將產品從安特衛普海關移動至存貨
欄位 值
源庫位
目標庫位
移動類別
提前期
操作 安特衛普海關
存貨
手動
3天
卡車運送至庫房
上述規則配置好后,OPENERP就會自動為產品從一個庫位移動至另一個庫位生成所有必要的單據.系統會根據規則里定義的順序將這些單據先后關聯起來.當公司收到產品抵達某個港口或海關的通知時,就可以確認相關的產品移動.這樣就可以用每個庫位來跟蹤如下的產品存貨信息了
  .特定產品已到哪兒了,
  .待清關的產品數量,
  .產品到店鋪還需多長時間,
  .在各庫位之存貨價值
案例 2: 待驗
可以配置系統以便在產品到達公司時將產品自動送達待檢區. 要實現此功能,只需為產品配置一個從供應商接收產品時將產品送至待驗而不是來料庫位的規則.
表20.16 手動將產品由來料庫位移動至待驗庫位的規則
欄位 值
源庫位
目標庫位
移動類別
提前期
操作 來料
待驗
手動
0天
待驗
當收到此產品時,OPENERP會自動產生一張待手工確認的由來料庫位到待驗庫位的內部移動單.
（庫存管理 部份 完）

修改版-續3

不同的操作,比如收貨與出貨,這極大地簡化了數據錄入的工作量.
可以在客戶庫位與存貨庫位中看到對應的產品清單.這些待收貨清單是由OPENERP基於庫鏈自動生成.
如果希望將產品(PC3)出租給客戶(axelor)30天.需要兩次庫存移動來管理此業務.
1. 產品從存貨庫位(公司的庫位)發出,到 axelor-租賃庫位(客戶庫位)
2. 30天后產品將自axelor-租賃庫位(客戶庫位)歸還到存貨庫位(公司庫位)
要通過庫鏈管理租賃產品,請通過菜單 倉庫-配置-倉庫管理-庫位 如下圖一樣配置一個租賃庫位(axelor-租賃庫位)

圖20.22 配置一個租賃庫位 axelor-租賃庫位
使用菜單 倉庫->追溯->庫存移動,可以創建一個租賃產品(PC3)從存貨(庫位)到客戶庫位(axelor-租賃庫位)的庫存移動記錄.

圖20.23:將產品PC3送至客戶庫位的庫存移動記錄
在之前的移動單上通過點擊 立即處理  按鈕確認后, OPENERP會在適當的計畫日期之後自動生成從客戶庫位移動至存貨庫位移動單.
特定的產品之內部存貨自動移動到待驗庫位也是相同的邏輯.

20.6.3 寄售產品
庫鏈原理也適用于管理寄售產品.可以指定特定產品在出貨給客戶多少天之後需退回來.
產品出貨后,OPENERP會自動為該寄售產品產生收貨單(退回來).很明顯指定的日期只是大概估計的,但是使用它能夠對產品退回進行預測.

20.7 倉庫
倉庫是指可以由此向客戶出貨以及接收原物料的物理庫位.當向供應商購買產品時,需要考慮此採購活動需要使用的倉庫.最終用戶可以選擇實際的倉庫而不是從一個庫位清單中進行選擇.
使用菜單 倉庫->配置->倉庫管理->倉庫,然後點擊新增來配置一個新倉庫
定義一個倉庫時,可設定3個關聯庫位
  .存貨庫位欄位是指從此處有可用庫存,可以直接向客戶出貨,可用的庫存對應該庫位以及其子庫位.
  .收貨庫位是指從供應商處接收的產品收到此處.此庫位可與存貨庫位相同,比如,希望接收的原材料都要待驗
  .出貨庫位:此庫位作為一個緩衝區存放所有已被分揀但尚未發運給客戶的物品強烈建議不要將此庫位放在存貨庫位結構之下,相反要將其置於一個較高層級或同一級.

圖20.24:倉庫參數
可以為倉庫設定一個地址.理想的情況下此地址就是公司的地址.倉庫被定義好以后,它就可以用於
  .最小庫存規則
  .採購訂單
  .銷售訂單(銷售點會關聯一個倉庫)

20.7.1 自動供應
OPENERP可以進行多種方式的產品自動供應
  .針對面向訂單生產產品的工作流
  .針對面向庫存生產產品之最小庫存規則
  .針對面向庫存生產產品之主生產計畫排程
以下詳細說明最后兩種方式
20.7.2 最小庫存規則
可以使用最小庫存規則實現自動補貨建議,為此,請使用菜單 倉庫->自動供應->最小庫存規則.
規則如下:如果指定庫位的預期存貨低于規則中設定的最小存貨量,系統就自動建議一個供應單以增加預期存貨至規則中設定的最大存貨量.

圖20.25:最小庫存規則清單
提示:衝突處理
系統中會有些看似不需要的草稿狀態的生產或供應訂單.如果系統設置得很糟糕就會出現此類情況(比如說,忘了為一個產品設定供應商).要檢查這種異常,請使用菜單 倉庫->排程->供應異常 看看處於異常狀態的供應清單.在制造章節有有關於處理此類異常的更詳細的說明.
在此我們強調的是規則是基於預期存貨而不僅是實際數量.它考慮了對未來訂單與收貨的計算.
來看看以下案例:
.在庫產品:15
  .已訂未出(貨)產品:5
  .在制(造)產品:2
規則為:
  .最小庫存:13
  .最大庫存:25
一旦恰當地配置好了上述規則,採購經理只需要使用菜單 採購->採購管理->請求報價 看看訂單清單以與供應商進行確認.
注:請注意供應并不意味著一定要從供應商處採購,如果一個產品的供應方式是生產,則排程將生成一個製造訂單而不採購訂單.

也可以在最小庫存規則中設定倍數,如果設置的倍數是3,系統會建議供應15(5*3)個而不是實際需要的13(25-[15+2-5])個.在此情況下,系統會自動將數量圓整到了上一個整數.
在最小庫存規則里,可以為一個倉庫指定一個系統默認的庫位,可以在排程結束后可以按庫位而不是倉庫修改此默認庫位.

修改版續-2
--待驗
    --售后服務
    --供應商退貨
    .通過為租賃產品自動生成退貨移動以協助租賃管理.
此模塊安裝后,會在產品表單上出現一個額外的物料流子頁面.在此可以添加推式與拉式流規格(規則).
20.5.1 推式流
推式流特別適用于當特定產品到達一個指定庫位后接下來一定會移動到另一個庫位,可能有幾天的延後.
注:核心的倉庫模塊功能已支持庫位級的推式流,但不能在產品層級定義推式流.
推式流定義哪個庫位與另一個庫位關聯以及相關參數.一旦特定數量的產品移動到源庫位,就會根據流的定義(目標庫位,延遲,移動類別,憑證簿等)自動觸發一個預期的庫位移動.取決于相關參數,新的移動可能被自動處理,或者需人工確認.
假定當產品CPU3進入存貨庫位,它首先要被稱動到待驗庫位進行品質檢查.
讓我們在系統內通過菜單 倉庫->產品->產品 來看看CPU3 這個產品
要讓OPENERP完成上述業務,配置推式流如下
  .操作:收貨到待驗(庫位)
  .源庫位:存貨
  .目標庫位:待驗
  .自動移動:自動但無附加步驟
  .延後(天):1
  .貨運類別:取得商品

圖20.19:產品CPU3的推式流定義(規格)
推式流關係到如何生成庫存移動以增加或減少存貨.

20.5.2 拉式流
拉式流與推式流有些不同,拉式流不是處理產品的移動,而是處理供應訂單.被拉動的是需求而不是產品.
便利店的產品由其每公司負責供應就是一個經典的拉式流的案例.
[客戶]<-A-[便利店]<-B-[母公司]-C-[供應商]
當一個新的供應訂單(A, 比如說來自于對一個銷售訂單的確認)到達便利店,它將其轉換為另一個向其母公司的供應(B, 通過一個’移動’類別的推式流),當母公司處理供應訂單B時,如果已無存貨,就會再轉換成對供應商的採購訂單(C,‘採購類別的推式流).最終的結果是供應訂單,需求,從客戶一路被推動到了供應商.
從技術上來講,拉式流在處理供應訂單時可以因為同時考慮考慮產品以及庫位擁有該產品需求的庫位而有所不同(供應訂單的目標庫位)
要講解產品CPU1的拉式流之前,我們先來通過菜單倉庫->自動供應->最小庫存規則 為CPU1配置最小庫存規則,
對于公司 OPENERP
  .最小數量:10
  .最大數量:50
對于公司商店1:
  .最小數量:10
  .最大數量:20
為了配置拉式流, 我們通過菜單 倉庫->產品->產品 來看看產品CPU1,

圖20.20:產品CPU1的拉式流規格
產品CPU1有兩個拉式流規格
規格1:
  .名稱:自倉庫收貨
  .目標庫位:商店1
  .供應類別:移動
  .公司:商店1
  源庫位:內部運輸
  夥伴地址:OPENERP
  貨運類別:取得商品
  供應類別:面向訂單生產

規格2:
  .名稱:出貨商店
  .目標庫位:內部運輸
  .供應類別:移動
  .公司:OPENERP
  .源庫位:存貨
  .夥伴地址:Fabien
  .貨運類別:發送商品
  .供應類別:面向庫存生產
現在我們來從商店1出售1 個CPU1,再來使用菜單倉庫-排程序器->計算排程 運行排程,最后使用菜單 倉庫->追溯->庫存移動 來查看產品CPU1的庫存移動.

圖20.21:與拉式流相關的產品CPU1的庫存移動
這些移動可被解讀為
[客戶]<-[商店1]-<-內部貨運<-存貨<-[OPENERP]
當商店1賣了1 個CPU1給客戶,其存貨降至10個,根據最小庫存規則,系統自動生成一個需要21個CPU1的供應訂單,根據源庫位與目標庫位的內部配置將會有21個CPU1會從公司OPENERP移動到商店1.
拉式流關係到如何運行供應流程以找到產品來增加或減少存貨.

20.6 進口與出口
有時管理外國公司的進出口會很複雜.在出口港與目的地公司之間,產品可能在海上,在無數轉運階段及海關停留幾個星期,有效地管理此類出貨的以下方面至關重要.
  .知道產品在哪兒
  .知道產品何時會到達其目的地
  .知道在途價值
  .跟進不同階段的狀態
OPENERP中的庫鏈讓可以很優雅地對此進行管理,可以使用如下的庫位結構
.供應商:
    -歐洲供應商
    -中國供應商
  .在途
    -上海港
    -太平洋
    -舊金山港
    -舊金山海關
20.6.1 存貨
在途庫位之間利用手工確認進行彼此間關聯,內部庫存移動是在到達每個港口與海關時被確認的.OPENERP會自動準備好所有這些關聯的移動
注:Intrastat
進行進出口業務的公司需要安裝 report_intrastat模塊,此模塊可以提供一些必須的產品出口申報報表

可以使用不同庫位間的提前期來比較真正的延遲. OPENERP會基於提前期與存貨預測進行計算以估計產品的到達時間.因此可以做到盡可能精准地響應客戶的需求.
也可以基於選定庫位的配置對在途產品進行存貨估價.

20.6.2 租賃庫位
在OPENERP中可以使用基於庫位的系統很輕鬆地管理租賃庫位.使用存貨_庫位模塊,可以為租賃物品設定一個租期到期后的歸還日期,
系統會實時地維護每天的實際與預期存貨.OPENERP會在特定日期之後自動建議

修訂版1 重大修訂說明
1. 勞爾馬克思->化學家拉瓦錫名言
2. 盡量去掉了多余的“你”，”你的“
3. 統一了專門的術語“supplier order"=》採購訂單，customer order=》銷售訂單，goods=>產品，quality control->待驗，procurement->供應（本意為獲取，換個角度就是供應，或許還可以叫做購置）
4. 採用了一些目前界面上的翻譯得比較好的術語，日記帳->憑證簿，乘數->倍數（最小庫存規則裏面）
5.修正了一些不恰當的翻譯，如為簡化起見->舉個簡單的例子
6.還有一些與目前界面上的不太一樣，位置->庫位，積壓訂單->欠交訂單，未來庫存->預期庫存。
管理倉庫, 搞定製造
本書此部份著重關注實際物料-庫存處理以及透過組裝及製造對物料進行轉換.
這里的存貨是指產品規格的實體表現形式,而不僅僅是產品數據清單.存貨需要被存儲,在各庫位之間移動,會被以套或個的方式進行追蹤.它們有尺寸,重量以及成本屬性.Open ERP 使用了一種有效且獨特的方式進行存貨管理.
製造是指將物料以及組件,可能還有一些可計量的資源轉換成其它產品和服務,為公司增加價值.

倉庫
Open ERP的存貨管理看似非常簡單,實則很靈活且功能全面. 它基於帶給會計革命性變化的複式記帳原理.系統的特性可引用著名化學家拉瓦锡的名言” 什么也没有失去，一切都改变了”, 或者”一切皆為移動” 來闡釋 .在Open ERP中不會談論突然不見,產品消耗或遺失:而是說庫存從一個地方移動到了另一個地方.
正如會計記帳,OPENERP同時管理主要業務活動及其對應相關方,如從供應商處收貨,發貨給客戶,來自存貨的收益與損失以及原物料的消耗.庫存移動始終是指庫存由一個庫位移動到另一個庫位.為了確保每次庫存移動都有一個對應相關方,軟件支持以下不同類別的庫存位置(庫位)
物理存貨庫位
夥伴庫位
虛擬庫位如生產及盤點

物理庫位代表倉庫及其層次結構.實際上就是指通常由傳統庫存管理系統管理的庫位.
夥伴庫位代表客戶和供應商的存貨.在與這些夥伴們進行對帳時,這些庫位就扮演了第三方科目的角色.從供應商收貨在系統內就被表示為商品由夥伴庫位移動到了公司的物理庫位. 所以會看到供應商庫位通常都會顯示負庫存而客戶庫位通常顯示為正庫存(數量).
與生產對應的虛擬庫位通常使用在製造流程中.製造的特性是消耗原材料,產出成品.虛擬庫位就用作上述兩個移動的對應相關方.
盤點庫位是公司對存貨進行收益與損失相關操作(譯者注:如盤點,存貨價值重估)的對應相關方.

下圖是系統初始安裝后的庫位層次結構圖

圖20.1 OPENERP 安裝后的初始庫位結構

注:結構化庫位
在OPENERP中,庫位是結構化的.可以將庫位作成基於父子關係的樹狀結構.這樣的組織方式可以對倉庫各種庫存移動及倉庫組織架構進行各種明細層級的分析.
技巧:庫位與倉庫
在OPENERP中倉庫代表物理存貨的實際地理位置,可以將倉庫組織成由多層級庫位組成.庫位是用來管理各種類別的存貨地點,比如說客戶和生產庫位.
本章需要一個全新安裝且帶演示數據的數據庫,并選裝了倉庫管理及其依賴模塊,不需要配置特別的科目表.
20.1 理解複式記帳的存貨管理
為了講解存貨管理的這個概念,我們先來看看以下業務會產生什麽樣的庫存移動,
  從供應商處接收產品
  出貨給客戶
  材料遺失存貨處理
  製造
庫位結構基於系統初始安裝后的庫位層次結構圖,假定還沒有任何存貨,也沒有尚在進行中或計畫了的庫存相關操作.
如果從供應商那裡定購了30輛自行車,在接收了產品后,OPENERP會做以下操作
表20.1 自供應商處收貨后的庫存移動操作
庫位                    產品
伙伴庫位 >供應商        -30 自行車
物理庫位->OPENERP>存貨      +30 自行車

如果將2輛自行車出貨給歐洲的客戶,對應出貨將有以下交易資料

表20.2 出貨給歐洲客戶的庫存移動
庫位                        產品
物理庫位->OPENERP->存貨      -2 輛自行車
夥伴庫位->客戶->歐洲客戶 +2 輛自行車 

當以上兩個作業完成后,可以在每個庫位看到以下庫存數
表20.3 存貨狀態
庫位                            產品
夥伴庫位->供應商                -30 自行車
物理庫位->OPENERP->存貨          +28自行車
夥伴庫位->客戶->歐洲客戶    +2 自行車

至此,可以看到一個產品在所有庫位中的總庫存始終為0. 相當于會計帳中的所有借方與所有貸方相等(譯者注:會計記帳原則有借必有貨,借貸必相等).
夥伴庫位(客戶和供應商)并不歸屬於公司庫位層級結構中,因此在此類庫位中的存貨也就不是公司自有存貨的一部份.因此如果只看公司內部的物理庫位,那兩輛自行車就不再屬於公司了.雖然它們已經不是公司物理存貨,而是存在于客戶庫位里,這樣的信息對于進行詳細的庫存管理分析是十分有用的.
提示: 對于寄售庫存,需要定義對應的客戶或供應商寄售庫位,這些庫位屬於自有存貨的一部份
注:科目
在管理存貨時,往往很難避免在軟件中的存貨數量與倉庫中實際的存貨數量之間不出現偏差.庫存管理使用復式記帳法使得發現差錯的機會增加了一倍.比如說如果忘記了在某庫位中的兩個物料,此種差錯會容易地在該庫位相關的對方庫位中反映出來.

在會計帳中,從一個科目及其相關對方科目的異常現象中可以很容易找出錯帳,比方說如果銀行戶頭(科目)錢少了很可能就是有人忘了將客戶付款事項入帳到銀行科目了. 與此類似, 不論是會計帳還是OPENERP的庫存管理都遵循所有借方與所有貸方相等(譯者注:有借必有貨,借貸必相等)的原則.
在會計帳中,所有憑證都會產生會計分錄,這些分錄就是會計管理的基礎.如果創建發票或對帳單,這些業務活動的結果就是產生對相關科目的會計分錄.在OPENERP中的庫存管理也類似.所有庫存業務活動均作為簡單的庫存移動進行記錄.不管是對物料進行包裝,或製造,抑或是進行庫存盤點,每次都是在進行庫存移動.
前文中已經看到了一個相對簡單的產品收貨與出貨的案例,但是有些庫存業務并不那麼顯而易見-比如說存貨盤點.存貨盤點實質上就是比較系統內記錄的存貨數量與實物存貨真實數量差異的業務活動.在OPENERP中,基於其復式記帳原則,可以使用庫存移動來記錄此類存貨盤點業務.這樣的記帳方式有助管理庫存可追溯性.假設實物存貨有26輛自行車,但是在OPENERP系統內記錄的是28輛,那麼需要將系統內的存貨數量減少為26,這個被減少的2輛將被視為產品減損損失,對系統數據的更正動作會產生以下系統記錄
表20.4 調整存貨的庫存操作
庫位                          產品
物理庫位->OPENERP->存貨            - 2 自行車
虛擬庫位->存貨損失            +2 自行車

與此相關的產品庫存變更以下

表20.5 業務完成后的實際及相關方存貨
庫位                        產品
夥伴庫位->供應商            -30 自行車
物理庫位->OPENERP->存貨          +26 自行車
夥伴庫位->客戶->歐洲客戶    +2 自行車
虛擬庫位->存貨損失          +2 自行車

此案例展示了複式記帳庫存管理模式在績效分析方面的巨大優勢.幾個月以后,可以對庫位 虛擬庫位->存貨損失 作一次存貨估價以了解在特定的期間內公司總的存貨損失情況.
現在讓我們來看看以下製造業務在OPENERP中是如何組織的.要生產1輛自行車,需要兩個輪子與一個車架.這也意味著有兩個輪子與一個車架會從實際存貨中被消耗掉,一輛自行車會被增加到存貨中.消耗與生產以產品移入移出物理庫位的形式在系統內體現.與此相關的存貨業務如下:
表20.6 製造后庫存狀態
庫位                            產品    步驟
虛擬庫位->生產                +2輪子  原材料消耗
物理庫位->OPENERP->存貨            -2 輪子  原材料消耗
虛擬庫位->生產                +1 車架  原材料消耗
物理庫位->OPENERP->存貨              -1 車架  原材料消耗
虛擬庫位->生產                  -1 自行車 成品生產
物理庫位->OPENERP->存貨              +1 自行車 成品生產

至此已得到從消耗原材料到生產出成品的結果.
注:評估已創造價值
或許我們已注意到複式記帳的另一個效用:如果對虛擬庫位->生產 進行一次存貨估價,可以得到公司的已創造價值(是一個負數).對任一指定庫位進行存貨評估的計算公式:在庫產品數量*成本.在本案例中原材料價值要從成品價值中扣減.
20.2 從供應商到客戶
接下來,我們將通過一個比較務實的案例來更進一步講解庫存管理操作.主要包括如何:
 定義一個新產品
 設置初始存貨
 從供應商收貨
 出貨給客戶
 分析存貨狀態

20.2.1 定義一個新產品
首先,讓我們來定義以下產品
表 20.7 產品定義

欄位          值
名稱          中央供熱類型1
編碼          CCT1
產品類型      庫存產品
供應方式      購買

使用菜單 倉庫->產品->產品, 然後點擊新增 來定義一個新產品

圖 20.2:定義一個新產品
定義一個新產品時,以下三個欄位是庫存管理中是很重要的
產品類別
供應方式
供應方式

20.2 產品類別
產品類別用以表明產品是否需要作庫存管理以及OPENERP是否管理如何供應它. 三種產品類別如下
 庫存產品:此類產品需做存貨管理,並且其補貨或多或少是依據定義的規則由系統自動完成的.如:自行車,電腦或者中央供熱系統
 消耗品:這種產品需要進行庫存處理,可以對其進行收貨,出貨甚至生產.然而其存貨水平(量)不是由系統管理的.OPENERP假定在任何時候都有此種產品足夠的存貨,因此它不需要自動補貨.如螺釘.
 服務:它不會出現在各種庫存操作中.如諮詢服務.
供應類別-面向庫存生產和面向訂單生產
供應類別決定了產品如何補貨
  面向庫存生產:從可用庫存中供貨給客戶.在存貨數量太低時補充一定數量的產品(根據最小庫存規則).如:傳統的分銷商
  面向訂單生產:當銷售訂單確認后,通過採購或製造此訂單需要的產品.從一段時間來看,因為只是完全依訂單需求量補充存貨(譯者注:后續訂單會將補充的存貨出貨給客戶),銷售訂單”面向訂單生產”不會變更庫存量.如按需組裝的電腦

在大多數行業里面,對各種不同的最終產品及中間半成品是混合在使用以上兩種模式.產品表單上顯示的供應類別只是提供給訂單一個默認值,銷售人員可以依據實際狀況為訂單產品選擇合適的供應類別.

圖 面向庫存生產產品之庫存變化 和 面向訂單生產產品之庫存變化 分別展示了一個面向庫存生產和一個面向訂單生產產品之庫存變化情況.這兩個圖截取自OPENERP 產品表單中可的存貨水平預測報表.

圖20.3: 面向庫存生產產品之庫存變化

圖20.4: 面向訂單生產產品之庫存變化

注:物流方式
面向庫存生產通常適用于大量且需求是季節性的或者很容易預測.面向訂單生產則適用于產品是單獨計量或非常昂貴或只需要很短時間就可以補貨.

20.2.4 供應方式
OPENERP支持以下兩種供應方式
  生產: 產品是由內部資源製造或服務是由內部資源提供的
  購買: 產品是由供應商處習來的

這些都只是系統進行自動補貨時使用的默認設定.同一個產品既可以內部製造或可以從供應商處購買.
這三個欄位(供應方式,供應方式,產品類別)決定了產品需求處理過程中系統的行為.基於此三個欄位的設定系統會自動生成不同的單據來滿足一個訂單,要么是向供應商發出一份詢價單或開出一張製造工單.

OPENERP可以同時管理庫存產品和服務.對於在面向訂單方式中自供應商處購買的服務,系統會生成一個對該供應商的外包訂單.

圖 基於產品設定的自動供應工作流 說明了自動供應的各種不同情況.

圖 20.5基於產品設定的自動供應工作流

下表展示了基於產品設定的自動供應工作流各種可能的情況

表20.8 面向庫存生產(MTS)與面向訂單生產(MTO)之供應方式對比
供應方式          生產                購買
MTS            等待直到庫存不夠    等待直到庫存不夠
MTO            生產工單            採購訂單

表20.9 供應方式對使用服務的影響
供應方式            生產        購習
MTS                /          /
MTO                創建任務  外包訂單

在本章中你將進一步學習到更多與供應有關的自動化管理流程.
20.2.5 計量單位
OPENERP支持很多計量單位.同一產品的數量可用很多不同的計量單位表示.例如可以用頓為單位購買糧食,而以公斤為單位進行出售.只是要確保所有這些單位均屬於相同的單位類別.
注:單位類別
相同類別的所有單位之間可以相互轉換.

下表列出了一些計量單位及其所屬類別.只要屬於同一單位類別,不同計量單位之間使用系數進行轉換.

表20.10 單位的例子
單位 類別 比率 單位類型
Kg
克
頓
小時
天
半天
項
100項 重量
重量
重量
工作時間
工作時間
工作時間
單位
單位 1
1000
1000
8
1
4
1
0.01 參考
小
大
小
參考
小

基於上表,可以得出 1公斤 = 1000克 = 0.001 頓. 以重量為單位類別的產品可以用公斤,頓或克表示,但不可以用小時或個表示.
使用菜單 倉庫->設定->產品->計量單位->計量單位 來定義一個新的計量單位

在計量單位的定義中,可以定義圓整精度係數,此係數定義金額如何在轉換后被取整. 圓整系數1表示圓整到1個單位,0.01表示圓整到1%.
注:第二單位
OPENERP支持雙單位.使用此功能后,整個庫存管理系統使用雙單位記帳,兩個單位之間沒有實質的關聯.
此功能在農產-食品行業特別有用,比如,用個出售漢堡,用公斤來開票收款.當然在開票給客戶之前需要稱重.
要啟用雙單位管理,請將用戶組 可用性/產品UoS視圖 分派給用戶.
在此情況下,同一產品可以同時使用分屬不同單位類別的單位表示,這樣就可以區分存貨計量單位(個)和發票或銷售計量單位(公斤).
在產品表單上可以為銷售與庫存管理設定一個計量單位,為採購設定另一個計量單位.
這些單位都被賦予給定的標題.對產品的每個操作中可以使用其它已定義在相同單位類別里的計量單位,如果選擇其它計量單位,OPENERP會自動進行價格與數量換算.
因此如果有430公斤胡蘿卜,每公司5.3歐元,當以頓為單位出售時,OPENERP會自動將換算為0.43頓,5300歐元每頓.如果設定的圓整系數是0.1頓,那麼OPENERP會顯示只剩下0.4頓了.
20.3 存貨

得到老肖的肯定真是很荣幸，不过有点过奖了。
不过作为open source的贡献者，回馈又及鼓励才是不断努力与付出的动力呀，同志们，不要吝啬你们的意见呀。我希望OE越来越好，在中国越来越有市场。

庫存部份快完成了，先貼出來。
20.8 排程
主生產計畫,有時也叫MPS(Master Production Schedule主生產排程),用來對收到及發出物料產生預測.
注:MPS,供應與生產
OE區分生產,採購與供應.
生產是指製造,採購是指從另一方取得貨物,而供應則包括以上兩者.因此最好是將MPS叫做Master Procurement Schedule主供應排程,OE就是這樣做的.
提示:產品交易
也稱生產計畫.此工具對大生產性交易產品也非常有用.你也可以用它進行採購和生產相關的庫存管理.
要使用生產計畫功能,你必須安裝 庫存_計 畫模塊

20.8.1 銷售預測
要進行生產計畫,首先要定義庫存管理的周期,有些公司作日計畫,有些則是周或月計畫.
提示:庫存管理間隔
在生產計畫中管理庫存的間隔時間之選擇取決于你多長時間完成一個生產循環.一般會有日,周,月等情況.如果需要幾天時間組裝你的產品,你極有可能會定義一個周計畫.如果你的一次製造循環要花幾個月,那么你就可以定一個月計畫.

進到菜單 銷售->配置->庫存與銷售期間->庫存與銷售期間.接下來出跳出一個窗口允許你自動定義用於庫存管理的下個期間.

圖20.26:定義庫存管理期間
上述定義之後銷售人員可以使用菜單 銷售->銷售預測->銷售預測 按產品與期間錄入銷售預測數據.預測可以是數量也可以是金額.對於金額預測OE會基於預計金額為你自動計算出相應的數量.當然在保存之前你可以根據需要對數量進行手工調整.

圖20.27:維護銷售預測以幫助創建主生產計畫

20.8.2 生產計畫
接下來物流經理要計畫每期的收貨(製造與或採購)與出庫(消耗或出貨). 菜單路徑為 倉庫->庫存計畫->主供應排程
OE會為每個期間之產品提供以下信息
  .預估期末存貨. 計算邏輯為上期末存貨(譯者注)-預計出庫+預計入庫
  .已結案記錄: 來自生產與已確認採購
  .本期預計入庫:計算公式:計畫入庫-截止存貨
  .計畫入庫: 由物流經理手工錄入
  .已結案出庫. 包括製造耗用以及出貨給客戶
  .出庫預測.計算公式:計畫出庫- 截止存貨
  .計畫出庫: 由物流經理手工錄入
  .銷售預測: 代表銷售人員所作銷售預測的匯總

圖20.28:主生產排程
物流經理可以基於生產計畫中的入庫及出庫預測來分析其相關產品未來庫存的影響.生產計畫可以讓你能檢查并確保特定產品的庫存不會低于設定的庫存水平.
你也可以開啟以前期間的生產計畫.這種情況下OE是在預估報表中按期間顯示給你實際庫存移動明細.
如果你尚未為產品定義自動供應規則,你可以在任意時間基於生產計畫中的預測啟動供應. 與此相關的操作方法是在主供應排程畫面點擊 未達入庫供應. OE按預測的金額對供應進行計畫.

20.9 管理批次與可追溯性
OE的複式記帳使你可以作很高級的追溯性分析.所有的操作都被以庫存移動的形式記錄下來了,因此可以很容易地找出庫存移動中產生偏差的原因.
注:向上及向下追溯
向上追溯是指由從供應商處接收的原材料循移動鏈直至產成品出貨給客戶.(請注意此處的名稱有點易混淆-有時這種情況也被認為是向下追溯. 可以將此理解為什麽地地方使用了它- 被使用了)
向下追溯以另外一個方向跟蹤產品,是從客戶到各個不同的原材料供應商.( 請注意此處的名稱有點易混淆-有時這種情況也被認為是向上追溯. 可以將此理解為什麽地地方供應了它)

20.9.1 庫存移動
使用菜單 倉庫->追溯->庫存移動 可以追蹤一個產品或特定庫位的過去的庫存交易.你可以使用各種欄位進行過濾以找出產品相關的訂單,生產活動或源庫位及目標庫位.

圖20.29:庫存移動歷史
每次庫存移動均有特定的狀態,各種可能的狀態如下
  .草稿:此類移動在系統內還未有實際作用.此交易尚未被確認
  .已確認:移動即將完成,因此它會被計算到預期存貨里,因為已為移動相關產品作了預留,你不知道它是否會被正常處理完成.(譯者注,此處有點繞)
  .已驗證:此移動即將完成且此交易必須的原物料也已被預留.
  .已完成:庫存移動已完成且被作為實際存貨的一部份
  .等待:在來自訂單的情況下,此狀態意味著庫存移動因等待其它移動的結束被暫停.
  .已取消:庫存移動沒有執行,因此實際庫存與預期庫存都不會考慮它.
出貨單,產品收貨及內部分揀清單都只是對有相類似屬性庫存移動進行分組的單據,你也可以使用菜單 倉庫->追溯->包裝 來看看這些單據的歷史記錄.

20.9.2 批號
OE也可以管理批號,有以下兩類批號
  .生產批次(批號)適用于離開相同生產區域的獨特產品或由相同產品組裝而成的組裝件.它們通常由貼在產品上的條形碼進行標識,批號可以是供應商號碼或貴公司號碼.
  .追蹤號:是邏輯批次用以識別包含一組產品的容器.相關的實際應用案例,如放有許多不同產品的棧板上的棧板號.
這些批號可用於所有庫存移動,特別是貨運入庫,內部移動以及出貨.

圖20.30:輸入產品收貨行
在操作中輸入批號時,要么使用現有批號或創建一個新批號.生產批號(批號)用於單個產品.追蹤號可以不同產品上使用多次,因此你可以在一個棧板上或盒子里混合不同的產品.
注:簡化視圖
在簡化視圖模式下,看不到追蹤號:該欄位被隱藏了.要使用擴展視圖模式,請將 可用性-擴展視圖 用戶組分派給當前用戶.
你也可以在產品表單上指定哪些操作中批號是必輸的.這樣你就可以強制用戶為製造操作,收貨以及出貨包裝輸入批號了.
你不需要為一組不同的物品一個一個地編一個唯一的批號.你只需要選定包含許多新產品的移動單,然後點擊產品批號分割按鈕.接下來給定一個前綴(如果你希望),OE會啟動一個嚮導在前綴基礎上添加一個序列號為你生成一個完整的批號.此序列號可能就對應于一組預先打印好已貼在每個產品上的條形碼.

圖20.31:批號分割

20.9.3 追溯
如果你如上所述為庫存移動輸入了批號,你就可以針對特定的批號作追溯了. 相關菜單為 倉庫->追溯->生產批號,或 倉庫->追溯->包裝
提示:產品捷徑
從產品表單,右邊的工具條提供了以下有用信息
  . 最小庫存規則
  . 各庫位存貨
  . 產品銷售
  . 物料清單

可以使用批號,日期或產品等過濾條件搜尋一個特定的批號.一旦你看到此批號的表單, 在表單上可執行以下動作
  . 向上追溯:從供應商直至客戶
  . 向下追溯:從客戶到供應商
  . 在所有物理及虛擬庫位中的存貨

圖20.32:面向訂單生產之向上追溯

圖20.33:面向庫存生產之向下追溯

20.10 按日記帳管理
你可以像按日記帳管理會計一樣通過日記帳來管理庫存.此方式最大的優勢是你可以用不同的方式定義日記帳以滿足貴公司的需求.
例如,一個大公司可能希望按部門或倉庫組織其出貨.那麼你可以為每個部門創建一個日記帳和分派一名經理.對應于其在公司內的職務不同的用戶可以使用相應的日記帳.這種方式可以讓你更好地組織你的信息.
有大量運輸業務的公司可以按運貨車輛組織其日記帳.那麼不同的運輸訂單就可以被分派給代表運貨車輛的日記帳.當車輛離開公司時,你可以將此日記帳中所有的運單一并進行確認.

20.10.1 各種日記帳
激活銷售管理的發票日記帳重配置選項或安裝銷售_日記帳模塊就可以使用各種不同的日記帳了.在OE中有3個與此有關的新概念
  .發票日記帳
  .訂單日記帳
  .出貨日記帳
發票日記帳(銷售->配置->銷售->發票類別)用於分派採購訂單和/或出貨訂單給指定的發票日記帳.可以對日記帳中的任何事項進行一次性開票并且你可以按日記帳控制開票金額.例如你可以創建如下日記帳:每日發票,周末發票和每月發票.也可以在夥伴表單中默認顯示發票日記帳. 根據你的需求,可以設定開票方式為集中開票(一客戶一發票)或單獨開票(單獨發票).
訂單日記帳看起來像訂單,它會自動將記錄于其中的內容自動地轉換到對應的訂單中.這種功能讓你可以按各種方式對你的訂單進行分類,比如按部門,按銷售員或者按類別.一個銷售員可以使用自己的日記帳從所有她負責的訂單中篩選出該日記帳中的訂單以輕鬆了解對應訂單需要進行的工作.
提示:默認值
要在其自己的日記帳中錄入所有的訂單,銷售人員可以使用創建訂單時設定的欄位默認值.
最后的出貨日記帳.用於將每個項次過帳到一個出貨日記帳.例如你可以按出貨日期創建相應日記帳(如星期一出貨,下午出貨)或這些日記帳代表出貨車輛(如卡車1,卡車2)一天的出貨.

20.10.2 使用日記帳
現在你會看到如何在實際工作中使用日記帳來進行庫存管理工作.安裝銷售_日記帳模塊后,請先看看夥伴清單.在每個夥伴的銷售與採購子頁面里你會注意到開票方式欄位

圖20.34:夥伴表單中的開票方式
你可以在此為一個夥伴創建一個新的發票日記帳.你可以決定在日記帳中生成發票之後是單獨開票還是合并一起開票.創建第二個發票日記帳 月底發票 ,你可將其分派給另一個夥伴.

圖20.35:定義一個發票日記帳
請再為此兩個夥伴的一些訂單輸入一些數據.輸入完訂單數據后,夥伴表單中的開票方式欄位內容會自動帶到訂單中來.
請再來看看銷售訂單 歷史 子頁面中已創建的裝箱清單. .系統已自動顯示開票方式信息.請確認此清單中各個不同的訂單.
在每天下班前,主管開票的人可以按日記帳顯示一份清單. 進到菜單 銷售->發票->發票行. 選擇發票日記帳,這時系統會將所有待開票訂單在一個清單中顯示出來.你可以點擊 生成發票按鈕(畫面上齒輪狀圖標)以自動執行開票動作.
提示:確認發票
默認情況下,生成的發票只是草稿狀態,以讓你可以在將發票發送給客戶前可以進行修改.但是你也可以從清單中選擇所有發票并選擇 確認草稿發票 進行一次性確認.
在月底發票管理做的是同樣的工作,只不過是在月底發票日記帳中罷了.
你也可以錄入日記帳以一次性確認或取消所有訂單.同樣你也可以進行多個報價并將它們分派給一個日記帳,再一次性確認或取消它們.

圖20.36 訂單日記帳視圖
20.11 庫存管理的高級元素
在此部份我們將為你講解以下庫存管理與控制的細節
20.11.1 需求計算/排程
需求計算是指計算引擎根據為產品定義的規則對產品進行計畫,排定優先級以及啟動自動供應.
注:需求計算
需求計算常常被叫做排程
需求計算默認每天自動執行一次,你也可以通過菜單 製造->排程->計算排程手動執行它. 需求計算利用在產品,供應商以及法人中定義的參數決定各種不同的產品訂單,出貨以及採購的優先順序.

20.11.2 及時生產
排程默認每天自動執行一次.你應該將此執行安排在晚上你很少使用系統的時候以避免排程運算影響系統的性能.可以通過菜單 管理->配置->排程->排程動作 設定排程的開始時間.選擇被稱作 運行MRP排程 的規則并修改其下次執行的日期與時間.有些公司希望不斷地對錄入的訂單進行計畫而不是等到下一天產生供應訂單.模塊MRP_及時生產就是做這個工作的.安裝好此模塊后,在每個需求(會產生生產或採購訂單)被確認后系統就會進行實時的計畫.
如果你錄入了一個面向訂單生產產品的客戶訂單后,系統會立即產生一個對供應商的報價請求.
提示:自供應商出貨
Sale_supplier_direct_delivery(基於供應商直接出貨的銷售,有的系統也稱此為第三方交貨)模塊允許你的供應商直接交產品交給你的客戶.在撰寫本文時此模塊尚在addons_extra(外掛模塊:其它)中.產品遵循為其單獨配置的邏輯且只影響被標記為面向訂單生產的產品.
此模式不是任何時候都有實際意義.每個訂單會在被確認之時立即得以處理.因此如果一個訂單將在3個月后出貨,排程會在訂單被確認后為其在存貨中進行預留.這種情況下使相關產品對其它訂單可用應該更為合理.
如果一個採購訂單的發票控制被配置為 來自訂單,排程會立即創建對應的供應商詢價請求.考慮到提前期你可能更傾向于延後幾周以合并未來的訂單進行統一採購.
總結以上,我們可以看出及時生產模塊的一些副作用是
  .訂單間的優先級管理得不好
  .產生多餘的存貨(譯者注:此處不好理解, 根據上文,提前產生了需求?).

20.11.3 計畫
你已經看到大部分的OE單據可以在計畫視圖中進行變更.對出貨與收貨也一樣.在任何時候你都可以將它們放到日曆視圖中以對你的出貨與收貨進行計畫.

圖20.37 計畫客戶產品出貨
裝箱單上的計畫日期被定義在每個庫存移動行上,如果你有一個裝箱單包含許多不一定在同一天出貨的產品.裝箱單中最大與最小日期就是對應于裝箱單的庫存移動行之最早與最晚日期
如果你在日曆視圖上移動一個裝箱單,庫存移動單行中的計畫日期也會自動變更(移動).

20.11.4 管理部份交貨
部份交貨,有時也稱欠交訂單是由OE自動產生的.當你確認一個對客戶的出貨或來自供應商的收貨時,OE會要求你確認出貨或收貨的數量.
如果你不變更建議的數量,OE會確認并完成出貨或收貨有關的訂單.如果你修改數量,OE會自動以剩下的數量生成第二張出貨或收貨單.第一張單會被確認,而第二張會處於等待出貨(或收貨)狀態.

圖20.38 出貨數量確認屏幕
當你打開當前出貨清單,你會發現欠交訂單欄位,裏面記錄的是已出貨給客戶的前一張出貨單號, 每天你都可以據此快速找出那些部份交貨訂單以便優先處理它們.

20.11.5 供應商產品收貨
OE支持3種方式控制自供應商收貨之數據錄入
  . 手工錄入
  . 使用系統預先生成的收貨單
  . 獨立于收貨單從所有待收產品進行選擇,

你可以在”推動你的採購”章節看到更細節的關於供應商訂單的配置如何影響收貨的內容.

20.11.6 收貨之手工數據錄入
請選擇菜單 倉庫->倉庫管理->進口貨物 點擊新增按鈕 就可以手工錄入收貨信息.

圖20.39:產品收貨之手工數據錄入

20.11.7 確認預生成收貨單
如果你使用OE中的採購訂單,在採購訂單確認時系統就會為你自動生成產品收貨單.你不需要輸入任何資料,只要確認已訂數量與收貨數量是否一致即可.
通過菜單 倉庫->倉庫管理->進口貨運 會看到OE生成的所有待收貨產品的清單,可以恰當的過濾條件,利用按狀態分組等功能你就可以找到在特定狀態下的各種待收貨單據.

圖20.40:待收貨清單
接下來你可以使用供應商名稱或參考訂單號來定位具體的收貨單.選擇收貨單并確認數量.如果顯示的數量與控制表單中的不一樣,OE會以剩餘數量自動生成另一張待處理的收貨.你可暫時不用理會這張生成的收貨,或者如果你知道供應商再也不會將短少的數量送貨給你了,你就可以取消生成的收貨單.

20.11.8 通過選待收產品進行確認
上述方式對於收貨與原始訂單相符的情況特別適用.然而,如果你的供應商送貨時并不必然與訂單一致時,通過選擇產品而不是訂單來進行收貨顯然就容易多了.你可通過菜單 倉庫->產品移動 ->接收產品 來手工創建一個新產品收貨.OE會打開供應商的所有待收與已收產品清單,你可以自動地添加部份或者全部的產品到你的收貨單中.你可以基於狀態對待收產品進行過濾并進行確認.這種數據錄入方式特別適用于在同一時間針對多個訂單進行收貨.

20.11.9 產品路由