SAP SD学习笔记17 - 投诉处理3 - Credit/Debit Memo依赖,Credit/Debit Memo

上一章讲了 请求书(发票)的取消。

SAP SD学习笔记16 - 请求书的取消 - VF11-CSDN博客

再往上几章,讲了下图里面的返品传票:

SAP SD学习笔记14 - 投诉处理1 - 返品处理(退货处理)的流程以及系统实操,比如 返品传票;请求Block标记;收到退货之后的处理,请求传票的登录_销售退货 sap-CSDN博客

SAP SD学习笔记15 - 投诉处理2 - 返品处理流程之 参照请求传票(发票)来生成返品传票-CSDN博客

本章继续讲本图中的内容:Credit/Debit Memo依赖。

目录

1,Credit/ Debit Memo 概要

2,在系统上做Credit Memo依赖

2-1,VA01 标准受注登录

2-2,VL01N 出荷传票登录

2-3,VF01 请求书登录

2-4,VA01 受注传票登录 - Credit Memo依赖

2-5,VF01 请求传票登录

2-6,传票Flow

3,直接做Credit Memo

3-1,数据准备

3-2,VF01 请求书传票登录

3-3,传票Flow


下面是详细内容。

1,Credit/ Debit Memo 概要

Credit Memo依赖究竟是个什么东西呢?

其实就是说客户对这个商品的意见可能不是主要集中在商品本身,而是包装啦,或者只是商品本身有轻微的擦痕,不影响使用,只影响心情。

那么TA打电话抱怨,你难道也要给退货吗?商品本身不影响使用,那一般处理方式可能就是便宜点给TA嘛,这样TA也决定OK的话,这事儿就了了。

在系统上就是通过Credit/Debit Memo来减价/加价,不涉及到品目的移动。

下图是Credit Memo依赖的处理概要。

注意下图中 Credit Memo依赖(クレジットメモ依頼)的特点:

- Credit Memo依赖 的来源有 两条线

  - 受注传票

  - 请求传票

- Credit Memo 的来源有 一条线:

  - 请求传票

然后再注意到另外两个个点:

- Credit Memo依赖 在承认 之后,可以生成 Credit Memo

- 受注传票和 Credit Memo之间是没有直接关系的,要经过Credit Memo依赖,承认之后才可以。

  Credit Memo依赖 本质上是一张受注票;Credit Memo 本质上是一张请求票。

  在现场,比较常用的是 Credit Memo依赖 --》承认?--》Credit Memo,

  原因和之前学习的 请求Block 标记相同,都是为了给员工 和 上司之间加一个承认的动作。

2,在系统上做Credit Memo依赖

先做一下数据准备。

2-1,VA01 标准受注登录

2-2,VL01N 出荷传票登录

点 Menu > 后续机能 > 转送指图登录

点 转送指图明细生成,然后点保存

回到VL02N,点出库确认

2-3,VF01 请求书登录

直接点保存

回到 VA03,点传票Flow

这样数据准备就做好了。

然后哎,客户投诉来了,经过交涉,客户接受不退货,但是要价格要优惠有些。

下面在系统上来做Credit Memo依赖。

2-4,VA01 受注传票登录 - Credit Memo依赖

- 受注Type: CR - Credit Memo依赖

和返品处理的时候一样,Credit Memo依赖也是有两种做法

- 参照受注票

- 参照请求书(发票)

咱们这里就不一一做了,做法,以及两者的区别,跟做返品处理一样,具体可以参照下面文章:

SAP SD学习笔记15 - 返品处理流程2 - 参照请求传票(发票)来生成返品传票-CSDN博客

这里我们做一下 参照请求书那条路。

输入 请求传票,然后点 Copy图标。

默认 请求Block 被设定上了

输入 受注理由,然后点保存

如果数量超过受注数量,比如这里 2改为3,那么会出一个Warning Message

参照伝票数:                   2 ST - 参照合計数:                   3 ST
Msg 番号 V1494

