Why do we need to redesign the User Security Access from the scratch?

After the series of GP Application Level Security topics from David, I thought of just substantiating one point which is also recommended by David.

While upgrading GP from lower versions to v10.0, it is recommended to redesign our User Security Access list instead of carrying forward from the lower versions. For those who ask "Why should I redesign when my Security Access details are already on place in the earlier version and it just needs to be transferred from lower version to current version?", the reasons are listed below:

1. The security model approach in GP 10.0 is Pessimistic as opposed to the lower versions which are Optimistic.
2. It's a perfect oppurtunity (as precisely mentioned by David on one of his articles: Information about using v10.0 Security Conversion Tool) to redesign our User Security Access using the new Security Roles and Tasks. While the conversion tool does transfer the existing details, it does not however convert the details to the exact Roles & Tasks. It just do a "Near-Role & Task" conversion, as explained on this article.
3. The new Security System provides us with a set of default Roles & Tasks, which are best suited and completely covers the entire system and its operations. In any case, we still need to re-define the Security Access rights to the 3rd Party features, so that is not considered in this discussion at all. We can leverage our Security Details to the best extent by making use of the new set of Roles & Tasks.
4. Technically, the tasks are CREATED instead of CONVERTED. Means, the old Security Details are recreated on the System tables, which means, unwanted load of Security Data. Which means, we may load our system with too many records which are not exact, but near to what is exact.

There may be a lot of other reasons, but the above is what I could think of at this very moment. I sincerely welcome more points supporting / opposing this.

Vaidy

About Energized Accounting

It's been a long time since I did something on my blog. I was stuck with two things, one which caught my interest and one I was caught unaware: 

1. Inventory data level issues on one of my clients' site.

2. My Photography

Sooner, I will get back to the above and provide you some interesting facts on that.

But this post, is meant to introduce a very good blog, which I very recently came across and now I am a constant follower. The blog is named as ENERGIZED ACCOUNTING. 

Most of the consultants in our GP community should be knowing this. But for those who don't know about its existance: This is a blog with posts which very practically approached and intensely informative.

The Author of this Blog, Mr.Bill Kennedy, touches almost unforeseen (or rather overlooked) points on an ERP system. An ERP Consultant evolves completely only when he/she knows the basics better. This blog would certainly help us to evolve.

You read it, you will agree with me 100%, or even more than that.

Well, I am back to where I belong to. To learn & discuss GP.

Vaidy

Declaring Variables to Relevant Datatypes

For all Developers,

I just thought of sharing this very simple (some, with their experience, may even think that this is silly) piece of advise.

Recently I was working on a Customization (debugging an issue reported). An Inventory Variance Transaction was not getting posted. Trx Lines were perfect, the lots were properly assigned and everything looked perfect. This Variance Trx was created at runtime based on the Customization. Still, this batch was not getting posted. The client had suppressed the Edit List functionality on the Trx Entry and the Posting Journal Report on the Batch Entry screen. Ideally, there is no other way to get informed on what went wrong.

I first enabled the Edit List report on Batch Entry and ran the Edit List. Which displayed this error message: Lot number does exist for this item and site in Lot Number file.

I checked the IV Lot Master table and IV TRX Serial Lot Work table. Records were properly linked. After hours of troubleshooting, I finally found one difference.

The Date Seq Number in Lot Master table and IV Trx Serial Lot Work table did not match for the erroneous record. The value of DTSEQNUM in IV00300 table was 32768 and the value in IV10002 was 32767. I got the source code of that Customization and checked the place where this Trx is created. This developer had declared an "integer" variable and had passed it to the script INVEN_LotNumberAutoAssign script, which returns a "long" value for this parameter. Ideally this should have been 32768 and since the "integer" does not hold more than 32767, wherever the value was 32768, it had stored as 32767.

Well, the moral of this frustrating story: Please be very alert in declaring variables and always keep it to relevant Data Type, as this may take your (worse someone else' life) life sometime down the lane.

Vaidy