SAP跨公司销售业务测试与原理V10

/目录TOC\o"1-5"\h\z\uSAP跨公司销售（ICS）业务——测试与原理 3Part1. 测试环境、测试剧本与测试数据 31.1 测试剧本 31.2 术语标准 41.3 测试数据 5Part2. 业务流程 62.1 接单方签署并下达销售订单 62.2 需求方案的落实传递 72.3 修改销售订单，变更交货工厂 102.4 重新落实需求方案 122.5 供给工厂创立交货单 132.6 供给工厂拣配 152.7 供给工厂过账出货 182.8 接单方出票，向客人收款 202.8.1 对外销售发票的单价 202.8.2 会计凭证的价值分析 212.9 供给方出票，向接单方收款 212.9.1 内部结算发票的单价 232.9.2 会计凭证的价值分析 242.10 接单方成认对供给方的应付账款 24Part3. 技术原理剖析 273.1 序曲–组织单元的设计 273.1.1 公司代码 273.1.2 工厂代码 273.1.3 公司代码与工厂代码之间的分配关系 283.1.4 接单方与供货方的销售组织 283.1.5 接单方与供货方的销售区域组合 293.1.6 接单方与供货方的销售组织和渠道对各自工厂的匹配关系 303.1.7 接单方的销售组织和渠道对供货工厂的匹配关系 303.1.8 接单方和供货方各自装运点与工厂的匹配关系 313.1.9 接单方的采购组织设置 323.2 慢板–主数据的准备和局部关键定制 323.2.1 以接单公司的立场，创立供货公司的供给商主数据 323.2.2 以供货公司的立场，创立接单公司的客户主数据 343.2.3 物料主数据的组织单元覆盖 353.2.4 物料对外销售价格主数据 363.2.5 物料对内结算价格主数据 373.2.6 内部结算发票价格条件的特殊定制细节 383.2.7 跨公司销售订单和发票的定价过程确定 393.2.8 跨公司销售订单或发票的定价过程细节 403.3 协奏–发票类型的输出的配置和数据准备 423.3.1 为公司间交易发票类型分配输出确定程序 423.3.2 定义输出确定程序 423.3.3 输出类型RD04的定制 433.3.4 为接单方的客户号维护RD04输出条件的主数据 443.4 盘旋–公司间发票的系统配置 453.4.1 销售订单类型配备公司间发票类型 463.4.2 把接单公司之销售组织的内部客户号确定下来 473.4.3 指定EDI传输的供给商逻辑地址 483.5 高潮–IDOC内核与财务端的设置 493.5.1 维护IDOC处理的端口 493.5.2 定义客户的伙伴参数文件 493.5.3 定义供给商的伙伴参数文件 533.5.4 为EDI接收发票定义程序参数 553.5.5 为EDI接收发票分配公司代码 573.5.6 为EDI接收发票分配总账科目 573.5.7 为EDI接收发票分配税码 583.5.8 EDI接收发票的总账科目的数据要求 613.6 尾声–计量单位的定制和EDI凭证价值分析 633.6.1 计量单位的特殊定制要点 633.6.2 EDI自动产生会计凭证的价值分析 653.7 余韵–IDOC讯息监控与背景作业 673.7.1 IDOC讯息监控 673.7.2 背景作业 70Part4. 附加说明 72

