创建Info Record的几种方法

本文介绍在SAP系统中通过报价及采购订单等不同方式自动创建或更新采购信息记录的方法。具体包括通过报价自动创建信息记录的不同选项及其影响,以及在采购订单和框架协议下信息记录的创建与更新规则。
部署运行你感兴趣的模型镜像

详细图片请参考附件。

 

创建SAP采购中重要的主数据之一info record有如下3种方式:手动(ME11);通过Quotation自动创建;通过PO或者outline agreement自动创建;

看一下后两种方式:

首先ME13确认,并不存在一个我们想创建的info record

 

之后创建相关物料的RFQ并作Quotation

注意Quotation中的这个字段InfoUpdate 其中有如下选项:

         No update

A       Update with or without plant

B       Update with plant (if no plant ban)

C       Update without plant (if no plant requirement)

我们首先选默认的No update 然后对报价进行保存,ME13可以看到依然没有Info Record被创建,因为是No update

如果选择A,相应的condition都会被这个报价中的price所更新。

但是更新规则如下,如果有plant level的话,相应的plant level会被更新,如果没有的话,更新general level

我们来确认一下。

 

 

 

但是我们会发现一个现象,那就是再次查看这个报价,会发现InfoUpdate自动变成了C,也就是without plant,而且info record中也会提示没有plant specific的数据。这是因为我们之前没有维护过任何和plant相关的数据,根据A的规则,创建通用数据的condition。而因为没有plant数据,所以这个flag也变成了C,也就是说维护与plant无关的condition

如果之前我们先创建一个与工厂相关的Info record,然后再选择flagA的报价,看看condition是如何更新的。

 

可以看到,如果这样做的话,与工厂相关的info rec.就被更新了,而general级别的却还是没有condition。而报价中的flag也自然而然的自动变成了B,也就是说如果没有工厂,则不做更新。

用报价来创建和更新info record就是这个道理。

如果在PO中呢?PO中并不会更新condition。而只是影响info record中的last PO number一个字段而已。如果创建PO时没有info record则会创建一个,但是依然不会带入任何价格信息。

 

outline agreement中,对于contract来说,如果在创建contract的时候没有Info Record存在,则选择了相应的info update类别后,会创建新的info record,并更新condition信息,如果在创建contract的时候系统中已经有了info record,则不会更新condition信息。

对于scheduling agreementcontract release order来说,不会更新condition信息,与PO一样,之更新last document字段。

 

备注:

我们以上的实验前提都是在condition可以存在于Plant level的前提下。条件永远都与采购组织相关联,但是也可以设定为与plant相关。默认情况下,我们一般都会允许工厂级别的条件存在,配置更加灵活,除非需求真的是将所有工厂都统一用一个价格。这个在后台的配置中

Purchasing -Conditions-Define Condition Control at Plant Level

可以指定是否只允许工厂级别的条件存在;是否不允许工厂级别的条件存在

如果我们不允许工厂级别的条件存在,则ME11指定工厂时会得到错误消息。

 

您可能感兴趣的与本文相关的镜像

Stable-Diffusion-3.5

Stable-Diffusion-3.5

图片生成
Stable-Diffusion

Stable Diffusion 3.5 (SD 3.5) 是由 Stability AI 推出的新一代文本到图像生成模型,相比 3.0 版本,它提升了图像质量、运行速度和硬件效率

### 编写测试用例的方法和最佳实践 #### 黑盒测试方法论 黑盒测试关注的是软件的功能需求,而不考虑内部结构或工作原理。这种方法通过提供各种输入并验证输出是否符合预期来进行测试。为了确保覆盖尽可能多的情况,可以使用边界值分析、等价类划分和其他技术来设计测试用例[^1]。 #### 白盒测试方法论 相比之下,白盒测试则深入到程序代码层面,基于对逻辑路径的理解构建测试场景。这有助于发现隐藏于实现细节中的缺陷,并能有效评估代码质量。对于复杂算法或者安全性要求较高的模块尤为适用。 #### 创建清晰一致的模板 无论采取哪种方式,在编写具体实例之前都应该先建立一个标准化格式作为指导方针。一份完整的文档应当至少包含以下几个部分:唯一编号(用于追踪)、简洁明了的任务说明、详细的执行步骤指引以及期望得到的结果描述;另外还应该设立评判标准以区分成功与否的状态[^4]。 ```python def create_test_case(test_id, description, steps, input_data, expected_output): """ Creates a structured test case. Args: test_id (str): Unique identifier for the test case. description (str): Brief explanation of what is being tested. steps (list[str]): Ordered list of actions to perform during testing. input_data (dict): Data required by the system under test. expected_output (any): The anticipated outcome after running tests. Returns: dict: A dictionary representing a fully formed test case record. """ return { 'Test ID': test_id, 'Description': description, 'Steps': steps, 'Input Data': input_data, 'Expected Output': expected_output } ``` #### 自动化工具的应用 随着DevOps文化的普及和技术进步,越来越多的企业倾向于利用专门开发出来的框架和支持库来自动生成甚至运行这些脚本文件。Python语言配合Selenium WebDriver这样的组合非常适合Web应用程序接口(API)级别的回归检验作业[^5]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值