Bates Numbering Placeholder in Devonthink 3 not restarting the count

I have been playing around with the imprint feature in Devonthink 3, specifically with the bates numbering placeholder. The problem I am encountering is that I cannot figure out how to restart the numbering of the pages. I have gone in the templates folder, and changed the “bates number” plist file to have an “integer” of “1” to try to restart the count (I also deleted the .plist file but that didn’t seem to result in a new one being created so I put it back). I have also closed the database and started it and quit the application and restarted. The count only restarts sporadically. Also, if I select several PDFs and apply the imprint, the count throughout the selects PDFs is not sequential. Even within a single PDF the count is not sequential (when I am selecting multiple PDFs and trying to “batch” the application of the imprint).

Welcome @rlamber3

The Bates numbering isn’t supposed to be able to be reset. That’s part of the point of them.

If you can consistently reproduce the sporadic numbering, please provide steps for us to follow. Thanks.

Thanks for replying to my post @BLUEFROG. I am very much enjoying the Devonthink 3 release and don’t mean to nitpick.

I take your point about the bates numbering not resetting. But I still think it would be nice to add that as a user option. You know, mistakes happen, something may have been added to the group of files that you didn’t mean to add and you want to start over or change the order of it, etc.

Here are the steps for the sporadic numbering:

(1) Select two or more PDF files
(2) Select Tools/Imprint/Whatever you called the custom imprint with Bates Numbering Placeholder included
(3) the imprinted files seem to skip several numbers (e.g. going from 00062 to 00065 on the next page)

Now I don’t know if you intended to be able to “batch” apply imprints across PDF files like this, but again, I think it would make the feature more convenient because otherwise you have to apply to each file individually or combine all PDFs into one file.

Thanks again for your time.

Note: I have the “Duplicate Item before imprinting” box checked. I tried unchecking this box to see what would happen and the results were worse (for some reason some of the pages turned a coral color).

Are you imprinting the same documents again and again while testing?

No I tried different documents.

The index/counter placeholders always start at 1.

To add to @rlamber3 points my testing of the Imprinter (Bates Number) configuration indicates that the counter is global, ie. not database specific. Thus if I have two different legal cases (in two different databases) the BN will not start at “1” in each database. Naturally this is even worse if you hold multiple legal case material in one database (different groups). Each case should normally start with a counter of “1”. I have tested different scenarios - even deleting databases completly and the BN just keeps incrementing.
Adding to the foregoing, batching is not possible. A recent submission I did involved over 21,000 documents - this type of volume needs automation - not clicking one at a time and imprinting. For example if you batch two docs it is number Page 1 of the first document say with “1” then Page 1 of the second document “2” then back to Page 2 of the first document and so on. Three batched documents mean the first document will be sequentially numbered 1, 4, 7 and so on.
Numbers are also not applied in the sort order of the selected documents. When batched the Imprinter seems to jump to whatever document it thinks it should use next - not in the sort order.
The Imprinter is faster than the scripts available that use PDFPen Pro BUT the Imprinter (with Bate Number) is erratic.
I have not explored further but generally Bates Numbered submissions require an Index indicating the start page BN for each document. If the Imprinter (Bates Number) function worked it does not seem possible to create the submission index without Applescript or some other techniques outside of Devonthink.
In legal circles I think the options to use an Imprinter configuration with Bates Numbers should be explored and developed further - noting the above comments. I do note that BN is used in multiple work environments - indeed when I started work in the 70s each new cheque payment request had a cover sheet applied with the next BN, etc.
On the plus side I keep finding more and more features in DTPro3 that make the product possible the best Document mgt DB available on the market. Keep up the great work.

Welcome @Quejinok
Thanks for the kind words and encrouagement!

We are investigating some of the behavior of the Imprinter.

Also, we were informed (by some lawyers, as well) that Bates Numbers are always supposed to be unique, i.e., you can’t reset them. We obviously are open to discussion on the subject though.

A screenshot of your imprinter configuration(s) would be great, thanks.

@BLUEFROG While it is correct that in a particular case each document should contain a unique BN, it is not the case that all documents ever produced in any case must have a unique BN. It is also important to note that the prefix of the BN also makes it unique. Here are some examples for clarification.

Let’s say that I am only going to make 1 production in a case. I would usually stamp the production with something like:
CASENAME-00001 to CASENAME-99999
In the next case, I would similarly stamp the production with something like:
NEWCASENAME-00001 to NEWCASENAME-99999

In that example, the counter reset, but each stamp is still unique (which is not even necessary when the production is for separate cases, but it can be helpful and most lawyers do assign a prefix like my examples show).

For another example, let’s say that we will be making multiple productions within the same case. For instance, I might produce one batch of documents that contains emails and a separate batch that contains other types of documents, such as contracts. In this case, I would usually stamp the documents with something like:

