NIPPON跨公司销售业务-自动公司间发票V10.docx

公司间发票

对外的发票

1100002926
目录

跨公司销售（ICS）业务 3
1.1 术语规范 4
1.2 测试数据 4
Part 1. 业务流程 6
2.1 接单方签署并下达销售订单 6
2.2 重新落实需求计划 7
2.3 供货工厂创建交货单 8
2.4 供货工厂过账出货 9
2.5 接单方出票，向客户收款 11
2.5.1 对外销售发票的单价 11
2.5.2 会计凭证的价值分析 12
2.6 供货方出票，向接单方收款 13
2.6.1 内部结算发票的单价 14
2.6.2 会计凭证的价值分析 15
2.7 接单方承认对供货方的应付账款 16
Part 2. 技术原理剖析 19
3.1 序曲 – 组织单元的设计 19
3.1.1 公司代码 19
3.1.2 工厂代码 19
3.1.3 接单方的销售组织和渠道对供货工厂的匹配关系 20
3.1.4 接单方的采购组织设置 20
3.2 慢板 – 主数据的准备和部分关键定制 21
3.2.1 以接单公司的立场，创建供货公司的供应商主数据 21
3.2.2 以供货公司的立场，创建接单公司的客户主数据 23
3.2.3 物料主数据的组织单元覆盖 25
3.2.4 物料对外销售价格主数据 26
3.2.5 物料对内结算价格主数据 26
3.2.6 内部结算发票价格条件的特殊定制细节 27
3.2.7 跨公司销售订单和发票的定价过程确定 28
3.2.8 跨公司销售订单或发票的定价过程细节 29
3.3 协奏 – 发票类型的输出的配置和数据准备 31
3.3.1 为公司间交易发票类型分配输出确定程序 31
3.3.2 定义输出确定程序 31
3.3.3 输出类型RD04的定制 32
3.3.4 为接单方的客户号维护RD04输出条件的主数据 34
3.4 回旋 – 公司间发票的系统配置 35
3.4.1 销售订单类型配备公司间发票类型 36
3.4.2 把接单公司之销售组织的内部客户号确定下来 37
3.4.3 指定EDI传输的供应商逻辑地址 38
3.5 高潮 – IDOC内核与财务端的设置 39
3.5.1 维护IDOC处理的端口 39
3.5.2 定义客户的伙伴参数文件 40
3.5.3 定义供应商的伙伴参数文件 44
3.5.4 为EDI接收发票定义程序参数 46
3.5.5 为EDI接收发票分配公司代码 48
3.5.6 为EDI接收发票分配总账科目 48
3.5.7 为EDI接收发票分配税码 49
3.5.8 EDI接收发票的总账科目的数据要求 52
3.6 尾声 – 计量单位的定制和EDI凭证价值分析 54
3.6.1 计量单位的特殊定制要点 54
3.6.2 EDI自动产生会计凭证的价值分析 56
3.7 余韵 – IDOC讯息监控与背景作业 59
3.7.1 IDOC讯息监控 59
3.7.2 背景作业 63
Part 3. 附加说明 65

跨公司销售（ICS）业务
一、 业务场景：
销售公司：立邦船舶涂料（上海）有限公司简称NPMZ
生产公司：立邦船舶涂料（张家港）有限公司简称NPMZZ
NPMZ销售涂料给客户，由NPMZZ直接供货给客户，然后根据客户签收的凭证向NPMZ开票收款；NPMZZ验证签收凭证与事实无误之后付款，同时也向客户开票收款。
二、 上述业务的分析：
1. 上述业务的分析，首先需要划分两个维度（Dimension）：第一、交易的当事人“第三方”与“卖方”之间是否存在资本上的关联关系？第二、发生在“第三方”与“卖方”之间的标的物品，其物流是否存在“入卖方仓库”的事实？如下图，以这两个维度为坐标，业务被划分为四个象限——

（图：三角销售交易四象限图）

