Batch Versioning of Requirements Catalogs

[Former Member]

Hi,

Suppose that I have a horde of requirements catalogs that need new versions created periodically. By this, I mean that a catalog - new catalog version pair should be filled out with the same requirements as a catalog - existing catalog version pair, and that this needs to be done for each catalog there is. If one has, say, more than a hundred catalogs, doing this manually in PIQRLCATM is tedious and error-prone....

I haven't seen such functionality in SLCM 4.72, and am wondering whether it exists in 6.0 or is planned?

Alternatively, suppose that I have the same horde of requirements catalogs, but decide that new versions should only be created on an as-needed basis. By this, I mean that a catalog - new catalog version pair should only be created when a subrequirement of a requirement in a catalog - existing catalog version pair would need to be changed. This implies that a separate version set should be maintained for each catalog. However, the version set number can only be a two-digit number, and there are more than 99 distinct catalogs.

Is the maximum size of this number increased in SLCM 6.0 or is there a plan to widen it in the future? (Changing it to a 2-character alphanumeric value would also increase the range, but not as much as making it a 4-digit decimal number.)

Thank you,

Eric

[Former Member]

Hello Eric,

There is no report available to copy requirement catalog versions. As far as I know such a report is also not planned. Currently catalog versions must be copied manually.

However, you can create a customer own report easily using function module HRIQ_AUDCATALOG_VERSION_COPY. If you decide to create this report I'm sure you need also function module HRIQ_AUDCAT_VERSIONS_GET, which determines the versions of the version set assigned to a certain catalog. Table parameter ET_VGRP contains versions of a catalog imported to the function module and contains furthermore the sort order of the versions (might be needed to determine 'next' version).

When you copy catalog versions you should consider following (assuming version sets are re-used for several catalogs): the new catalog version should likely be the default version of the version set assigned to the catalog. So, you must likely copy all catalog versions using the same version set. If you create catalog versions periodically (manual copy), e.g. copy each year all catalog versions, this problem is reduced. But it's not 100% sure that you have not forgotten to copy a catalog version. Transaction PIQRLCATM does not offer any checks concering this problem.

I think this is what you mean with error-prone, right? A report could ensure that all catalog versions of a certain set are copied and it would certainly help to prevent errors.

If you use own version sets for each catalog you could avoid the periodically copying and you could offer a on-needed copying. This is interesting and surely worth to think about. But I think this would be a misuse of the version sets. The version sets are intended to be re-used and they shall be re-used. Therefore I assume that it's unlikely that we prolongue the domain for version sets. Instead we could allow to define a default version at the assignment of version set to catalog. Example:

- Catalog 'Undergraduate', Version Set 'by Years', default version 2007

- Catalog 'Major Requirements', Version Set 'by Years', default version 2008

Would this help to support the on-needed copying?

Moreover I like to add one more considerations concerning the copying of requirement catalog versions.

When you copy a catalog version, the requirements (rule container) get a new infotype record for the new catalog version. In this record among others the sub requirements are stored. But the sub requirements are not copied, the existing ones are just assigned to the new record. That means, changes to sub requirements have effect on several catalog versions. That is probaby not what you want. If you want to change a sub requirement in one version only you need to delete the sub requirement (in Tx PIQRLCATM delete means unassign) and create a new sub requirement.

Currently checks like 'sub requirement used in other requirements' or 'sub requirement used in other version' for change mode of sub requirements are missing. But we're working on that.

Best Regards

Volker.

[Former Member]

Hi Volker,

Thanks for your reply.

I guessed that someone was going to say that I was misusing version sets with one version set per requirements catalog. So, let me explain how I arrived at that situation.... The format of our university's undergraduate program is currently such that a student can choose a different yearly version of the undergraduate catalog for each major or minor (academic specialization) signed, plus another yearly version of the undergraduate catalog for the general education and degree requirements. This implies that we cannot have a single undergraduate catalog for our SAP implementation, because otherwise there would be no way to disambiguate which yearly version of the catalog matches which CG or SC. (At least, I believe this to be true based on my testing plus previous discussions in this forum.)

As an example, a student could be registered for a SC with a catalog "Bachelor of Science" and version "2005 - 2006", a CG with a catalog "Physics" and version "2006 - 2007", and another CG with a catalog "Mathematics" and version "2007 - 2008". Now, if we had a single catalog "Undergraduate", which contained the rule containers for the degree and the majors, there would not be a way to figure out which yearly version of the "Undergraduate" catalog went with which requirement.

So, it appears that we are compelled to have a separate catalog for each undergraduate major and minor, as well as a separate one for each degree program. The questions about version sets then enter the picture. The path of least maintenance would be to keep a separate version set for each catalog, and then only create new versions (with one or more subrequirements replaced) in that version set as university curriculum changes for the given program or specialization. This is the "on-demand" or "as-needed" scenario that I presented in my original post to this thread. The problem, of course, is the domain of the available version set numbers.

To get around this limitation, I developed an alternative proposal, and that was the "batch update" scenario. In that scenario, we can use a single version set for all catalogs, but there will be lots of extra maintenance and redundancy. If SAP does not plan on extending the domain of the available version set numbers, then I think that we are forced to follow the batch update approach. But, maybe there is a third approach to the problem that I have not yet considered...?

Additional Comments:

To clarify the remark about manual copying being error-prone, yes, I meant that someone could overlook a copy or put the wrong rule container in a catalog - especially with that many catalogs to be processed.

As far as a "default version" goes, I assume you are talking about something different than the default version that one can already assign to version sets (for the purpose of deriving requirements without an explicit catalog version being given)? I am not sure that what you suggest would help with the problem. But, if you want to explain your proposal further, I might be able to give a yes or no answer.

Your remark about "changing" subrequirements is actually what I had in mind, when I said "change". I should have chosen a different word. So, yes, I meant unassign and then add a new replacement.

Again, thank you for your reply. I will consider the advice you gave about the batch update.

Eric