JD Edwards: Moving from an Open System to a Closed System Safely

Using ‘IT’ Transactions Between Branch Plants

Edward Gutkowski, Chief Architect - Rapid Reconciler

When moving goods from ‘Branch A’ to ‘Branch B’ in JD Edwards, it is normally recommended to use the ‘ST/OT’ transfer process. This is to account for distance between the branches, where transportation is necessary (bills of lading etc.). But what if the branches are in the same building? Do you need to generate documentation and perform all those steps?

Well, the answer is an emphatic NO! You can use the standard ‘IT’ process to accomplish the task, but it does come with a caution, especially when using the branch plant number as the business unit in the general ledger account.

Consider the following scenarios:

Scenario 1

• Item/qty to transfer: 12345, 10 units
• Cost level in item master: 2 or 3
• Cost in branch A: $1.00
• Cost in branch B: $1.00

This is the typical scenario, where the costs in the branches are the same:

Nice and simple. DMAAI 4122 controls the credit form branch A, while DMAAI 4124 controls the debit to branch B. If the business unit field in the DMAAI set up is left blank, then the system will use the branch plant as the business unit. Your cardex will show the From and To transactions at $10 and the GL will move the value from A.Inventory to B.Inventory. Perfect!

But what if the costs in the 2 branches are different? What happens then?

Scenario 2

• Item/qty to transfer: 12345, 10 units
• Cost level in item master: 2 or 3
• Cost in branch A: $2.00
• Cost in branch B: $1.00

As in scenario 1, DMAAI’s 4122 and 4124 control the initial debit and credit, but what about the variance? That’s where DMAAI 4141 comes to the rescue. If 4141 is set to an expense account, like COGS for example, you will get the proper GL entries as pictured above.

Time and time again when I review DMAAI’s for this situation, DMAAI is set to the INVENTORY account, which pushes the cost variance to the wrong account and causes reconciliation issues.

Lesson to be learned: When using ‘IT’ transactions to move goods from ‘Branch A’ to ‘Branch B’, set DMAAI 4141 to be an expense account. It will save you reconciling items!

To find about GSI's products or services, call us at 855-GSI-4ERP or click on CONTACT US to send us a request for more information.

Meet the Author

Edward Gutkowski

JD Edwards: Moving from an Open System to a Closed System Safely

*PUBLIC is one of the most important roles in the JDE system for JD Edwards Security. It dictates the entire setup for your system, as *PUBLIC is a role everyone has “assigned”. The security assigned to *PUBLIC decides what users can and cannot see in the JDE system by default using *ALL access. There are typically two system setups commonly used. We discuss JD Edwards closed system security setup in this article.

An open system setup has either *ALL with all yes (Ys) for application and action security or no entries at all for *PUBLIC, *ALL.  This means that, without any other security assigned, users in the system can see, run, and change information using any application in JDE. You can see how this can cause problems. Roles assigned to users will have to be used to restrict what users should not be able to see, run, or change. This system requires a lot more maintenance, as the person handling security will have to assign security for every program in the system except for what the role actually should have. For example, we have a voucher entry role, 04VCHENT. In an open system, we will have to assign no to application and action security for all programs in the system except for the applications required for entering vouchers. If we were to forget one program, that could be a huge security risk. If you have to do that for one hundred or even two hundred roles, it is very likely there could be a major flaw in your security that will be very difficult to detect.

The other system set up, best practice recommended, is a closed security system. It is the polar opposite of an open system, with *ALL assigned no (N’s) to application and action security. This restricts all users from seeing, running, or changing anything in the system without roles that explicitly grant access to certain objects. Roles assigned in closed systems are a lot easier to maintain, as you only need to give the roles the security they need to see. *PUBLIC will block users from being able to use anything outside of what the roles define. Using 04VCHENT again, with a closed system you only need to worry about assigning applications needed to enter vouchers. Meaning, 04VCHENT grants access to P0411. If this is the only role assigned, the user will ONLY have access to P0411. The user does not inherit any other access because of the closed security setup. This is significantly easier to work with, even if the system has hundreds of roles.

Clearly, a closed system is a more secure system. So how do you switch from an open system to a closed system? The first thing to do would be to change the system’s *ALL setting in *PUBLIC to No (N) for Application and Action security. This will lock down the security of the system. From there, any roles would have to be reorganized, giving users the access that each role would need, whether it’s application security only (which would give the user inquiry access to the program) or application and action security (which would give the user full access to view, add, change, or delete data).

“Flipping the switch” from an Open to Closed Security model should involve preplanning, an executable project plan, and testing to validate the security is in place properly. Please do not hesitate to reach out to the GSI Security Team if you have any questions or would like to discuss options for remediating your current security structure.

To find out about GSI's products or services, call us at 855-GSI-4ERP or click on CONTACT US to send us a request for more information.