2. 以下用SAP的系统业务，对这四个象限分别分析：
2.1 第1象限：卖方找与自己存在资本关联的第三方购买产品，收货入库后再交给客户。这个流程其实是两段业务：首先是卖方与第三方之间的STO（库存调拨订单）业务，然后是卖方与客户之间的正常销售业务。本案中无论是货物流向还是债权债务关系，第三方与客户之间并没有直接的业务关系；
2.2 第2象限：卖方找与自己没有资本关联的第三方购买产品，收货入库后再交给客户。这个业务其实也是两段业务：首先是卖方与第三方之间的常规采购业务，然后是卖方与客户之间的正常销售业务。这是一个典型的“左手买进、右手卖出”的贸易业务。同样，本案中无论是货物流向还是债权债务关系，第三方与客户之间并没有直接的业务关系；
2.3 第3象限：卖方找到与自己没有资本关联的第三方购买产品，但货品自始至终并未进入卖方的仓库，而是由第三方直接交给客户。这个业务就是SAP称为“第三方销售订单”（3rd party sales order）的三角交易业务，第三方是“外部供应商”，三方在业务中形成一个整体，彼此之间存在着业务关联关系；
2.4 第4象限：卖方与第三方存在资本关联，货品始终没有进入卖方仓库，第三方直接交付给客户。由于卖方对第三方存在应付账款（AP），第三方对卖方存在应收账款（A/R），显然不能把第三方当成简单的外部供应商来对待。这个业务在SAP系统里被称为“跨公司销售”（Inter-Company Sales，ICS），在ICS中，卖方叫做“接单方”（Selling Party）或者“订单方”（Order Party），第三方叫做“供货方”（Supply Party），它们与客户一道组成一个三角业务关联整体。本文后续章节所描述的，就是这个象限的内容。
3. 追问：卖方与第三方虽然事实上存在资本关联关系，但第三方尚未进入SAP系统（即尚未上线），那业务怎么处理？
回答：问得好。第三方只要没有体现为SAP系统内的组织单元（如公司代码、工厂代码等），就一律“视作外部供应商予以管理”。

只有概念明确，测试才有依据，因此，请认真领会本段落所述的业务场景。

1.1 术语规范
为避免概念混淆，本文行文中，将把NPMZ称为“接单方”或者“接单公司”（Ordering party），NPMZZ称为“供货方”或者“供货公司”（Supplying party）。
1.2 测试数据
数据种类
代码
本业务中的作用
数据要求
物料主数据
FGN011Z17.0
U-Marine Finish 聚氨脂面漆
1.对工厂2000和1000同时维护；
2.对销售组织2000和1000同时维护。
客户主数据
100000015
与接单方签约的客户
1.对销售组织2000和1000同时维护；
2.至少要对公司代码2000维护。
接单方的公司代码
2000
与客户签署销售订单的我方当事人
组织单元，非前台维护数据。有关要求，见本文《技术原理剖析》部分
接单方的工厂代码
2000
履行销售订单交货业务的默认工厂
接单方的销售组织
2000
签署销售订单的组织单位
供货方的公司代码
1000
实际履行交货义务的会计发生主体
供货方的工厂代码
1000
实际履行交货义务的实体工厂
供货方的销售组织
1000
内部应收账款结算的销售组织

Part 1. 业务流程
2.1 接单方签署并下达销售订单
步骤：
1. 事务代码VA01。初始屏幕中，Order type = ZOR，Sales organization = 2000，distribution channel = 10，Division = 00。敲回车；
2. Sold-to party = 100000015，Req. deliv. Date服从系统自动默认结果。敲回车，呼出其他默认内容，把表头固定下来；
3. 行项目中，输入物料号FGN011Z17.0，数量自定（别太大，太大了存货不够，补进又会生出其他的操作），敲回车。交货工厂1000。

4. 菜单“Edit→incompletion log”，确保没有缺失的内容。
5. 选择行项目（摁瘪），点击图标，观察行项目的价格。记住了，可以修改的价格条件只有主价格ZPR1，其余都是来自价格主数据或者付款条件的价格数字；跨公司销售价格条件多了个ZI01和ZPRS等