SAP跨公司销售（ICS）业务——测试与原理测试环境、测试剧本与测试数据本公司自己的IDES系统，客户端800。登录语言最好选择英文（EN），汉语环境无法保证有关的表单格式已具备。测试剧本剧本描述：卖方与客人签约提供某个产品，然而卖方是“销售型公司〞，没有生产的资质，只能找一个第三方购置。第三方安排供货，把交易标的物品直接交给客人，然后根据客人签收的凭证向卖方主张权利（即收款）。卖方验证签收凭证与事实无误之后，向第三方成认债务（即支付货款），自己也向客人出票主张权利。这个“三角交易业务〞项下，第三方的角色非常关键。以下是分析——上述剧本的分析：上述剧本的分析，首先需要划分两个维度（Dimension）：第一、交易的当事人“第三方〞与“卖方〞之间是否存在资本上的关联关系？第二、发生在“第三方〞与“卖方〞之间的标的物品，其物流是否存在“入卖方仓库〞的事实？如以下图，以这两个维度为坐标，业务被划分为四个象限——（图：三角销售交易四象限图）以下用SAP的系统业务，对这四个象限分别分析：第1象限：卖方找与自己存在资本关联的第三方购置产品，收货入库后再交给客人。这个流程其实是两段业务：首先是卖方与第三方之间的STO（库存调拨订单）业务，然后是卖方与客人之间的正常销售业务。本案中无论是货物流向还是债权债务关系，第三方与客人之间并没有直接的业务关系；第2象限：卖方找与自己没有资本关联的第三方购置产品，收货入库后再交给客人。这个业务其实也是两段业务：首先是卖方与第三方之间的常规采购业务，然后是卖方与客人之间的正常销售业务。这是一个典型的“左手买进、右手卖出〞的贸易业务。同样，本案中无论是货物流向还是债权债务关系，第三方与客人之间并没有直接的业务关系；第3象限：卖方找到与自己没有资本关联的第三方购置产品，但货品自始至终并未进入卖方的仓库，而是由第三方直接交给客人。这个业务就是SAP称为“第三方销售订单〞（3rdpartysalesorder）的三角交易业务，第三方是“外部供给商〞，三方在业务中形成一个整体，彼此之间存在着业务关联关系；第4象限：卖方与第三方存在资本关联，货品始终没有进入卖方仓库，第三方直接交付给客人。由于卖方对第三方存在应付账款（AP），第三方对卖方存在应收账款（A/R），显然不能把第三方当成简单的外部供给商来对待。这个业务在SAP系统里被称为“跨公司销售〞（Inter-CompanySales，ICS），在ICS中，卖方叫做“接单方〞（SellingParty）或者“订单方〞（OrderParty），第三方叫做“供货方〞（SupplyParty），它们与客人一道组成一个三角业务关联整体。本文后续章节所描述的，就是这个象限的内容。追问：卖方与第三方虽然事实上存在资本关联关系，但第三方尚未进入SAP系统（即尚未上线），那业务怎么处理？答复：问得好。第三方只要没有表达为SAP系统内的组织单元（如公司代码、工厂代码等），就一律“视作外部供给商予以管理〞。只有概念明确，测试才有依据，因此，请认真领会本段落所述的业务场景。术语标准为防止概念混淆，本文行文中，将把测试剧本中的“卖方〞称为“接单方〞或者“接单公司〞（Orderingparty），而“实际供货方〞称为“供货方〞或者“供货公司〞（Supplyingparty）。测试数据数据种类代码本业务中的作用数据要求物料主数据M-01交易的标的物1.对工厂2200和1000同时维护；2.对销售组织2200和1000同时维护。客户主数据2500与接单方签约的客人1.对销售组织2200和1000同时维护；2.至少要对公司代码2200维护。接单方的公司代码2200与客人签署销售订单的我方当事人组织单元，非前台维护数据。有关要求，见本文《技术原理剖析》局部接单方的工厂代码2200履行销售订单交货业务的默认工厂接单方的销售组织2200签署销售订单的组织单位供货方的公司代码1000实际履行交货义务的会计发生主体供货方的工厂代码1200实际履行交货义务的实体工厂供货方的销售组织1000内部应收账款结算的销售组织

