Import Xe batch versions into E910?


VIP Member
Hi all,

I don't have the full details yet, but will ask this as a fairly general question anyway...

My customer has exported batch versions from Xe (SP24) and inported them into E910 (

The versions are from RCW06 that was a 3rd party product in Xe that Oracle acquired and is now a standard part of E910. The UBE and its template are customised in Xe.

They appear to import correctly in E910, and in BV I can see all the data selections and processing options.

When I list the versions with R98306 however, it doesn't print any processing options - all the versions just are blank.

Should the above case work, even with customised processing option template?

Note: If I create a new version of RCW06 in E910 then it reports correctly in R98306.

Correction: it does *not* report new versions correctly so maybe this is a general problem with RCW06?

**Update** - turns out the processing option template was corrupted - all ok now...


Versions are a bit tricky:
1) If the PO Template is different across the systems, the values would obviously no longer match, but also
2) The standard JDE CopyVersion function used to do the deed will also copy the PO DSTR (F98743 specs) and the F98306 data, which may screw up the target UBE & all its versions, which can be recovered by importing some other (good) version from the same system (exported before or from a different unaffected environment).

Hard to say exactly with the symptoms you have described, but it does look like there's some sort of mismatch. Maybe this product underwent changes when it was being incorporated into JDE. I.e.: even if the DSTR's have the same count of members, but some ID's are now different, it would still confuse it, they really have to be identical.

The same, of course, would pretty much apply to upgrading any versions across any two systems, no matter the technique used to bring the specs across...
Hi Alex,

As I just updated on the original post - all is well once I grabbed the pristine PO Template.

But I would like to confirm a couple of things:

As I understand it - the processing options are stored as name-value pairs. I've noticed that if a version with new processing options defined in a template get promoted to a pathcode without the template, it still works as the new names get ignored, but when the new template gets subsequently promoted, the new names and values become visible (and uncorrupted) in the new pathcode. Will the same useful behavior occur when using Boomerang?

Re your point 2) - are you saying that when we sent up the versions that we unwittingly sent up the Xe processing option template (or anything else)? We would not want to do that without telling it to do so.

What are the rules about templates when copying versions between systems like this?


Yes, it would be the same, because these different bits are actually stored in different places and there's no referential integrity. Plus, there's actually some redundancy there too.

Yes, unfortunately, this is "standard" JDE behaviour. And in fact, it may sometimes be useful. But indeed, most of the time it would cause havoc in such scenarios.

I believe that exporting and importing Versions would always carry along the F98306 records for sure, but possibly F98743 DSTR specs as well (I can't be 100% certain without re-testing this, as I haven't looked at this functionallity for quite some time now, but you will surely see if that's true or not in your system after an import anyway).

And the fact that it carries F98306 records along almost makes sense, because otherwise they will never be upgradeable (i.e.: they do not actually belong anywhere solid, like DSTR specs or the Version specs, they really sit there in between).

PS: It would have been quicker to e-mail me directly, as you only get digests from this group only once a day...
The latest version of Boomerang offers a configuration setting to either do or not do this. In different scenarios, it's important to do this right:
1) When copying Versions of your custom UBE's, you probably have to copy F98306 records along with them;
2) When copying custom Versions of standard Objects, you most likely do not want these copied.

So this has to be decided before the Import and set accordingly. I expect that if you are copying all kinds of things, you would probably end up changing this setting rather frequently. And this would also make it harder to work with Projects that contain different kinds of Versions, but not by much - you can Import the same single Package in 2 goes, using different values for this setting. Anyway, just the extra bit of flexibility ;-)