6. 存盘，记录下号码1100000311。
7. 我们先记住这两个命题：①、价格ZPR1是接单方与客户之间的结算基本单价；②、价格ZI01则作为接单方（2000）与供货方（1000）之间的内部结算单价的基础。随着后续测试的进行和结果分析，我们将验证这两个命题的正确性。
2.2 重新落实需求计划
MD04，观察接单方（2000）项下，大地白茫茫真干净：

MD04，观察供货方（1000）项下，这回，需求元素可是实实在在的了。

供货工厂（1000）的计划人员只要看到MD04中1000工厂项下的需求和存货，自然就了解供需对照状况。
本例中，存货（Stock）量已足够覆盖需求（requirement）量，因此系统不会产生计划单（如果是内部获取）或者采购申请（如果是外部获取，物料类型HAWA是trading goods，外购商品，即所谓“左手买进右手卖出的东西”，一般就是外部获取）。
2.3 供货工厂创建交货单
供货工厂1000的存货已经到位，那么当然就可以向客户交付了。系统内的操作步骤如下——
1. 事务代码VL01N，输入装运点1000，输入销售订单号。日期必须可以覆盖销售订单中的要求交货日期。如下图——

2. 敲回车后，这回系统准许交货工厂创建交货单了。

3. 存盘，记录下交货单号码8000000320。
4. 刷新FGN011Z17.0在工厂1000项下的MD04显示。可以看到需求元素变更为交货单。

2.4 供货工厂过账出货
拣配完成，可以出货了。开两个会话（session），一个MD04观察FGN011Z17.0的存货/需求对照，另一个VL02N执行过账发货操作。事务代码VL02N，输入交货单号，点击那个大大的图标“Post goods issue”。
点击图标的操作非常简单，叙述从略。
点击过账后，MD04的结果显示如下，存货减少，需求元素姿消。

VA03显示销售订单的凭证流（document flow），可以清楚地追溯到交货单、拣配单和物料凭证的信息。

发的是工厂1000的货，而工厂1000又从属于公司代码1000，这笔货不能不明不白，因此公司代码1000项下，当然将产生一笔会计分录。

2.5 接单方出票，向客户收款
事务代码VF01，参照已过账出货的交货单创建标准发票（F2）。过程从略，结果如下——

我们需要验证两个问题：1. 出具销售发票依据的单价是哪个？ 2. 会计凭证中的价值是怎么计算来的？
2.5.1 对外销售发票的单价
VF03显示销售发票，观察其ZPR1的单价和价值。

含税单价10USD，数量5*17，汇率6.162，净合价=10 x 105*6.162=5,237.70；
税率17%，税额 = 5,237.70 x 17%=761.03；
2.5.2 会计凭证的价值分析

瞧仔细了：对客户的外部发票是接单方（2000）出具的，公司代码当然就是2000。
2.6 供货方出票，向接单方收款
如果是常规的销售业务，2.8段落执行完毕后，物流模块（Logistics）的流程就全部结束了，因为后面的收款和清账纯属财务上的操作，与物流无关。
然而本案所述的流程中，事情并没有结束，因为供货方（工厂1000/公司1000）作为一个会计核算主体代替另一个会计核算主体（接单方2000公司）履行了交货义务，它的权利还没有得到交代。因此，供货方需要对接单方出票，主张自己的应收账款。
怎么主张？
答案很简单：VF01，对交货单“二次出票”！操作步骤如下描述——
1. VF01进去。在下方的单据中，再次输入交货单号！

插话：等等，先别急着敲回车。就这样，你就能创建第二张发票吗？
回答：是的，就这么简单。
追问：在字段Billing Type中，你难道就不想输入一点内容吗？
回答：嘿，我还真就不想输入任何内容，我现在就敲回车给你看——
2. 回车一敲，系统真的创建一张新的发票，而且选择的billing type不是F2，而是IV。在标准的SAP定制中，IV就是“公司间结算的发票类型”！

3. 存盘，先产生发票号和会计凭证，接下来再分析。

2.6.1 内部结算发票的单价
VF03显示内部结算发票（IV发票），观察其ZIV1的单价和价值。