业务流程接单方签署并下达销售订单步骤：事务代码VA01。初始屏幕中，Ordertype=OR，Salesorganization=2200，distributionchannel=10，Division=00。敲回车；Sold-toparty=2500，Req.deliv.Date服从系统自动默认结果。敲回车，呼出其他默认内容，把表头固定下来；行工程中，输入物料号M-01，数量自定（别太大，太大了存货不够，补进又会生出其他的操作），敲回车。可以看到，系统默认的交货工厂是2200。菜单“Edit→incompletionlog〞，确保没有缺失的内容。选择行工程（摁瘪），点击图标，观察行工程的价格。记住了，可以修改的价格条件只有主价格PR00，其余都是来自价格主数据或者付款条件的价格数字；存盘，记录下号码。需求方案的落实传递下达销售订单成功，那么订单需求通过系统关于需求传递的有关定制，自动落实需求方案。本步骤不存在写操作，只显示，步骤如下：启动事务代码MD04，输入物料号M-01（这是销售订单交易的标的物品），再输入工厂2200（即销售订单默认的交货工厂），敲回车进去。结果如下——接单方（2200）本身是个销售型公司，之所以设置工厂代码，是因为销售交货单是在工厂层面发生，而不是由于其事实上存在库存。事实上，如上图所示，工厂2200的存货是一张白皮。问题是：这一步骤下，需求方案到底是传递给2200还是1200？答案很明确：在这个步骤，需求方案还只是传递到2200即接单方层面，还没有传递到1200即事实上的供给工厂层面。你用MD04可以迅速获得验证——事实上，如果我们用VL01N创立交货单，如以下图所示的界面把供货方装运点输入后，您看看系统会有什么反应——（图：用供货方装运点去创立交货单的初始屏幕）敲回车后，系统反应如以下图所示。很显然，这绝对不是“可以创立外向交货单〞的界面。（图：供货方装运点不能创立交货单）怎么办？供货方（即1200）不能创立交货单，我用接单方（即2200）可以创立交货单吗？试试不就知道了吗？结果如以下图，显然，这是“可以创立外向交货单〞的界面。虽然2200工厂项下M-01没有任何存货，但由于ATP检查的配置，我们还是可以“创立交货单〞，只不过不能“拣配〞、更不能“过账发货〞而已。（图：接单方装运点可以创立交货单）不过不要太快乐地说“接单方装运点可以创立交货单，那么问题就解决了〞这句话。请问：我们的业务是什么？是直接由接单方向客人交货吗？如果是这样，那本文叙述这么多不就全成为废话吗？还有什么存在的价值？从业务本身而言，货并没有进入接单方2200的库存，而是直接由供货方1200发给客人，那么请问2200有什么理由创立交货单？（愤怒地）询问：供货方1200不能创立交货单，接单方2200可以创立交货单却不符合业务，那到底该怎么办？（沉着地）问答：这就是我们的下一步操作——修改销售订单，变更交货工厂根据接单方（2200）与客人的销售契约，允许从接单方的兄弟公司（即供货方1200）供货。既然实际交易的契约允许，那么我们当然可以把销售订单的交货工厂，从默认的2200变更为事实上的1200。变更操作很简单，步骤如下——事务代码VA02，输入记录下的销售订单号码，敲回车进去；在行工程级别，把工厂从默认的2200，变更为1200！敲回车确认；就这么简单吗？不，没那么简单。请选择行工程（摁瘪），点击上图下方的图标，进入行工程的“价格〞。请问：价格有什么变化？是不是如以下图所显示的那样，多出了一条可以修改的价格条件PI01？我们先记住这两个命题：①、价格PR00是接单方与客人之间的结算根本单价；②、价格PI01则作为接单方（2200）与供货方（1200）之间的内部结算单价的基础。随着后续测试的进行和结果分析，我们将验证这两个命题的正确性。切换到行工程的卡片夹shipping，我们可以看到，不仅工厂成为1200，装运点也成为1200了。把storagelocation的赋值输入为0001。菜单“edit→incompletionlog〞，确保订单没有缺失的内容，存盘。重新落实需求方案MD04，观察接单方（2200）项下，大地白茫茫真干净：MD04，观察供货方（1200）项下，这回，需求元素可是实实在在的了。供货工厂（1200）的方案人员只要看到MD04中1200工厂项下的需求和存货，自然就了解供需对照状况。本例中，存货（Stock）量已足够覆盖需求（requirement）量，因此系统不会产生方案单（如果是内部获取）或者采购申请（如果是外部获取，物料类型HAWA是tradinggoods，外购商品，即所谓“左手买进右手卖出的东西〞，一般就是外部获取）。供给工厂创立交货单供货工厂1200的存货已经到位，那么当然就可以向客人交付了。系统内的操作步骤如下——事务代码VL01N，输入装运点1200，输入销售订单号。日期必须可以覆盖销售订单中的要求交货日期。如以下图——敲回车后，这回系统准许交货工厂创立交货单了。存盘，记录下交货单号码。刷新M-01在工厂1200项下的MD04显示。可以看到需求元素变更为交货单。供给工厂拣配在绝大多数客户化SAP实施工程中，交货单创立完毕，打印出来就可以过账发货了。然而这是IDES系统，为了不影响其他同事全面学习和测试SAP的功能，我们没有修改交货单与交货行工程的定制，因此我们的交货单行工程中，有两个醒目的状态，如以下图——这两个状态的赋值，要么空白（即“无关〞），要么就必须是C（即“已完全处理〞），其余状态如A或者B都无法过账出货。那么，怎么做呢？以下是步骤——事务代码VL03N，输入交货单号。进入行工程的卡片夹“picking〞项下，把仓库号（Warehousenumber）抄下来。退出交货单。事务代码LT03，输入仓库号、工厂代码和交货单号，其余不问，如以下图——上图敲回车后，进入处理界面。滑鼠放在交货单行工程任何一个位置，再点击上方的大图标系统马上在卡片夹“processeditems〞下，把交货单及其行工程转移过去了。存盘。系统告知。熟悉WMS的参谋应该知道，转储订单（transferorder，TO）创立之后需要确认（confirmation）。不过在IDES系统中，根据WMS的有关定制，交货单环节的TO创立成功后即自动确认。用LT21验证，以下图的状态图标及其文本说明，相信已经把意思表达得很充分了。VL03N，重新显示交货单，看看状态如何——退出交货单的读操作界面，本步骤结束。供给工厂过账出货拣配完成，可以出货了。开两个会话（session），一个MD04观察M-01的存货/需求对照，另一个VL02N执行过账发货操作。事务代码VL02N，输入交货单号，点击那个大大的图标“Postgoodsissue〞。点击图标的操作非常简单，叙述从略。点击过账后，MD04的结果显示如下，存货减少，需求元素姿消。VA03显示销售订单的凭证流（documentflow），可以清楚地追溯到交货单、拣配单和物料凭证的信息。发的是工厂1200的货，而工厂1200又附属于公司代码1000，这笔货不能不明不白，因此公司代码1000项下，当然将产生一笔会计分录。接单方出票，向客人收款事务代码VF01，参照已过账出货的交货单创立标准发票（F2）。过程从略，结果如下——我们需要验证两个问题：1.出具销售发票依据的单价是哪个？2.会计凭证中的价值是怎么计算来的？对外销售发票的单价VF03显示销售发票，观察其PR00的单价和价值。净单价811，数量5，净合价=811x5=4,055；税率20.6%，税额=4055x20.6%=835.33；价税合计=净合价+税额=4,890.33。SAPIDES系统可不像咱们在中国国内做的以含税价定价的工程，它是不含税价。不含税价的算法当然如上述方式去计算。也就是说，本笔交易对客人收取的总应收款项，就应该以4,890.33为基础。问题在于：会计上也是这么认为的吗？请看下一节——会计凭证的价值分析嘿，会计还真是这么认为的！整个会计分录是——借：客户应收账款4,890.33贷：销售收入4,055.00应付销项税金835.33瞧仔细了：对客户的外部发票是接单方（2200）出具的，公司代码当然就是2200。供给方出票，向接单方收款如果是常规的销售业务，2.8段落执行完毕后，物流模块（Logistics）的流程就全部结束了，因为后面的收款和清账纯属财务上的操作，与物流无关。然而本案所述的流程中，事情并没有结束，因为供给方（工厂1200/公司1000）作为一个会计核算主体代替另一个会计核算主体（接单方2200公司）履行了交货义务，它的权利还没有得到交代。因此，供给方需要对接单方出票，主张自己的应收账款。怎么主张？答案很简单：VF01，对交货单“二次出票〞！操作步骤如下描述——VF01进去。在下方的单据中，再次输入交货单号！插话：等等，先别急着敲回车。就这样，你就能创立第二张发票吗？答复：是的，就这么简单。追问：在字段BillingType中，你难道就不想输入一点内容吗？答复：嘿，我还真就不想输入任何内容，我现在就敲回车给你看——回车一敲，系统真的创立一张新的发票，而且选择的billingtype不是F2，而是IV。在标准的SAP定制中，IV就是“公司间结算的发票类型〞！存盘，先产生发票号和会计凭证，接下来再分析。问题：为什么两张发票号码，产生的会计凭证号相同？答复：请带着你的问题看下面的分析。看完分析，自然就知道原因了。内部结算发票的单价VF03显示内部结算发票（IV发票），观察其ZIV1的单价和价值。ZIV1的单价作为计算基础，数量5PC，净单价=183x5=915.00；没有销项税。我们不必纠结于“这个是否符合中国的税务实践〞，只看算法是否正确即可。那么供给方公司1000向接单方公司2200的应收账款，就应该是915.00。挑战：“这不过是你的猜想，会计上也这么认为吗？〞应战：看看会计分录怎么说——会计凭证的价值分析上帝，会计分录还真应验了我的推测，上图的会计分录用白话文来表达如下——借：客户应收账款915.00贷：关联销售收入915.00瞧瞧，aff.是“affiliate〞的缩写，affiliate的含义就是“关联公司交易〞，多么贴切的总账科目。瞧仔细了，这张会计凭证是公司代码1000出具的，与上一张对客人销售发票的会计凭证主体有所不同。在SAP系统中，不同公司代码项下的某一类会计凭证，其号码范围是可以分开定义的，因此1000公司和2200公司的第一张销售发票会计凭证的号码相同就不难理解。这个命题，财务参谋会告诉你在哪里定制，本文就不再掠美。接单方成认对供给方的应付账款提问：三角交易中，接单方（2200）对客人的发票出具了，供给方（1200）对接单方的内部结算发票也出具了，流程是不是就该结束？答复：还没有，因为接单方还没有成认对供给方的应付账款义务。这就是“同一企业集团项下不同会计法人主体之间的关联交易〞必须考虑的要素：一方对另一方主张权利，不等于另一方同时成认义务。提问：那么接单方又该怎么“成认〞呢？应付账款的产生，只可能来源于两个渠道，要么从采购模块的发票校验产生，要么是在FI模块中手工做账，是不是？答复：说的很到位，确实如此。追问：可是本文行文至此，根本就没有出现采购订单，更没有收货。这不是STO业务，接单方与供给方之间没有采购订单和收货记录，怎么做发票校验？难道是直接在FI模块中用事务代码FB01直接手工创立会计凭证这种“流氓方式〞吗？答复：您还真说对了，确实是FB01，但操作者不是接单方（2200）的会计人员，而是系统的IDOC功能！因此，不能说是“手工创立应付账款凭证〞，而是“系统驱动IDOC自动创立〞。具体的机制后面再阐述，我们先只看结果，步骤如下——事务代码FBL1N。供给商代码输入10000，公司代码输入2200，“openatkeydate〞维持系统默认的当前日期，其余不问。点击图标进入。系统显示如下。很明显，画红框的才是本案的记录。点击上图凭证前面的小方框，再点击图标，进入以下图不必领会其他内容，直接点击上图的图标。图穷匕首现。流程至此才算全部结束。很显然，人工FB01与本文所述的系统IDOC触发FB01操作，哪个“更具有技术含量〞，不言自明。