CASENAME-EMAILS-00001 through CASENAME-EMAILS-99999

and

CASENAME-CONTRACTS-00001 through CASENAME-CONTRACT-99999

In all of these examples, the whole stamp is unique, but the counting resets with each production. Not allowing the user to either reset or change the starting number creates numerous issues. For example, let’s say that an attorney’s cases involve hundreds of thousands or millions of documents. If the counter never resets, then the numbers will eventually become extremely high after several cases. It could literally get to the point where they run across the entire page. Think about a massive class action where one production alone might contain 100 million pages of documents.

I believe the best way to handle the bates counter is to default to “1,” but allow the user to change it to whatever he or she wants. This is important because, for example, let’s say the attorney needs to produce documents in multiple batches. What happens if something is included in the second batch of documents that should not be included, but the batch has already been stamped. The attorney would likely want to remove those documents and stamp the documents again. If he cannot manually change the starting number, then there would be an unusual gap in the document numbers. So you might have a batch stamped CASENAME-00001 through CASENAME-000150, then produce a batch stamped CASENAME-00200 through CASENAME-00250. This creates confusion. If I received two productions that were stamped as such, I would question the producing attorney about whether they forgot to produce the documents that appear to be missing.

PDFpenPro’s bates stamping function operates the way I have suggested. It defaults to either 0 or 1, but allows the attorney to change the counter to whatever number is desired. I think that is the best way for it to work. The way DTP3 currently works by literally never resetting the counter, even from one database to the next, makes it a completely useless feature for attorneys.

I hope that helps to clarify.

Yes your situation is clarified. Thanks for the particular insight. It is noted.

makes it a completely useless feature for attorneys.

I would have to disagree with this blanket statement as discussions with attorneys never came to all the same conclusions you did.

But again, your insight is appreciated and perhaps they handle things differently or perhaps we misunderstood something.

@BLUEFROG You are correct that I should not have made the blanket statement that it is a useless feature for attorneys. But I think if you ask the vast majority of attorneys who litigate that you will find that the majority use a convention similar to what I have suggested. If the numbers start getting really high, they will ultimately cause issues like what I discussed above, but other problems as well. For example, if you are at a trial and you need to reference a document, really high numbers can lead to problems. The attorney might miss one of the digits while reading the number or the individuals who are trying to find the document might not hear all of the digits. You could easily have 20 people that will need look in their binder to find a document you refer to. It is difficult for people to remember long strings of numbers. So the longer the number, the more likely it is that the attorney will have to repeat it multiple times before each of those 20 people is able to find the document. If he has to reference a lot of documents, then it can add a significant amount of time to the trial.

As I mentioned above, I should not have made such a blanket statement. However, the way that I suggested would still allow attorneys who do not want the numbers to reset, the way DT3 currently functions, would still be able to accomplish it because they could manually set what number to start with. But it would also allow attorneys that use a convention like I suggested to use DT3 also, instead of having to use a third-party program to apply BNs.

Thanks again and I will try to refrain from making blanket assertions in the future.

No worries! :slight_smile:

As I said, we also could have misunderstood or not probed deeply enough to uncover the things you pointed out. We are clearly not attorneys :wink::blush:

:slightly_smiling_face: :wink:

One thing I’m curious about: would there be multiple open cases on one litigators machine, each with its own Bates Numbering (and surely it’s own prefix) ? I’m assuming it’s definitely possible, but wonder if that would be common.

@BLUEFROG Yes, I keep each case in its own database and I will often have two case databases open at the same time. I always use a prefix with bates numbers that is unique to the particular case and I think that most attorneys do the same. I might have both databases open because it is two cases against the same Respondent/Defendant but the Claimant/Plaintiff is different, and I want to look at something in the other case. I also will often be working on something for one case, but get a call from a client or opposing counsel and need to pull up the database for another case. It is actually fairly common for me to have two case databases open at the same time. But the prefixes that I use will always make the BN unique.

Interesting stuff for us to consider. Much appreciated.

@BLUEFROG DT3 is an awesome product. I literally use it everyday. I am more than happy to contribute to making it even better than it already is. Let me know if you think of any other questions that might help.

Best,
James

Thanks for the kind words and offer. It’s always good for us to get differing perspectives on how people use our applications.

You’re welcome.

One more thing. In the example I gave above where a massive class action might have millions of pages of documents. They will often actually break it up into multiple smaller batches with different prefixes and restart the numbering. It is for the same reason that I gave when I was referring to an attorney reading a BN to 20 people at trial. It is much easier to reference ACTIONNAME-EMAILS-000150 than it is to reference ACTIONNAME-9853213456.