那么供货方公司1000向接单方公司2000的应收账款，就应该是500。
2.6.2 会计凭证的价值分析

上帝，会计分录还真应验了我的推测，上图的会计分录用白话文来表达如下——
借：客户应收账款 585.00
贷：主营业务收入 915.00
贷：税金 85
2.7 接单方承认对供货方的应付账款
提问：三角交易中，接单方（2000）对客户的发票出具了，供货方（1000）对接单方的内部结算发票也出具了，流程是不是就该结束？
回答：还没有，因为接单方还没有承认对供货方的应付账款义务。这就是“同一企业集团项下不同会计法人主体之间的关联交易”必须考虑的要素：一方对另一方主张权利，不等于另一方同时承认义务。
提问：那么接单方又该怎么“承认”呢？应付账款的产生，只可能来源于两个渠道，要么从采购模块的发票校验产生，要么是在FI模块中手工做账，是不是？
回答：说的很到位，的确如此。
追问：可是本文行文至此，根本就没有出现采购订单，更没有收货。这不是STO业务，接单方与供货方之间没有采购订单和收货记录，怎么做发票校验？难道是直接在FI模块中用事务代码FB01直接手工创建会计凭证这种“流氓方式”吗？
回答：您还真说对了，的确是FB01，但操作者不是接单方（2000）的会计人员，而是系统的IDOC功能！因此，不能说是“手工创建应付账款凭证”，而是“系统驱动IDOC自动创建”。
具体的机制后面再阐述，我们先只看结果，步骤如下——
1. 事务代码FBL1N。供应商代码输入10000，公司代码输入2000，“open at key date”维持系统默认的当前日期，其余不问。点击图标进入。
2. 系统显示如下。很明显，画红框的才是本案的记录。

3. 点击上图凭证前面的小方框，再点击图标，进入下图

4. 不必领会其他内容，直接点击上图的图标。图穷匕首现。

5. 流程至此才算全部结束。很显然，人工FB01与本文所述的系统IDOC触发FB01操作，哪个“更具有技术含量”，不言自明。
Part 2. 技术原理剖析
有一个SAP NOTE叫做31126，阐述的就是如何在“跨公司出票”（Inter-Company Billing，ICB）场景下使用SAP EDI技术（Electronic Data Interchange，电子数据互换）直接在FI模块中过账到供应商库存而执行正确的系统设置。本部分内容就以这个NOTE为参考线索，结合作者个人体会而叙述。
3.1 序曲 – 组织单元的设计
首先必须搭建这个业务中所涉及的有关接单方（Selling Party）与供货方（Supplying Party）的组织结构，包括公司代码、工厂代码、采购组织、销售组织、销售区域组合（即销售组织·分销渠道·产品组的组合）等组织单元，以及此类组织单元之间的分配关系。
3.1.1 公司代码
作为SAP顾问，公司代码的配置路径再熟悉不过了，不再赘述。
供货公司1000和接单公司2000已存在，且地址数据完备。
自定义的公司代码，地址数据必须完备。所谓“完备”的标准，是“不要让SAP系统报错存在缺失‘必须输入’的数据”即可。

3.1.2 工厂代码
同样的理由，工厂代码的配置路径不再赘述。
本案有关的供货工厂1000和销售工厂2000也已存在，且地址数据完备。
自定义的工厂代码，地址数据仍然必须完备，标准同上。

3.1.3 接单方的销售组织和渠道对供货工厂的匹配关系
在接单公司的自有工厂无法供货的情况下，它当然要寻求供货公司的工厂。因此，必须完成接单方的销售组织（2000）和有关渠道与供货工厂（1000）之间的分配关系。这个配置可以说是ICS业务得以实现的基石，切记、切记！

3.1.4 接单方的采购组织设置
在本案所述的三角交易关系中，接单方（2000）相当于是从供货方（1000）购买商品。虽然在整个流程中没有出现任何采购订单，但这不等于采购组织没有定义的必要。
SAP IDES中，接单方2000的采购组织就是它自己的部门或者团队，即2000。下图显示的是工厂代码2000项下所有的采购组织配置状况。配置路径，请自己寻找。

