壹佰网|ERP100 - 企业信息化知识门户

 找回密码
 注册

QQ登录

只需一步,快速开始

查看: 424|回复: 1

[FI] kb11n 出现奇怪的问题

[复制链接]
发表于 2012/7/21 22:16:05 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。如果您注册时有任何问题请联系客服QQ: 83569622  。

您需要 登录 才可以下载或查看,没有帐号?注册

x
我用kb11n 做了几笔业务  
当时产生几个成本的凭证  
1003300001-1003300005
后来 我要看下这些凭证  '
到 coep 表里.竟然发现 1003300002 这张凭证不存在 ..
为什么呢...
kbs5 也看不到。但是其他几张都看的到。..成本凭证是连号的啊。..
怎么会出这种怪异的问题呢...
谁可以给个合理的解释..

凭证跳号不很正常吗?从系统上讲,(即使将什么number rang的buffer不设->只是减少机会),
是绝对无法避免的事实. 如对程序熟悉,模拟各种凭证跳号还不是小case.




该贴已经同步到 xiaoerp的微博
 楼主| 发表于 2012/7/21 22:16:21 | 显示全部楼层
贴一个OSS的回答,其实绝对不可能杜绝跳号的,只要是多进城(or 线程)的系统就一定不可避免.但是这样的机会也不会很到..要模拟出跳号是非常容易的.

symptom
Gaps (jumps) occur when allocating internal numbers.
The status of the number range does not match the number last assigned.
The number assignment does not match the insert sequence.
Additional key words
Document number, Number range, Number range object, Buffering, Current number level, Trip number assignment, Number interval, CO document, CO actual posting, Inspection lot, Material document, Physical inventory document, Production order number, Planned order number, Process order number, Maintenance order number
FB01 VF01 KO88 KE21 KE11 FD01 FK01 XK01 XDN1 MB01 MB0A MB11 MB1A MB1B MB1C MB31 KANK KB11 KB13 KB14 KB41 KB43 KB44 KB21 KB23 KB24 KB31 KB33 KB34 KB51 KB53 KB54 PR01 PR02 PR03 PR04 PR05 XD01 VD01 MK01 SNUM SM56 SNRO VL01 VL02 CO01 CO40 CO41 VA01 MR1M MIRO
Cause and prerequisites
A large number of number range objects are buffered. When buffering a number range object, numbers are not updated individually in the database, rather, the first time a number is requested, a preset group of numbers are reserved in the database (depending on the number range object) numbers and these are made available to the application server in question. The following numbers can then be taken directly from the application server buffer. If the application server buffer is exhausted, new numbers are generated in the database.
The effects described under "Symptom" then result:
If an application server is shut down, the numbers that were left in the buffer (that is, that are not yet assigned) are lost. As a result, there are gaps in the number assignment.
The status of the number range interval reflects the next free number that was not yet transferred to an application server for intermediate buffering. The current number level does not therefore display the number of the "next" object.
The current number level (per server) can be displayed with Transaction SM56. Start Transaction SM56 and branch into the menu 'Goto' -> 'Entries'. In the dialog box, enter the client, the affected number range object (for example, RK_BELEG) and possibly the required subobject (corresponds to the controlling area for the object RK_BELEG).
If several application servers are used, the chronological insert sequence is not determined by the numerical sequence on the individual hosts, due to the separate buffering on the various servers.
Buffering the number range objects has a positive effect on the performance as no database access (on the number range table NRIV) is required for every posting. Furthermore, a serialization of this table (database blocking) is prevented to a large extent so that posting procedures can be carried out in parallel.
Solution
As the number range buffering does not lose any guaranteed attributes, a correction is not required.
If you still require a continuous allocation, you can deactivate the number range buffering deliberately for individual objects.
Proceed as follows:
- Start transaction SNRO and enter the affected object
- Press the 'Change' pushbutton
- Deactivate buffering: Menu 'Edit' -> 'Set buffering' -> 'No ??buffering'
- If you only want to change the buffer size, please enter the ??corresponding value in the field 'No. of numbers in buffer'
- Save the changes
Please note that this change is a modification. The modification is overwritten as soon as the affected number range object is redelivered - that is, you must check the change manually after every import of a maintenance level.
For the the following number range objects, gaps may cause user insecurity as a sequential numbering is 'expected':
Area CO:
- RK_BELEG?? (CO Document)
Caution: Note that the problems described in notes 20965 and 29030 can occur if you deactivate the buffering.
- COPA_IST?? (Document number during actual posting)
- COPA_PLAN??(Document number with planned posting)
- COPA_OBJ?? (Business segment number)
Area FI:
- DEBITOR????(Customer master data)
- KREDITOR?? (Vendor master record data)
Area HR:
- RP_REINR?? (Trip numbers)
Area PM, PP, PS
- AUFTRAG????(Order number, Production, Process, Maintenance order
number, network number.)
- QMEL_NR????(Number range message)
Area MM:
- MATBELEG?? (Material documents)
- MATERIALNR (Material master)
Area QM:
- QLOSE??????(Inspection lots in QM)
- QMEL_NR????(Number range message)
- QMERK??????(Completion confirmation number)
- QMERKMALE??(Master inspection characteristics in QSS)
- QMERKRUECK (Completion confirmation number of an inspection
???????????? characteristic in QM results processing)
- QMETHODEN??(Inspection methods in QM)
- ROUTING_Q??(Number ranges for inspection plans)
- QCONTROLCH (Control chart)
Area Workflow:
- EDIDOC???? (IDocs)
Number range buffering can be activated or deactivated at any time.
Number range objects that must be continuous due to legal specifications (for example RF_BELEG, RV_BELEG), or due to a corresponding application logic must not be buffered with the buffering type 'Main memory buffering'. Please see also notes 37844 (for RF_BELEG) and 23835 (for RV_BELEG).
Source code corrections

您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|Archiver|小黑屋|手机版|壹佰网 ERP100 ( 京ICP备19053597号-2 )

Copyright © 2005-2012 北京海之大网络技术有限责任公司 服务器托管由互联互通
手机:13911575376
网站技术点击发送消息给对方83569622   广告&合作 点击发送消息给对方27675401   点击发送消息给对方634043306   咨询及人才点击发送消息给对方138011526

GMT+8, 2025/11/30 17:43 , Processed in 0.011067 second(s), 14 queries , File On.

Powered by Discuz! X3.4

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表