技术原理剖析有一个SAPNOTE叫做31126，阐述的就是如何在“跨公司出票〞（Inter-CompanyBilling，ICB）场景下使用SAPEDI技术（ElectronicDataInterchange，电子数据互换）直接在FI模块中过账到供给商库存而执行正确的系统设置。本局部内容就以这个NOTE为参考线索，结合作者个人体会而叙述。序曲–组织单元的设计首先必须搭建这个业务中所涉及的有关接单方（SellingParty）与供货方（SupplyingParty）的组织结构，包括公司代码、工厂代码、采购组织、销售组织、销售区域组合（即销售组织·分销渠道·产品组的组合）等组织单元，以及此类组织单元之间的分配关系。公司代码作为SAP参谋，公司代码的配置路径再熟悉不过了，不再赘述。在IDES系统中，供货公司1000和接单公司2200已存在，且地址数据完备。自定义的公司代码，地址数据必须完备。所谓“完备〞的标准，是“不要让SAP系统报错存在缺失‘必须输入’的数据〞即可。工厂代码同样的理由，工厂代码的配置路径不再赘述。在IDES系统中，本案有关的供货工厂1200和销售工厂2200也已存在，且地址数据完备。自定义的工厂代码，地址数据仍然必须完备，标准同上。公司代码与工厂代码之间的分配关系事务代码OX18，完本钱案公司代码与工厂之间的分配关系。很显然，IDES中已经完成。作为一个常识，应该知道：公司代码项下可以有多个工厂，但工厂只能效劳于一个公司代码。接单方与供货方的销售组织配置路径或事务代码从略。IDES里已存在接单方和供货方的销售组织。接单方与供货方的销售区域组合与本案有关的销售区域组合，在IDES项下已经存在。自己寻找配置路径或事务代码。接单方与供货方的销售组织和渠道对各自工厂的匹配关系IDES中，无论是接单方还是供货方，销售组织与分销渠道对各自工厂的匹配关系已经定义。自己寻找配置路径或事务代码。接单方的销售组织和渠道对供货工厂的匹配关系在接单公司的自有工厂无法供货的情况下，它当然要寻求供货公司的工厂。因此，必须完成接单方的销售组织（2200）和有关渠道与供货工厂（1200）之间的分配关系。这个配置可以说是ICS业务得以实现的基石，切记、切记！接单方和供货方各自装运点与工厂的匹配关系事务代码OVXC，为工厂分配装运点。IDES系统早已分配完毕。作为常识应该知道：一个工厂项下可以有多个装运点，但一个装运点不能效劳于多家工厂。接单方的采购组织设置在本案所述的三角交易关系中，接单方（2200）相当于是从供货方（1200）购置商品。虽然在整个流程中没有出现任何采购订单，但这不等于采购组织没有定义的必要。SAPIDES中，接单方2200的采购组织就是它自己的部门或者团队，即2200。以下图显示的是工厂代码2200项下所有的采购组织配置状况。配置路径，请自己寻找。慢板–主数据的准备和局部关键定制以接单公司的立场，创立供货公司的供给商主数据很明显，本案中，接单公司是2200，供货公司是1200创立供给商主数据的事务代码是XK01，这个事务代码意味着组织结构的选择不仅要选择公司，还要选择采购组织。公司代码当然是2200，采购组织按3.1.9段落的描述，也是2200。创立主数据的过程从略，作者只想强调的是：供给商号码与工厂之间必须关联！供给商与工厂关联的含义，在于以下步骤——对创立完毕的供给商，启动事务代码XK02（MK02也行），输入供给商号、公司代码、采购组织后，只点击“Purchasedata〞。如以下图：敲回车进去后，菜单“extra→additionalpurchasedata〞。系统跳出一个对话框。在对话框里，输入工厂代码1200。这就是所谓的“将集团内供给商与工厂组织给关联起来〞，MM模块主导的STO业务也有这个操作！存盘退出。以供货公司的立场，创立接单公司的客户主数据创立客户主数据的事务代码是XD01，这个事务代码意味着组织结构的选择不仅要选择公司，还要选择销售区域。公司代码当然是2200，销售区域组合按我们在前面章节的描述，销售组织=1000、分销渠道=12、产品组=00。创立过程从略，IDES系统里已有现成数据，但作为ICS业务的关键实现要素，下面几个要点必须强调——页签“Sales〞项下，字段CustomerPriceProcedure。不同工程对客户定价程序的设置详略程度不一样，像咱们公司的工程中，公司间交易是I，标准销售是1。不过在IDES系统里，内部客户的客户定价程序与常规销售相同，也是1；同样的页签“Sales〞，字段“Acctatcust.〞，非常重要。只能是10000。问：为什么要输入10000？答：这个字段是什么意思？“我们在客户方的账号〞。“我们〞是谁？对于接单公司2200而言，我们是不是它的供给商？既然是供给商，总得有个号码标识，我们的供给商号码标识，3.2.1段落说的还不够清楚吗？根据SAPNOTE31126的说明，如果要启动IDOC完成供给商账户的自动过账，字段“Acctatcust.〞必须输入正确的值！页签“Billingdocuments〞项下，字段“Acctassgmtgroup.〞，与外部客户不同。IDES中是03，文字“Ap.reven.〞，已经把“关联公司收入〞的含义表达得很清楚了。同样页签“Billingdocuments〞项下，字段“Taxcl.〞。IDES中是0，这也是本文2.9段落中描述的“内部结算发票〞的税率为0的根本原因。至于这个设置“是否符合中国国情〞，不在本文讨论范围，自辨。物料主数据的组织单元覆盖物料既然可以被接单公司（2200）下销售订单，它就必须维护2200工厂项下的数据、以及维护销售组织2200·分销渠道10·产品组00项下的数据。物料既然可以被供给工厂（1200）交付，它就必须维护1200工厂项下的数据。物料既然可以被供给公司（1000）开内部结算销售发票，而销售发票离不开销售区域，因此还必须维护销售组织1000·分销渠道12·产品组00项下的数据。具体过程不再赘述，只看以下图所表达的结果——物料对外销售价格主数据事务代码VK11，条件类型PR00，选择最下方的“materialwithreleasestatus〞。物料=M-01，销售渠道=2200，分销渠道=10，有效期自己定。结果如下——可以回想一下：在2.1段落下订单时，PR00单价是不是默认自动带出来的（尽管是“白色可修改〞）？在已经存在物料销售价格主数据的前提下，用VK12修正或者VK13只读即可。物料对内结算价格主数据事务代码VK11，条件类型PI01。Keycombination只有一个选择。Salesorganizationfororder，当然填写2200，因为与客人签署销售订单的销售组织是2200；Plant，则必须填写1200，因为这是出货的工厂。下方物料号当然填写M-01，价格据实录入，有效期自定。作为IDES系统，已经定义了，请用VK12或者VK13观察。追问：不对，请等一等！你维护的是PI01，可是2.9.1段落中内部结算发票的截图很清楚，生效的是ZIV1的价格。这是怎么一回事？答复：你确实看得很仔细。下面的定制马上答复你的疑问——内部结算发票价格条件的特殊定制细节事务代码V/06，定位到ZIV1，也就是你看到的内部结算发票的价格条件。进入其详情——答案揭晓：ZIV1在执行销售业务中，将从PI01的现有记录中参考取值。关于“referenceconditiontype〞的用途，请自己参阅SAP在线帮助文档并自己测试，本文不再赘述。进一步讲，你可以启动事务代码VK11直接创立ZIV1的价格主数据，来看看系统会告诉你什么信息——跨公司销售订单和发票的定价过程确定事务代码OVKK。这个事务代码答复“系统如何抓取不同的定价过程和主条件类型〞。按以下变量挑选——Salesorganization=1000（供货方出具IV发票）Distributionchannel=12Division=00Customerpricingprocedure=1Documentpricingprocedure=I结果如以下图——不明白为什么“documentpricingprocedure〞要选I，是不是？事务代码VOFA，自己观察F2和IV，看看它们的字段“documentpricingprocedure〞各自是什么？作为接单方2200，它与客人签署的OR标准销售订单，定价过程则是RVAA01。它对客人出票的定价过程，也是RVAA01。其中的原理，请自己用上述方式去找寻，不再赘述。跨公司销售订单或发票的定价过程细节事务代码V/08。这个事务代码答复“定价过程是怎么样的构成结构〞。销售订单与外部发票的RVAA01定价过程，PR00是主价格，而PI01也是其中的一个条件类型，而且也对应到销售收入的账码（ERL）。然而更值得关注之处，在于它的requirement赋值22。无论是采购订单的定价还是销售订单的定价，requirement都表示“只有在满足例程所规定的算法条件下这个价格才有效〞。例程22的详情，请自己用事务代码VOFM去阅读其代码程式，本文不再赘述。内部结算发票所采用的ZIV001的定价过程，其配置详情，同样用V/08去观察。相对应的核心条件类型是ZIV1。自己看去，不再赘述。协奏–发票类型的输出的配置和数据准备为公司间交易发票类型分配输出确定程序事务代码：V/25作为比照，标准发票的输出类型是RD00。定义输出确定程序事务代码V/42。公司间发票的输出确定程序V40000的具体详情如以下图所示——作为比照，不妨看看常规发票的输出确定程序V10000的详情：输出类型RD04的定制事务代码V/40。看看，RD04的传输介质是什么？不怕不识货，就怕货比货。标准发票对应的输出类型RD00，它的介质又是什么？所有的SAP输出类型，都有程式（program）、表单例程（routine）和表单（form），当然表单是可以自定义的。标准IDES中的EDI传输介质并没有定义表单（Form）。熟悉SAP“条件技术〞（Conditiontechnique）的参谋都知道，条件类型（conditiontype）是定制概念，条件类型要想读取前台作业人员创立的主数据，就必须为它定义一个存取顺序（accesssequence）。输出（output）应用的，也是“条件技术〞的一种形式，因此输出类型也有存取顺序，这个存取顺序就是以下图所示的0004。为接单方的客户号维护RD04输出条件的主数据事务代码VV31。输入RD04，敲回车。点击图标keyconbination，跳出的组合只有一个，如以下图。这是因为RD04的存取顺序0004所确定的表格只有一个，如以下图：回到VV31维护输出主数据，结果如下。显然，IV发票的发送者（sender）是供货公司，上方的销售组织当然是供货方的销售组织1000。创立完毕后，存盘退出。已经存在记录的，用VV32修改或者VV33只读。盘旋–公司间发票的系统配置本段落的配置根目录：IMG→Salesanddistribution→Billing→Intercompanybilling，如以下图。这是本段落项下的“总配置目录〞。销售订单类型配备公司间发票类型配置路径：配置根目录→Defineordertypesforintercompanybilling。定位于标准订单类型OR，如以下图把发票类型IV填写进去。这个配置意味着当接单方（2200）向外部客人签署的标准销售订单变更供货工厂（即变更为1200）时，系统可以允许已经过账发货的交货单被“二次开票〞，且“二次开票〞的默认发票类型就是IV。经测试可以证明：本段落的定制，与VOV8定义销售单据类型是完全等价的。如以下图所示：把接单公司之销售组织的内部客户号确定下来配置路径：配置根目录→Defineinternalcustomernumberbysaleorganization在接单公司的销售组织（即2200）一行，填写3.2.2段落所创立的客户主数据号码填进去。提问：为什么供货方（1000）的销售组织也被维护了客户号码呢？答复：就本文所描述的场景而言，您确实可以不维护。维护了就表示1000销售组织同样可以作为“跨公司销售的签约方而被其他的兄弟公司出具公司间结算发票〞。不过这是IDES系统，咱维持不变。指定EDI传输的供给商逻辑地址配置路径：配置根目录→Automaticpostingtovendoraccount(SAPEDI)→AssignVendor事务代码：WEL1结果如以下图所示：维护说明如下：逻辑地址（Log.addr.）：以供货公司（即本案的1000）的立场来命名，结构是“供货的公司代码+接单公司表达为供货公司的内部客户号〞。这里需要强调：如果客户号码是内部编号（即全部是数字），那么逻辑地址必须凑足14位数，缺乏的局部，按下表所示的结构进行填充——性质供货公司用0填充客户号位数1234567891011121314赋值10000000022000目的端（Destination）：以接单公司（即本案的2200）的立场来命名。CompanyCode当然就是接单公司本身，即2200；Vendor就应该填入供方公司在接单公司项下的供给商号码，即10000。追问：本文的例子，无论供给商还是客人，号码都是内部编号（即全部是数字），然而在我们的XX工程中，公司代码固然都是数字，内部客户号和内部供给商号却是类似于C3430、C2000之类的编号。如果我们的场景是：公司代码2000（内部客户号C2000）对客人签单，公司代码3430（内部供给商号C3430）履行交货职责，那么逻辑地址又该怎么定？答复：逻辑地址如下表，即不需要凑足14位数。性质供货公司客户号位数123456789赋值3430C2000而目的端，公司代码则是2000，供给商当然是C3430了。注意：这个定制非常关键，它是被发送的EDI信息找到“接收方〞（recipient）的根本定制。高潮–IDOC内核与财务端的设置维护IDOC处理的端口事务代码：WE21在IDES中，已经有许多端口（port）了，我们只需要关注A000000009是否存在于文件夹“TransactionalRFC〞即可。定义客户的伙伴参数文件事务代码：WE20点开文件夹“PartnerTypeKU〞，创立客户22000。详细内容如下——页签“Postprocessing:permittedagent〞项下，Ty.默认为US（SAP用户）、Agent默认为当前操作人的用户ID、Language默认为当前系统的登录语言。这些信息维持默认值即可关键在于Outboundparameters（出埠参数），必须输入两行，如下表所示：PartnerRoleMessageTypeMessageVariantBPINVOICFIBPINVOICFI点击放大镜图标，信息变式（messagevariant）FI的详情如下：页签“outboundoption〞项下，以下图标注局部是关键要素；页签“Processcontrol〞项下，应用只能是V3，讯息类型是RD04，处理代码是SD08；其余页签维持默认值。点击放大镜图标，信息变式（messagevariant）MM的详情如下：页签“outboundoption〞项下，以下图标注局部是关键要素；页签“Messagecontrol〞项下，以下图标注局部是关键要素；其余页签维持默认值。在Partnerprofile的表头层面，第二个页签classification，Partnerstatus必须赋值为A。其余不问。新建的伙伴参数文件必须存盘才能生效。定义供给商的伙伴参数文件事务代码：WE20点开文件夹“PartnerTypeLI〞，创立供给商10000。详细内容如下——表头的要求，与客户伙伴参数一致，不再赘述；下方的细节，维护的是inboundparameter（入埠参数）。不需要partnerrole（因为inbound是被动接受），messagetype都是INVOIC，分别维护FI和MM的变式。变式FI的细节简述如下——页签“inboundoption〞，关键如下：其余页签无特别要求。变式MM的细节简述如下——页签“inboundoption〞，关键如下：其余页签不做特别要求。为EDI接收发票定义程序参数事务代码：OBCE。配置路径自己找，以下图是例如——选中以下图红框与本案有关的那一行，再点击图标——配置详情如下所述——请回忆本文2.10段落中的截图，系统自动产生的会计凭证的类型是RE，是不是？这个RE，就是由上图的定制确定的。为EDI接收发票分配公司代码事务代码：OBCA。定位于Partnertype=LI、Partnernumber=10000，即本案有关的供货公司，它们是接单公司的供给商。最右边的Cocd字段中，输入本案有关的接单公司的公司代码，即2200。根据SAP的文献原文描述——ByleavingthefieldCOCDblank,allcompanycodesareavailable。理解为“如果最右边的字段COCD维持空格，系统就默认为供给商10000可以对任何它存在数据记录的公司代码都触发EDI动作创立会计凭证〞。请自己验证。为EDI接收发票分配总账科目事务代码：OBCB。如以下图，在系统跳出的小框中，依次输入LI（供给商）、10000（供货公司表达的内部供给商）和2200（接单公司的公司代码）。上图敲回车进去后，按财务要求输入总账科目，文本字段是可选择工程。IDES系统内是空白，维持不变。当然，这个总账科目必须是事先在公司代码中创立好的科目主数据。需要注意的是：总账科目不可以与CO模块的任何对象挂钩，即它不能是本钱要素（costelement）。具体详情，请咨询FI/CO的参谋。为EDI接收发票分配税码事务代码：OBCD。本定制的作用，在于把来源于销售订单中的销项税（outputtax）与供给商发票中的进项税（inputtax）关联起来。定位到LI·10000的行，确保你交易中可能出现的销项税码能够关联到进项税码。字段“Taxtype〞，用来记录销项税税码（Outputtaxcode）；字段“Tx〞，用来记录进项税税码（Inputtaxcode）。马上产生了问题：我怎么知道供货方内部结算发票的销项税税码是哪个？答复：找到那张内部结算发票的号码，VF03显示。进入行工程的“Condition〞页签，如以下图：点击上图的图标后，定位到MWST“销项税〞那一行，点开，找到有值的那个访问顺序，如以下图：按上图的箭头所指，滑鼠点击，系统马上把你导引至条件价格主数据的界面如以下图——选中MWST那一行（摁瘪），再点击图标。如以下图所示，找到销项税税码。作为SD参谋，你真不应该提这个问题，因为这是SD参谋的根本功。EDI接收发票的总账科目的数据要求3.5.6段落所描述的总账科目（607010）的主数据，存在一定的要求。FS00，进入总账科目在公司代码2200项下的数据，如以下图所示强调两个要点：页签“controldata〞项下，taxcategory必须“允许输入进项税〞。这句话的意思是：“既允许输入销项税，也允许输入进项税〞。IDES如以下图的选项是“只能允许进项税〞，显然更加严格，当然满足这个条件——页签“Create/bank/interest〞项下，旧版本（4.7以下，含4.7）是“允许手工过账〞，新版本（4.7以上，即ECCX.0）则是“Postautomaticallyonly〞（只能允许自动过账）。那么在旧版本下，标志就得点上；新版本下，标志恰恰相反就不能点上。其余数据要求，按自己的需要自行处理，与IDOC无关。尾声–计量单位的定制和EDI凭证价值分析计量单位的特殊定制要点请回忆3.5.4段落中关于EDI接受发票的程序参数，最下方有个单位。这个计量单位的定制，有点“小小的讲究〞。用事务代码C