3.2 慢板 – 主数据的准备和部分关键定制
3.2.1 以接单公司的立场，创建供货公司的供应商主数据
很明显，本案中，接单公司是2000，供货公司是1000
创建供应商主数据的事务代码是XK01，这个事务代码意味着组织结构的选择不仅要选择公司，还要选择采购组织。公司代码当然是2000，采购组织按3.1.9段落的描述，也是2000。
创建主数据的过程从略，作者只想强调的是：供应商号码与工厂之间必须关联！
供应商与工厂关联的含义，在于下列步骤——
1. 对创建完毕的供应商，启动事务代码XK02（MK02也行），输入供应商号、公司代码、采购组织后，只点击“Purchase data”。如下图：

2. 敲回车进去后，菜单“extra→additional purchase data”。系统跳出一个对话框。在对话框里，输入工厂代码1000。这就是所谓的“将集团内供应商与工厂组织给关联起来”，MM模块主导的STO业务也有这个操作！

3. 存盘退出。

3.2.2 以供货公司的立场，创建接单公司的客户主数据
创建客户主数据的事务代码是XD01，这个事务代码意味着组织结构的选择不仅要选择公司，还要选择销售区域。公司代码当然是1000，销售区域组合按我们在前面章节的描述，销售组织=1000、分销渠道=12、产品组=00。
1. 页签“Sales”项下，字段Customer Price Procedure，内部客户的客户定价程序与常规销售相同，也是1；
2. 同样的页签“Sales”，字段“Acct at cust.”，非常重要。只能是10000。
问：为什么要输入10000？
答：这个字段是什么意思？“我们在客户方的账号”。“我们”是谁？对于接单公司2000而言，我们是不是它的供应商？既然是供应商，总得有个号码标识，我们的供应商号码标识，3.2.1段落说的还不够清楚吗？根据SAP NOTE 31126的说明，如果要启动IDOC完成供应商账户的自动过账，字段“Acct at cust.”必须输入正确的值！

3. 页签“Billing documents”项下，字段“Acct assgmt group.”，很多公司要设置与外部客户不同03，文字“Ap.reven.”，已经把“关联公司收入”的含义表达得很清楚了，本次项目客户并不需要分的太细致，所以视同普通销售，也设置为01.

3.2.3 物料主数据的组织单元覆盖
物料既然可以被接单公司（2000）下销售订单，它就必须维护2000工厂项下的数据、以及维护销售组织2000·分销渠道10·产品组00项下的数据。
物料既然可以被供货工厂（1000）交付，它就必须维护1000工厂项下的数据。
物料既然可以被供货公司（1000）开内部结算销售发票，而销售发票离不开销售区域，因此还必须维护销售组织1000·分销渠道10 产品组00项下的数据。
具体过程不再赘述，只看下图所表达的结果——

3.2.4 物料对外销售价格主数据
事务代码VK11，条件类型ZPR1，选择最下方的“material with release status”。
物料=FGN011Z17.0，销售渠道=2000，分销渠道=10，有效期自己定。结果如下——

可以回想一下：在2.1段落下订单时，ZPR1单价是不是默认自动带出来的（尽管是“白色可修改”）？
在已经存在物料销售价格主数据的前提下，用VK12修正或者VK13只读即可。
3.2.5 物料对内结算价格主数据
事务代码VK11，条件类型ZI01。Key combination只有一个选择。
Sales organization for order，当然填写2000，因为与客户签署销售订单的销售组织是2000；
Plant，则必须填写1000，因为这是出货的工厂。
下方物料号当然填写FGN011Z17.0，价格据实录入，有效期自定。
请用VK12或者VK13观察。

追问：不对，请等一等！你维护的是ZI01，可是2.9.1段落中内部结算发票的截图很清楚，生效的是ZIV1的价格。这是怎么一回事？
回答：你的确看得很仔细。下面的定制马上回答你的疑问——
3.2.6 内部结算发票价格条件的特殊定制细节
事务代码V/06，定位到ZIV1，也就是你看到的内部结算发票的价格条件。进入其详情——