注意咱们在下面一章里面Customize过 V4229 ,将 Warning 改为 Error,

但是这个 V1494 好像是改不了,SAP在代码里面写死了:😓

那你要想像 V4229 那样弄成 Error,不让过,那么只能做Addon增强了。

SAP SD学习笔记15 - 返品处理流程2 - 参照请求传票(发票)来生成返品传票-CSDN博客

双击一下明细番号(比如 10)

点一下 条件 Tab

这里面调整的就是 优惠的额度,比如每个便宜300 块钱,那么这里就写 300

要是全写上,表示全额退款,而且东西也是不要了。

所以,在业务上,到底是该用 返品,还是该用 Credit Memo依赖,要以什么为判断依据呢?

就是有没有货物移动,即客户到底把货给我退回来,还是不退回来。

如果退回来,就用返品;如果不退回来,只是价格的减增,那么就用Credit/Debit Memo依赖。

比如不能开封的东西,客户开封了之后要退货,那也只能全额退款,然后东西就别拿回来了,要不还得再次处理。

咱们这里写上 300,回车,然后点保存

Credit Memo依赖 番号:60000088

根据咱们上面的学习,知道该Credit Memo依赖 票是不能做出荷(入荷)的,咱们这里来试一下。

因未在 Table TVCPL 中登録,所以无法Copy: G2
Msg 番号 VL473

看着Message内容挺怪的哈,其实就是因为它天生就不是干那玩意儿的。

只是调了调价格而已,不涉及到入出库的。

2-5,VF01 请求传票登录

到 VF01 里,做请求书登录试试看。

請求伝票没有生成,请参照Log。
Msg 番号 VF032

点一下 Menu > 编集 > Log

该 0060000088 000000 伝票,做 請求処理时 被Block。

嗨,还记得那个 请求Block 标记嘛,就是那个没拿掉呢。

映射到现实中,就是Lead还没批呢。

VA02 - Credit Memo依赖变更,将请求Block设为空,然后保存

- 请求Block:空

回到VF01,这回就可以了,直接点保存

2-6,传票Flow

回到 VA03,点一下传票Flow

Credit Memo依赖 ( 0060000088 ),本质就是受注票(都是用 VA01 作成的)

Credit Memo ( 0090038099 ),本质就是请求书 (都是用 VF01 作成的)

再贴一下这张图,看着是不是有点儿感觉了😄

3,直接做Credit Memo

3-1,数据准备

跟上面的2-1 到 2-3 是一样的,我就不一一贴图了。

数据准备好之后的传票Flow如下:

这次我们跳过 Credit Memo依赖,参照请求书 直接做 Credit Memo。

3-2,VF01 请求书传票登录

直接给我报了个错:

伝票 90038100 (請求Type ) 在此事务中无法处理。
Msg 番号 VF169

这是为啥呢?

其实Message里稀里糊涂的,但是也提到了 请求Type

这个请求Type 需要设为 G2 - Credit Memo

默认呢,这个 请求Type是 F2 - 请求书,所以你不选个正确的,SAP就报错了

这样就进来了

双击 请求书那一行

这里显示的都是旧请求书的内容

再双击明细行,旧请求书的内容是改不了的

双击Credit  Memo 那一行,再双击明细行

这里的价格就可以改了。

比如改为 350,意思是 优惠了 350

回车之后,直接点保存

3-3,传票Flow

再贴一下 上面 2-6 的传票Flow,来对比一下

其实就是 2-6 多了个 Credit Memo依赖,其他的都一样。

也正因为有 2-6 这个受注票,所以做 VF01 的时候,SAP会自动提案 G2 - Credit Memo;

而 3-2 里面没做这个受注票(即 Credit Memo依赖),所以就需要你手工选择 G2。

<参照用>

本章主要讲了 Credit Memo 依赖和 Credit Memo。其含义如下:

