支付条件的限制，terms of payment, day limit?

lachy

关于0BB8支付条件的问题：

在学习0BB8的时候，发现SAP可以定义很多种支付条件，对于支付时间的先后可以灵活定义，因为以前写代码的时候就知道可以限制的参数越多越有可能发生矛盾，所以我就想试一下SAP对于这么多条件是如何统筹的，是否能避免各种限制条件之间的“撞车”。
  
首先声明一下，我知道condition2的天数应该大于condition1的天数，否则l逻辑上就是错误的。但是由于sap系统既支持No. of days又支持fixed date，那我想知道同时使用这2项的时候sap怎么判断时间的先后？sap能否在我配置的时候就将错误的逻辑都拒绝？还是sap有时候也无法判断时间的先后留下错误配置的隐患？

      图一图二：
        然后我试了下面的图1所示的配置，发现报错，并且发现condition1里的fixed date小于13的时候可以保存，大于等于13就不行，如图2所示。

我不知道12,13这个临界值系统是怎么算出来的，怀疑跟day limit有关系。

      图三图四:
         然后我把day limit从15改成14，其他数据不变，condition1里的Fixed date填12报错，填11就能保存！如图3和图4所示。
相当于day limit减1，condition1也减1.

这相当于验证了确实与day limit有关系，但是是什么关系呢？谁能帮忙解答，谢谢！

补充：系统报错的是“Periods to be calculated are not all in ascending order”，也就是系统能够认识到condition1和2会产生冲撞颠倒的情况。我想问的是，12能够保存，是因为系统认为这样condition1和2就不会冲撞吗？







该贴已经同步到 lachy的微博

wqh1208

Day limit：
天数限制。它决定当系统中定义了多个同名的支付方法时，具体选取哪个支付方法。例如定义了两个同名的支付方法，它们的天数限制分别为15和31，那么对于Posting Date在每月15号或15号之前的凭证，系统将选用天数限制为15的支付方法；对于Posting Date在每月16号至31号的凭证，系统将选用天数限制为31的支付方法。

tony

此原因，是你的不认真和不细心导致;
让我去读你的支付条件，以填写13那个为例（今天5月11日），就是说：
1.在未来的32天之内，2%的折扣；
2.在未来的30天之内，1%的折扣；
这不矛盾吗？

研究SAP一定要认真，从业务着手，业务对了，才可能对。

lachy

tony 发表于 2013-5-11 01:49
此原因，是你的不认真和不细心导致;
让我去读你的支付条件，以填写13那个为例（今天5月11日），就是说：
...

你可能误解我了，我这么做的目的就是想看看SAP系统能否排查这样的错误，我不明白的是为什么是13系统就报错，12系统就不报错？这跟limit date有什么关系？

如果SAP不能排查这样的错误，那一定就是SAP的bug吧，毕竟要做到完全避免冲突也是有可能的。

runpeak

       学习中

wqh1208

首先，请明确天数限制的作用（见前贴）。
其次，在配置支付方法的时候，必须保证后一行的“No. of days"大于前一行的"No. of days"，否则系统就会报错，如下图所示：


顺着这个思路，你再继续研究研究吧！

建议：在配置支付方法时，要么使用"No. of days"，要么使用"Additional months"+"Fixed date"，不要即使用"No. of days"又使用"Additional months"+"Fixed date"。这样就不会弄错了。

lachy

wqh1208 发表于 2013-5-11 11:32
首先，请明确天数限制的作用（见前贴）。
其次，在配置支付方法的时候，必须保证后一行的“No. of days"大 ...

你说的第2项的天数要大于第1项的天数，这个我知道，我就是想看看系统是否能判断出这个错误。显然sap在很多很明显的错误情况下都能判断出来，否则sap也不会报错。你还是没有回答我的问题，为什么sap认为13就应该报错，12就不报错？

lachy

我自己测试了一下，用OBB8创建Terms of payment,
1) 当day limit输0的时候，系统非常聪明，无论我怎么输入condition1和condition2的时间，只有存在错误的可能系统都会发现并报错“Periods to be calculated are not all in ascending order”，也就是系统能够考虑到各种情况以避免可能的冲突。
2）当day limit>0的时候，系统就变笨了不会算时间了！
我在虚拟机下创建了2个有问题的payment terms: 1006(day limit4,31) 和 S067(day limit15,31)
这2个支付条件在某些baseline date的时候会使算出的condition1比condition2的时间期限还长。
用F-22记账发现：
     使用1006的时候，如果是会出错的Bline Date，系统会报错“The terms of payment are incorrect”，阻止了line item 2的输入，无法成功记账；除非Bline Date算出的时间是condition1<condition2才能继续记账。
     使用S067的时候，系统似乎无法发现这个错误，记账很顺利，保存了之后再display凭证发现S067没有生效，net due date=Bline date。也就是说系统在最后入账的时候将错误的days/percent置零了。


不管是上面那种情况，SAP对Payment Terms可以说是做了多重检查，在OBB8中定义的Payment Terms跟最后记账生效的未必完全一样，因为记账的时候Bline date, days/percent都是可以手动修改的，且系统也会check其正确性的，即使系统在记账的步骤中没有check出来，错误的数据也无法记录入账，最坏的情况就是置零了。

super_carbon

学习

robot_lgw

学习