答案揭晓：ZIV1在执行销售业务中，将从ZI01的现有记录中参考取值。
关于“reference condition type”的用途，请自己参阅SAP在线帮助文档并自己测试，本文不再赘述。
进一步讲，你可以启动事务代码VK11直接创建ZIV1的价格主数据，来看看系统会告诉你什么信息——

3.2.7 跨公司销售订单和发票的定价过程确定
事务代码OVKK。这个事务代码回答“系统如何抓取不同的定价过程和主条件类型”。
按下列变量挑选——
l Sales organization = 1000（供货方出具IV发票）
l Distribution channel = 00
l Division = 00
l Customer pricing procedure = 1
l Document pricing procedure = I
结果如下图——

不明白为什么“document pricing procedure”要选I，是不是？
事务代码VOFA，自己观察F2和IV，看看它们的字段“document pricing procedure”各自是什么？

作为接单方2000，它与客户签署的OR标准销售订单，定价过程则是ZAB001。它对客户出票的定价过程，也是ZAB001。
其中的原理，请自己用上述方式去找寻，不再赘述。
3.2.8 跨公司销售订单或发票的定价过程细节
事务代码V/08。这个事务代码回答“定价过程是怎么样的构成结构”。
销售订单与外部发票的ZAB001定价过程，ZPR1是主价格，而ZI01也是其中的一个条件类型，而且也对应到销售收入的账码（ERL）。

然而更值得关注之处，在于它的requirement赋值22。

无论是采购订单的定价还是销售订单的定价，requirement都表示“只有在满足例程所规定的算法条件下这个价格才有效”。
例程22的详情，请自己用事务代码VOFM去阅读其代码程式，本文不再赘述。
内部结算发票所采用的ZIV001的定价过程，其配置详情，同样用V/08去观察。相对应的核心条件类型是ZIV1。自己看去，不再赘述。

3.3 协奏 – 发票类型的输出的配置和数据准备
3.3.1 为公司间交易发票类型分配输出确定程序
事务代码：V/25

作为对比，标准发票的输出类型是RD00。
3.3.2 定义输出确定程序
事务代码V/42。
公司间发票的输出确定程序V40000的具体详情如下图所示——

作为对比，不妨看看常规发票的输出确定程序V10000的详情：

3.3.3 输出类型RD04的定制
事务代码V/40。
看看，RD04的传输介质是什么？

不怕不识货，就怕货比货。标准发票对应的输出类型RD00，它的介质又是什么？

所有的SAP输出类型，都有程式（program）、表单例程（routine）和表单（form），当然表单是可以自定义的。标准IDES中的EDI传输介质并没有定义表单（Form）。

熟悉SAP“条件技术”（Condition technique）的顾问都知道，条件类型（condition type）是定制概念，条件类型要想读取前台作业人员创建的主数据，就必须为它定义一个存取顺序（access sequence）。输出（output）应用的，也是“条件技术”的一种形式，因此输出类型也有存取顺序，这个存取顺序就是下图所示的0004。

3.3.4 为接单方的客户号维护RD04输出条件的主数据
事务代码VV31。
输入RD04，敲回车。点击图标key conbination，跳出的组合只有一个，如下图。

这是因为RD04的存取顺序0004所确定的表格只有一个，如下图：

回到VV31维护输出主数据，结果如下。显然，IV发票的发送者（sender）是供货公司，上方的销售组织当然是供货方的销售组织1000。

创建完毕后，存盘退出。
已经存在记录的，用VV32修改或者VV33只读。
3.4 回旋 – 公司间发票的系统配置
本段落的配置根目录：IMG→Sales and distribution→Billing→Intercompany billing，如下图。这是本段落项下的“总配置目录”。

3.4.1 销售订单类型配备公司间发票类型
配置路径：配置根目录→Define order types for intercompany billing。
定位于标准订单类型OR，如下图把发票类型IV填写进去。

