03-02-2010 11:36 PM
Hi,
We have experimented a performance problem with transacction NK01. Could anyone tell me if have had a similar problem?
How can we solve this? the problem is specially with a large episodes. ( many services ).
thanks.
03-03-2010 10:01 AM
hi ..
Is your version number 4.63B .. or later ?
I will be quoting from the release notes of SAP Patient management ...
these changes have been made
· The Cancel function has be relocated to the Insurance Verification menu from
the Edit menu.
· The menu item Edit® Delete is no longer available. You can now only cancel
insurance verification requests.
· When you cancel insurance verification requests, the system uses the following
logic as in previous releases:
u2013 Insurance verification requests that already exist in the database are canceled.
u2013 Insurance verification requests that you have still to save and as such do not
exist in the database are deleted.
In both cases, the system immediately deletes the relevant entry to be canceled
from the interface, and therefore always shows you the up-to-date status. In
previous releases, this was only the case for the non-saved entries for the case
that did not exist in the database. The other entries were still displayed on the
interface at first. The system identified these entries by setting the deletion
indicator.
due to this there might be the issues which you are facing
Regards
Manthan.
03-03-2010 10:01 AM
hi ..
Is your version number 4.63B .. or later ?
I will be quoting from the release notes of SAP Patient management ...
these changes have been made
· The Cancel function has be relocated to the Insurance Verification menu from
the Edit menu.
· The menu item Edit® Delete is no longer available. You can now only cancel
insurance verification requests.
· When you cancel insurance verification requests, the system uses the following
logic as in previous releases:
u2013 Insurance verification requests that already exist in the database are canceled.
u2013 Insurance verification requests that you have still to save and as such do not
exist in the database are deleted.
In both cases, the system immediately deletes the relevant entry to be canceled
from the interface, and therefore always shows you the up-to-date status. In
previous releases, this was only the case for the non-saved entries for the case
that did not exist in the database. The other entries were still displayed on the
interface at first. The system identified these entries by setting the deletion
indicator.
due to this there might be the issues which you are facing
Regards
Manthan.
03-03-2010 4:35 PM
hi, our version is 6.0
Other thing is during verification, NRIV table is blocked and others verifications can not be made.
any clue? thanks.
Edited by: milasanz on Mar 3, 2010 5:36 PM
05-13-2010 8:10 PM
Hi ...
Reasons for performance problems in insurance verification could came from serveral reasons.
If you have problems with NRIV table, could be solved by setting up the buffering in the ISH_NKSK number range. It's a slight modification of the standard, but has no impact at all.
GO tx SNRO . Object ISH_NKSK, modify, go menu Edit -> Set up buffering -> Main Memory.
After that, the dympro will show at the bottom, the flag Main memory Buffering and No of numbers in buffer. try 100 or 50.
The only consideration you must have is that coudl occur gaps in the numbering of insurance verification documents.
Another problem could be caused by the pricing. Remember that the IV does pricing, I think twice. So, do an analysis of performance to the Pricing Procedures. Try by own developed formulas and void direct reads to database.
I hope this helps.
With best regards
Matías