There are frequently asked questions related to Visual CWR Validator.

General Questions

You are primarily making CWR, why this detailed validation tool?

We use basically the same code for building and reading CWR files, CSV files etc. This makes it unlikely that we can have most of the things working, but not all of them. If we have a bug, it usually breaks a lot of things and is picked up in many of our unit tests. This reduces the development time in the long run.

It is a great tool for educating our support staff. We sometimes use it to clarify issues with our clients. Not to mention the sales. These tools do create leads. Right?

Your tool shows errors, but this file was accepted by a society. So, is it really an error?

Good for you. Most societies do not validate as strictly as this tool. But different societies validate differently, so if we know that any of the societies validates, we do it as well. Of course, we could have a bug in the code, especially since this validator uses development version of the code.

The software I use is making CWR that is being rejected by societies and now your tool shows me why. What can I do?

Well, if it is a commercial tool, you may inform the vendor of the issues, but maybe you need to start thinking about moving away from them. We can not really help you with staying with a competitor, right?

Completeness

You state that the tool is incomplete. Can you be more specific?

The tool is based on our CWR library that is in development (and always will be). We do not update these FAQ as often, so no, we can not be completely specific.

You state that the validation complete on field and record level. Can you be more specific about that?

Yes. We take each row and try to separate it into fields using three different methods. Depending on which of them succeed and which fail, we declare the line generally invalid or go deeper. Generally invalid lines have a completely red background.

If we did manage to get the fields, we validate each of them separately. Mandatority, including conditional mandatority within each record, is the first step.

Then we try to validate the content of the non-empty field. Numeric fields must be numeric, alpha must not contain invalid characters, list fields must have one of the listed values, codes with check digits must be valid… We also check all sequences: transaction, record, publisher chain and territory, and percentages in each row.

Specific Errors

This is the growing list of specific errors that come popping up in questions.

What is a Wrong number of blanks of Carriage return missing?

This means that there is an issue with the line after the last non-blank character. The length of lines is strictly fixed, and blanks at the end should be present. Many tools simply strip them.

The lines in CWR, according to specs, must end with CRLF (Carriage Return character, followed by Line Feed character). This is also called Windows-style line termination. Many tools do this in Unix style, meaning there is only LF.

USA Licence Indicator is lit red, but this is not a required field?

This is a very common error, it means that there is exactly one blank character missing at the end, as this is the last field in the SPU/OPU records. It is often connected with the previous error.

First Recording Refusal Indicator is not required outside the UK. Why do you make it required? Why can’t it be set to ‘U’nknown? Can I just use ‘N’o here?

If a field is required anywhere and the destination society is not set (set to all), we mark it required. And that is how we choose to validate here. (We do not take into consideration destination part of the CWR filename, that would lead to much larger issues.) Although specs mark this as a flag field, validation rules state that it can be just set to Y or N or left blank, except for UK societies. So, it cannot be set to ‘U’nkonwn.

We have some text in an alpha field, but it is marked as Invalid value. Why?

There are either invalid characters or the field is not left-aligned. Although it is not stated in the specs, it stands to reason that alpha fields must be left-aligned, meaning that unless it is an empty field, the leftmost character must not be blank. This also must be valid for list fields, including Character Set field in HDR record.