这个配置意味着当接单方（2000）向外部客户签署的标准销售订单变更供货工厂（即变更为1000）时，系统可以允许已经过账发货的交货单被“二次开票”，且“二次开票”的默认发票类型就是IV。
经测试可以证明：本段落的定制，与VOV8定义销售单据类型是完全等价的。如下图所示：

3.4.2 把接单公司之销售组织的内部客户号确定下来
配置路径：配置根目录→Define internal customer number by sale organization
在接单公司的销售组织（即2000）一行，填写3.2.2段落所创建的客户主数据号码填进去。

提问：为什么供货方（1000）的销售组织也被维护了客户号码呢？
回答：就本文所描述的场景而言，您的确可以不维护。维护了就表示1000销售组织同样可以作为“跨公司销售的签约方而被其他的兄弟公司出具公司间结算发票”。不过这是IDES系统，咱维持不变。
3.4.3 指定EDI传输的供应商逻辑地址
配置路径：配置根目录→Automatic posting to vendor account (SAP EDI)→Assign Vendor
事务代码：WEL1
结果如下图所示：

维护说明如下：
1. 逻辑地址（Log.addr.）：以供货公司（即本案的1000）的立场来命名，结构是“供货的公司代码+接单公司体现为供货公司的内部客户号”。这里需要强调：如果客户号码是内部编号（即全部是数字），那么逻辑地址必须凑足14位数，不足的部分，按下表所示的结构进行填充——
性质
供货公司
用0填充
客户号
位数
1
2
3
4
5
6
7
8
9
10
11
12
13
14
赋值
1
0
0
0
0
0
0
0
0
2
2
0
0
0
2. 目的端（Destination）：以接单公司（即本案的2000）的立场来命名。Company Code当然就是接单公司本身，即2000；Vendor就应该填入供方公司在接单公司项下的供应商号码，即10000。
追问：本文的例子，无论供应商还是客户，号码都是内部编号（即全部是数字），然而在我们的XX项目中，公司代码固然都是数字，内部客户号和内部供应商号却是类似于C3430、C2000之类的编号。如果我们的场景是：公司代码2000（内部客户号C2000）对客户签单，公司代码3430（内部供应商号C3430）履行交货职责，那么逻辑地址又该怎么定？
回答：逻辑地址如下表，即不需要凑足14位数。
性质
供货公司
客户号
位数
1
2
3
4
5
6
7
8
9
赋值
3
4
3
0
C
2
0
0
0

而目的端，公司代码则是2000，供应商当然是C3430了。

注意：这个定制非常关键，它是被发送的EDI信息找到“接收方”（recipient）的基本定制。
3.5 高潮 – IDOC内核与财务端的设置
3.5.1 RFC 连接配置 SM59

3.5.2 维护IDOC处理的端口
事务代码：WE21
在IDES中，已经有许多端口（port）了，我们只需要关注A000000001是否存在于文件夹“Transactional RFC”即可。

3.5.3 定义客户的伙伴参数文件
事务代码：WE20
点开文件夹“Partner Type KU”，创建客户20000。详细内容如下——
1. 页签“Post processing: permitted agent”项下，Ty.默认为US（SAP用户）、Agent默认为当前操作人的用户ID、Language默认为当前系统的登录语言。这些信息维持默认值即可

2. 点击放大镜图标，信息变式（message variant）FI的详情如下：
2.1 页签“outbound option”项下，下图标注部分是关键要素；

2.2 页签“Process control”项下，应用只能是V3，讯息类型是RD04，处理代码是SD08；

2.3 其余页签维持默认值。

2.4 其余页签维持默认值。
3. 在Partner profile的表头层面，第二个页签classification，Partner status必须赋值为A。

4. 其余不问。新建的伙伴参数文件必须存盘才能生效。
3.5.4 定义供应商的伙伴参数文件
事务代码：WE20
点开文件夹“Partner Type LI”，创建供应商10000。详细内容如下——
1. 表头的要求，与客户伙伴参数一致，不再赘述；

2. 下方的细节，维护的是inbound parameter（入埠参数）。不需要partner role（因为inbound是被动接受），message type都是INVOIC。

3. 变式FI的细节简述如下——
3.1 页签“inbound option”，关键如下：

