E8.12 Alternative OBJ & SUB

[Rauf]

For a second CoA structure for reporting, I have decided to use OBJA, SUBA fields. But is there any way to input the alternative description of the account ? Is it okay to use ANS - Free Form (3rd Acct. No.) to enter this description ? ( It is 25 char length only, so I might need to use short forms like Account as A/c).

 

[Rauf]

Any thoughts ?

 

[markdcci]

Rauf,

Nobody else seems to be providing input so I will give it a shot.

Your intended use of the alternate object and sub seems pretty straightforward.

As I understood the Free Form (3rd Acct. No.) field, GMANS, it is intended to be used as a full account number that you might use in a related or legacy system. So if you converted from another system to JDE, this field might be where you could store the legacy account number for easy reference as an example. As such, it functions similar to the GMAID field where it is basically a unique identifier.

I think using it to hold a simple description might cause you some problems down the road as your proposed field would need to be unique, which is not typically the case for a text description field. You could probably make it work with some type of alphanumberic coding but I wouldn't recommend it.

I took a quick look at the F0901 and it doesn't look like there is user defined alpha field of suitable length that you could expose for such a purpose although I might have missed one. A low-code possibliltiy would be to use the SDB? Or a custom file keyed to the AID field in the F0901 with a new entry screen as a more code-heavy solution.

 

[Rauf]

Hi markdcci,

Thank you so much.
I summarize the two solutions as you suggested.

1- Use the 3rd Acct No to store the complete account number ( I hope I can do this).
2- If the solution 1 does not meet the requirement, create a tag file with AID as a reference.

 

[markdcci]

Rauf,

I would add to your possible solutions slightly, but here is my modified summary:

Storing the alternate account number
1- Continue with your original plan to use OBJA and SUBA, if your alternate account number fits into the BU.OBJ.SUB model. That leaves that 3rd Acct No field open for a future acquisition/integration/etc.
2- If not, use the 3rd Acct No to store the complete alternate account number as you noted.

Storing the description for the alternate account number - (Ideally you would be using the same description as the primary account number since, for example, AR Trade should be the same regardless of the identifier. However if that doesn't meet your requirements):
1- Put the description for the alternate account number into a new Supplemental Database (F00092). The advantage to this is there is no custom coding - only configuration. The disadvantage is that it can get a bit clunky for the user to enter data, unless you have CAFE1 layouts available. I can't recall whether CAFE1 is available in your release.
2-If using the Supplemental Database is not feasible, create a tag file with AID as a reference as you noted.