As a result of Sarbanes Oxley we need to segregate user duties. In particular users who post sales shipments cannot post invoices and cannot post credit memos; whilst those who post invoices cannot post shipment or credit memo’s. The same sort of rules apply in purchasing. I welcome your suggestions fo the most effective method of implementing this segregation of duties.
Do you have your own solution developer licence? If not, have you spoken to your Navision Solution Centre regarding this request? What version of Navision are you using? My solution would be; Create a set of boolean flags for each of the specific tasks on the User Setup table and set them accordingly. Then add code on each of the posting routines which first checks the flag relevant to the routine, and errors if the user doesn’t have the right permissions. If you would like to discuss this further, you can email me directly
Another solution would be to handle this with the respective permissions on the posted document tables, e.g. to post shipments you must have indirect permissions on T110 and T111, for posting invoice T112 and T113, for posting credit memos T114 and T115. I am quite sure that using the correct permissions you can setup the different roles that you mention, that you can then assign to the respective users. It might be more difficult to setup initially, but will require no programming. Saludos Nils
quote:
Another solution would be … It might be more difficult to setup initially, but will require no programming.
Originally posted by nilsm - 2006 Feb 17 : 09:19:07
I think that IS the solution! Why to invent the wheel? All my customers use the user management to follow this (stupid!) SOX stuff (stupid because what are you going to do when you only have 2 Users working on sales & purchase at the same time? Define 6 different roles AND logins?).
I didn’t realized that SOX had escaped form the US. Without doubt it is a completely bizare set of rules, that really have no logical connection to the real world. I have only done one SOX complaint system, and to be honest, I believe that making it fully compliant opened more security holes than base Navision. Many of the rules may seem sensible for one companies practices, but then are complete nonsense for another. I did find though that it was easier to achieve compliance on SQL than on Native, since it was easier at the DBA level to restrict backend access. From the role segregation issue, Navision permissions will provide most of what you need. You will probably need to move to form level security, since there are some areas that will need to breakdown furter than you can at the table level. You will probably need to use Change Log, and you will need to create a few keys on it, and some forms to make the data more usable. This could introduce performance issues, since its a very invasive process, so test it welll in the production system.
First of all thanks for the suggestions. Second, sorry for the dealy in replying. I am worried that changing permissions will mean that the posting will fail only when an attempt is made to insert into a table that is not allowed and that this happens as the last or next-to-last action int he transaction. This could mean significant roll-backs. What do you think???
Jonathan, fopr sure in a heavy posting environment this can be come an issue, since there is still quite a bit of processing before the first insert, but its not right at the end. THere is some pre testing done, and then the first insert of a shipment header, is not that far down the process. So yes it will add a perfomence hit that needs to be tested, but it won’t be all as bad as it looks. Also keep in mind that the problem is only going to happen when people do things that they know full welll they are not alloed to do, so they should learn after a while.
Jon, Set up a test system and do the security testing for role assignments there. Dave, As for change log…geez that argument drove me nuts. The auditors wanted to see a change log for anyone with db, security, or superuser rights, and any security changes that were made. They had trouble with “the version of Navison we are runnin is pre-SOX and does not support this.” Far as I can find in db ver 2.6 and exe ver 3.1 we don’t have that logging function. What version is the Change Log available on? I also had this argument at a prior company when the auditors wanted full logging on an SAP system. I told them NO. Even SAP warned about the HUGE log that would result if you log everything. You have to be selective in what you log or your log could be bigger than your data. SAP point blank stated logging of transaction data (vs master data) is a bad idea from a volume point of view. And by the way you have to save that HUGE log for the auditors to review at the end of the year. Maybe we should invest in the disk drive companies. Walter, I almost slaped a SOX IT auditor in the face when he made a comment that “he was concerned about system security and segregation of duties and operational issues was not his concern.” IOW the fact that SOD would cause the operational process of the company to stop because someone is out sick and there was no backup that would not create an SOD issue was of no concern to him. grrrrr You have to build a manual compensating controls process around this. For example periodic reviews of the transactions by a manager. Gary
The cleint was almost abotu to go live on 3.60, but we had to delay go live and move to 3.70 to be SOX compliant with Change Log. Crazy thing is that during the six month delay, they staid on the old system, that allowed any user with a log on ID and Access to read or modify ANYTHING in the system that they wanted. Oddly that was acceptable, since it was an existing system, but going live on 3.60 and then moving to 3.70 in 6 months was not acceptable. People there is BIG BIG money in being a SOX consultant.