SAP 日本的标准程序締め請求(ISJP_CR)

相信在日本工作都离不开締め請求这个词，在fi债权中更是重中之重，本篇浅谈下在工作中遇到的问题

 会计凭证有几个项目和本次的締め請求有关，比如転記日付，支払条件，支払基準日等。

在标准程序中支付基准日是転記日付，支払条件算出支付基准日也就是締め日，但在实际业务中可能会使用sd的出荷日、納入日来计算，这就需要用到badi:acc_document来实现。

在设置好支付基准日也就是締め日之后，通过对請求括り単位的更改(BADI:isjp_item)，可以使多比债权生成同一月次請求No、这样在后续出请求出时可以将这些比债权出到同一请求书当中。

需要注意的是，不同币种，不同支払期日会产生不同的月次請求No。

在日本2024.10开始引入インボイス之后，税需要完整的对上，因此税调整也是重中之重，而isjp_cr可以实现这一操作。

什么是税调整、比如存在下面两种仕訳的时候。单独看税是没有问题的，可将売上合起来看430的10%是43块的税，而实际只记了21+21=42块的税，这就需要税调整了。

仕訳1:売掛金236/売上215、21税

仕訳2:売掛金236/売上215、21税
启用这个功能需要改bp和配置，这里就不多介绍了。

可税调整明细在生成过程中经常出现错误导致締め請求执行的失败。由于是标准机能给出的error消息又没用，调查无从查起，这时笔者只能硬头皮看标准代码。

直接上结论

税调整明细是标准机能通过bdc来転記的（真low）、pgmid:lfipif00的1909行可以debug改下处理模式就能弹窗来查看失败理由了。是不是网上查不到的黑科技！

最后留下个悬念，在项目上线几个月后发现，在数据没有明显变多的情况下末締め时处理的时间越来越长，找了sap公司的人也没有给出什么好办法，结果只能是通过增加job的数量来减少处理时间。

最后从项目离开时也没有听说什么好的解决方案，只能在此先"记录在案"有机会再重新调查。

欢迎交流与指正！