3.2 其余页签无特别要求。30

3.5.5 为EDI接收发票定义程序参数
事务代码：OBCE。配置路径自己找，下图是示例——

选中下图红框与本案有关的那一行，再点击图标——

配置详情如下所述——

请回顾本文2.10段落中的截图，系统自动产生的会计凭证的类型是RE，是不是？
这个RE，就是由上图的定制确定的。
3.5.6 为EDI接收发票分配公司代码
事务代码：OBCA。
定位于Partner type = LI、Partner number=10000，即本案有关的供货公司，它们是接单公司的供应商。
最右边的Cocd字段中，输入本案有关的接单公司的公司代码，即2000。

根据SAP的文献原文描述——By leaving the field COCD blank, all company codes are available。理解为“如果最右边的字段COCD维持空格，系统就默认为供应商10000可以对任何它存在数据记录的公司代码都触发EDI动作创建会计凭证”。请自己验证。
3.5.7 为EDI接收发票分配总账科目
事务代码：OBCB。
1. 如下图，在系统跳出的小框中，依次输入LI（供应商）、10000（供货公司体现的内部供应商）和2000（接单公司的公司代码）。

2. 上图敲回车进去后，按财务要求输入总账科目，文本字段是可选择项目。当然，这个总账科目必须是事先在公司代码中创建好的科目主数据。

3. 需要注意的是：总账科目不可以与CO模块的任何对象挂钩，即它不能是成本要素（cost element）。具体详情，请咨询FI/CO的顾问。
3.5.8 为EDI接收发票分配税码
事务代码：OBCD。
本定制的作用，在于把来源于销售订单中的销项税（output tax）与供应商发票中的进项税（input tax）关联起来。
1. 定位到LI·10000的行，确保你交易中可能出现的销项税码能够关联到进项税码。

2. 字段“Tax type”，用来记录销项税税码（Output tax code）；
3. 字段“Tx”，用来记录进项税税码（Input tax code）。

马上产生了问题：我怎么知道供货方内部结算发票的销项税税码是哪个？
回答：
1. 找到那张内部结算发票的号码，VF03显示。进入行项目的“Condition”页签，如下图：

2. 点击上图的图标后，定位到MWST“销项税”那一行，点开，找到有值的那个访问顺序，如下图：

3. 按上图的箭头所指，滑鼠点击，系统马上把你导引至条件价格主数据的界面如下图——

4. 选中MWST那一行（摁瘪），再点击图标。如下图所示，找到销项税税码。

5. 作为SD顾问，你真不应该提这个问题，因为这是SD顾问的基本功。
3.5.9 EDI接收发票的总账科目的数据要求
3.5.6段落所描述的总账科目（607010）的主数据，存在一定的要求。
FS00，进入总账科目在公司代码2000项下的数据，如下图所示强调两个要点：
1. 页签“control data”项下，tax category必须“允许所有的税类型”。

2. 页签“Create/bank/interest”项下，旧版本（4.7以下，含4.7）是“允许手工过账”，新版本（4.7以上，即ECC X.0）则是“Post automatically only”（只能允许自动过账）。那么在旧版本下，标志就得点上；新版本下，标志恰恰相反就不能点上。

其余数据要求，按自己的需要自行处理，与IDOC无关。
3.6 尾声 – 计量单位的定制和EDI凭证价值分析
3.6.1 计量单位的特殊定制要点
请回顾3.5.4段落中关于EDI接受发票的程序参数，最下方有个单位。

这个计量单位的定制，有点“小小的讲究”。用事务代码CUNI进入PC的配置。
1. 维度
什么是维度（dimension）？
KG代表的是物品的“重量”、M则表示物品的“长度”，所谓的“重量”、“长度”，就是维度。用书面语言来说，维度是人类用来判断客观事物的基本视点。
那么PC又是什么维度？PC是离散计数的单位，离散计数的单位都属于“无维度的计量单位”。
那么，在下图，你该怎么做呢？当然就是直接点击最下方的图标，进入“无维度的单位”。

2. 无维度的单位