- 当客户投诉时,经过交涉,发现其实问题不严重,商品本身是可以用的,只是有一些不完美,所以提案优惠价,客户也同意了,就需要登一张Credit Memo依赖票。

- Lead审核之后,解开请求Block,就可以参照 Credit Memo依赖票 生成 Credit Memo票(发票)

- 除了上面2步操作之外,SAP还提供了另外一种1步到位的步骤,

  即直接在 VF01 里登 G2 -Credit Memo票。

更多SAP顾问业务知识请点击下面目录链接

https://blog.csdn.net/shi_ly/category_12216766.html

<think>好的,我现在要处理用户的问题,关于访问特定URL时出现的Navigated提示。首先,我需要理解用户的具体情况。用户提供的链接看起来像是一个前端应用的页面,可能涉及财务或记账软件,带有多个查询参数。 首先,用户可能是在开发或测试环境中遇到了这个情况,比如使用nodemon启动服务器后,访问这个URL时页面没有正确加载,或者出现了错误。根据用户之前的提问历史,他们之前遇到了nodemon的启动问题,现在可能是在成功启动服务器后,访问特定页面时遇到了问题。 接下来,我需要分析URL的结构。URL中的查询参数包括voucher_number、voucher_date、attachments、total_debit、total_credit、notes,这些可能用于填充表单数据。可能的场景是用户正在测试凭证录入功能,通过URL参数预填表单,但某些参数值为空,比如total_debit和total_credit,可能导致前端处理异常。 用户可能遇到的问题可能包括:页面未正确渲染、参数解析错误、后端接口未正确处理这些参数,或者前端代码存在bug。此外,如果服务器没有正确配置静态文件路由,可能导致index.html无法加载,进而出现空白页面或404错误。 需要进一步考虑用户的开发环境。如果用户使用前端框架如React或Vue,可能涉及路由配置问题。例如,前端路由未正确匹配导致组件未加载,或者历史模式需要服务器端配置支持。另外,检查服务器是否正确处理了这些查询参数,并返回了预期的数据。 还要注意,用户可能在本地开发服务器(如webpack-dev-server或Vite)上运行前端应用,而后端API可能未启动或配置错误,导致前端无法获取数据。例如,total_debit和total_credit为空时,前端可能尝试进行数值计算,导致NaN错误或页面崩溃。 此外,用户可能未正确构建项目,或者依赖包未安装,导致资源加载失败。需要建议用户检查控制台日志(浏览器开发者工具中的Console和Network标签),查看是否有JavaScript错误或资源加载失败的情况。 总结可能的问题点: 1. 前端路由配置错误,无法正确解析URL路径或参数。 2. 查询参数中存在空值,导致前端处理异常。 3. 后端服务未运行或接口未正确响应,导致数据获取失败。 4. 静态资源未正确部署,导致HTML、JS或CSS文件加载失败。 5. 前端代码中存在逻辑错误,特别是在处理URL参数时。 接下来,我需要构建一个结构化的回答,引导用户逐步排查问题。首先确认服务器是否正常运行,然后检查前端路由和参数处理,接着查看网络请求是否成功,最后建议调试步骤,如检查控制台错误、验证参数传递等。同时,提醒用户确保所有依赖服务正常运行,并确保参数格式正确,避免空值导致的问题。</think>--- ### 一、URL 结构解析 你提供的 URL 是一个典型的**前端路由+查询参数**组合,其核心组成部分如下: ``` http://127.0.0.1:5529/jizhangruanjian/frontend/index.html ?voucher_number=1 &voucher_date=2025-03-10 &attachments= &total_debit= &total_credit= &notes= ``` | 组成部分 | 说明 | |--------------------|----------------------------------------------------------------------| | 基础路径 | `jizhangruanjian/frontend/index.html` 表示前端入口文件路径 | | 查询参数 | `?` 后为参数列表,用于向页面传递数据 | | 空参数值 | `attachments=`, `total_debit=` 等表示参数值为空 | --- ### 二、关键参数说明 #### 1. **凭证参数** | 参数名 | 作用 | |------------------|----------------------------------------------------------------------| | `voucher_number` | 凭证编号(示例值:`1`) | | `voucher_date` | 凭证日期(示例值:`2025-03-10`,需注意日期格式为`YYYY-MM-DD`) | #### 2. **金额参数** | 参数名 | 说明 | |-----------------|----------------------------------------------------------------------| | `total_debit` | 借方总额(当前为空,可能需要前端自动计算) | | `total_credit` | 贷方总额(当前为空,可能需要前端自动计算) | #### 3. **辅助参数** | 参数名 | 用途 | |----------------|---------------------------------------------------------------------| | `attachments` | 附件信息(当前为空) | | `notes` | 备注信息(当前为空) | --- ### 三、典型应用场景 #### 场景1:凭证编辑页面 通过 URL 参数预填充表单字段,实现快速跳转编辑: ```javascript // 前端代码示例:解析URL参数 const urlParams = new URLSearchParams(window.location.search); document.getElementById(&#39;voucher_number&#39;).value = urlParams.get(&#39;voucher_number&#39;); ``` #### 场景2:数据初始化 空参数值可能表示以下情况: - 前端需要根据其他数据源动态计算(如自动生成凭证编号) - 后端接口未返回必要数据 - 用户未填写必填字段 --- ### 四、常见问题排查 #### 问题1:页面显示空白 **解决步骤**: 1. 打开浏览器开发者工具(F12) 2. 检查控制台(Console)是否有 JavaScript 错误 3. 查看网络(Network)面板是否成功加载 `index.html` 和相关资源 #### 问题2:参数未生效 **验证方法**: ```javascript // 在浏览器控制台直接运行 console.log(&#39;当前参数:&#39;, Object.fromEntries(new URLSearchParams(window.location.search))); ``` #### 问题3:日期格式错误 **规范建议**: ```javascript // 日期格式校验示例 const isValidDate = (dateStr) => !isNaN(new Date(dateStr).getTime()); console.log(&#39;日期有效性:&#39;, isValidDate(&#39;2025-03-10&#39;)); // 应输出 true ``` --- ### 五、开发调试建议 #### 1. 参数安全处理 ```javascript // 防御性代码示例:处理空值 const totalDebit = parseFloat(urlParams.get(&#39;total_debit&#39;)) || 0; ``` #### 2. 使用路由框架优化 如果使用 Vue Router: ```javascript // router.js { path: &#39;/jizhangruanjian/frontend&#39;, component: IndexPage, props: (route) => ({ voucherNumber: route.query.voucher_number, voucherDate: route.query.voucher_date }) } ``` #### 3. 后端协作验证 检查服务器是否正确处理路由: ```bash # 测试API响应(假设使用Express) curl -I http://127.0.0.1:5529/jizhangruanjian/frontend/index.html ``` --- ### 六、安全风险提示 | 风险点 | 应对措施 | |-----------------------|--------------------------------------------------------------------------| | 未过滤的URL参数注入 | 使用`encodeURIComponent`处理动态参数 | | 敏感数据暴露 | 避免在URL中传递密码等敏感信息 | | 客户端计算依赖 | 关键计算(如金额合计)应在服务端验证 | --- ### 七、最佳实践建议 1. **参数标准化**:统一使用小写+下划线命名(如`voucher_date`) 2. **空值处理**:建议用`null`替代空字符串(`?total_debit=null`) 3. **文档化**:维护API文档说明参数格式: ```markdown | 参数名 | 类型 | 必填 | |----------------|---------|-------| | voucher_number | integer | 是 | | voucher_date | date | 是 | ``` --- 通过以上分析,可以判断该 URL 主要用于**凭证信息的预填充场景**。建议重点关注前端参数解析逻辑与后端数据验证的配合,确保空值参数不会导致页面异常。如果遇到具体功能问题,可结合浏览器开发者工具进一步诊断。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值