Jump to content

Changing indicia based on count and barcode


rpaterick

Recommended Posts

OK,

 

Client wants to run a postcard with the "invalids" or "uncorrected" records in the mailing. I have the indicia rule working based on record count but I now need to see if I could have the indicia change based on the barcode digit or another column of interest?

 

So the rule would look at the record count and apply the correct indicia for records that qualify for the Presorted rate, then the rule would look at the other column of interest to see if it needs the "Single-Piece" indicia.

 

Any ideas?:confused:

 

Rules I have as of now that are working based only on record count.

 

var myNewFile = new ExternalDataFileEx(FusionPro.Composition.inputFileName, ",");
SPI = (myNewFile.recordCount > 199);
FCI = (myNewFile.recordCount > 499);

 

    if (FCI)  {
       return Resource("FC");
   }
   else if (SPI)  {
       return Resource("SP");
   }
   else  {
       return NullResource();
   }

Link to comment
Share on other sites

I'm not sure I understand what you are trying to do. Perhaps including some data samples along with the possible scenarios would help.

 

The way I read your post, you have 3 possible scenarios:

1) Record does not qualify as 1st Class so does NOT receive indicia

2) Record qualifies for 1st Class but a flag in a 2nd field forces it to NOT receive an indicia

3) Record qualifies for 1st Class with no flag in 2nd field so it DOES get indicia

 

If that is correct, I would think you would just test both fields in your IF statement using the double ampersands (&&) between tests to see if both Field 1 and Field 2 test true. If they do, you return your FC resource. Your next two ELSEIFs would become what you currently have for IF and ELSEIF, and your final ELSE would be the NullResource.

 

How far off am I on my understanding? ;)

Link to comment
Share on other sites

The way I read your post, you have 3 possible scenarios:

1) Record does not qualify as 1st Class so does NOT receive indicia

2) Record qualifies for 1st Class but a flag in a 2nd field forces it to NOT receive an indicia

3) Record qualifies for 1st Class with no flag in 2nd field so it DOES get indicia

 

 

How far off am I on my understanding? ;)

 

Pretty close, I'm thinking number 3 perhaps? During the run, the indicia will change. You could have 1200 records. The last 10 records do not qualify for a presorted rate and need a different indicia on it, Single-Piece. The record count rule works, it's just I need it tweaked based on my data file. I'm trying to think of other fields that I could include that would stand out more in the data file for a callout to switch the indicia.

 

attached is a data file of the two records that qualify for presorted rate and the last two records do not qualify. This is where the indicia would have to change during the run from Presorted First Class, to Single-Piece. The Post Office needs to have the Single-Piece indicia on and it would be nice to not have two separate setups.

 

Thanks E!:D

test.txt

Link to comment
Share on other sites

How about searching the Endorsement Line for a unique substring to determine the correct indicia graphic? You could change this:

if (FCI)  {
       return Resource("FC");
   }
   else if (SPI)  {
       return Resource("SP");
   }
   else  {
       return NullResource();
   }

to something like this:

if (FCI) return (Field("Endorsement Line").search(/SINGLP/)) ? Resource("SinglePiece") : Resource("FC");
  else if (SPI) return (Field("Endorsement Line").search(/SINGLP/)) ? Resource("SinglePiece") : Resource("SP");
  else return NullResource();

You would have to add your own resource for "SinglePiece" of course.

Link to comment
Share on other sites

How about searching the Endorsement Line for a unique substring to determine the correct indicia graphic? You could change this:

 

if (FCI) return (Field("Endorsement Line").search(/SINGLP/)) ? Resource("SinglePiece") : Resource("FC");
  else if (SPI) return (Field("Endorsement Line").search(/SINGLP/)) ? Resource("SinglePiece") : Resource("SP");
  else return NullResource();

 

You would have to add your own resource for "SinglePiece" of course.

 

Cool, I will give this a try and see what I get!

 

Thanks E!

Ryan

Link to comment
Share on other sites

How about searching the Endorsement Line for a unique substring to determine the correct indicia graphic? You could change this:

 

eSmith,

 

I tried the code and it didn't work. it's saying FCI and SCI not defined. Just creates blank previews. I have both indicias setup in the RESOURCES and labeled as FC and SP. I'm using a data file that just has two records in it for testing quickly. 1st record is presorted in the endorsement line and the second record has the SINGLP in the endorsement.

 

I like this attempt because it eliminates the need for a "record" count. When I do proofing with separate data files, that data file sometimes has just 10 records in it but it's still mailing presorted 1st class.

 

Let me know if I can give anything to diagnosis further as my programming language is a challenge for me.

 

Thanks E!

Link to comment
Share on other sites

I like this attempt because it eliminates the need for a "record" count. When I do proofing with separate data files, that data file sometimes has just 10 records in it but it's still mailing presorted 1st class.

I didn't mean to suggest that you could bypass the first code snippet in your original post since that is the code that determines a value for FCI and SPI which are then referred to in my code. :(

 

Without counting records in data, I don't see how to determine (based on sample data file you supplied) if job qualifies for presort or not. Without a record count of data, you'd be back to checking the Endorsement Line -- a record containing SINGL would get one indicia while a record with AUTO would get a different one. That logic would assume that there are only two possibilities which doesn't seem to match the original post's scenario...

Link to comment
Share on other sites

That logic would assume that there are only two possibilities which doesn't seem to match the original post's scenario...

 

Yes, I like this scenario. This would be the way to go as it will always have over 200 records to qualify for postage.

 

So it basically looks for the Endorsement Line to tell it either presorted or single-piece. If no SINGLP in Endorsement, then it would use the presorted indicia.

 

Thanks E!:D

Link to comment
Share on other sites

In that case I would assume that all you really need is a rule with the following:

 

return (Field("Endorsement Line").search(/SINGLP/)) ? Resource("SinglePiece") : Resource("Presort");

 

Will all records in your data be either presort or single piece? If there's a third possibility, this code will return the Presort indicia for it as well which could be an issue...

Link to comment
Share on other sites

In that case I would assume that all you really need is a rule with the following:

 

return (Field("Endorsement Line").search(/SINGLP/)) ? Resource("SinglePiece") : Resource("Presort");

Will all records in your data be either presort or single piece? If there's a third possibility, this code will return the Presort indicia for it as well which could be an issue...

 

 

Yes, just either single-piece or presorted 1st class. The Endorsement line "should" always have SinglP in the endorsement line for the records that do not qualify for any presorting.

 

Should I still try the code?

Thanks,

Ryan

Link to comment
Share on other sites

If that's the case, I think the last round of code should be good.

 

By the way, I find it interesting that you use a different indicia for single piece records. We print a presort indicia on all records if the job is designed to go presorted, and pay a small fee for the pieces with the optional endorsement indicating SINGL (even though they too have the presort indicia). I'm wondering why you are doing something different?

Link to comment
Share on other sites

If that's the case, I think the last round of code should be good.

 

By the way, I find it interesting that you use a different indicia for single piece records. We print a presort indicia on all records if the job is designed to go presorted, and pay a small fee for the pieces with the optional endorsement indicating SINGL (even though they too have the presort indicia). I'm wondering why you are doing something different?

 

They(client) do not want the "optional" endorsement line printed on the piece. Last drop we did to the PO they made the driver fix all 135 presorted indicias to say single-piece indicias on the art. Even though our paperwork states they are going at a higher-rate and are getting PAID, they still want the indicia to have the correct wording on it.:mad:

Link to comment
Share on other sites

If that's the case, I think the last round of code should be good.

 

e,

 

code is defaulting to just the Single-Piece indicia, even if the endorsement does not state SINGLP. Validation works, just doesn't switch. is it missing an "else" statement?

 

Thanks for your help on this,

Ryan

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...