Record not processed because submitted version: 1643750256 is less or equal to previously submitted version {1} (403 Forbidden)

Description of issue or problem I’m having:
When I try to do the DOI deposit using the Crossref export/record plugin the OJS returns the following error: Record not processed submitted because version: 1643750256 is less or equal to previously submitted version {1} (403 Forbidden)

Steps I took leading up to the issue:

What I tried to resolve the issue:
I already changed the date of publication in a few days for more and for less, I already revised the dates of the references and the error message persists when I try to deposit the DOI…

Even so, the DOI is working and is apparently logged, but the error message in the OJS persists as a deposit failed.

How should I proceed?

Application Version - e.g., OJS 3.1.2:

I’m using OJS version 3.3.0.6.

Additional information, such as screenshots and error log messages if applicable:

the email I get from Crossref references errors in some references:

<?xml version="1.0" encoding="UTF-8"?>

<doi_batch_diagnostic status=“completed” sp=“ds3.crossref. org”>
<submission_id>1519817465</submission_id>
<batch_id>_1643895707-18754</batch_id>
<record_diagnostic status=“Success”>
10.52572/revchronosurg.v1i1.26
References processed successfully
<citations_diagnostic>
10.1590/1413-812320212610.26102020
10.1590/1413-81232014192.18032012
10.1590/S0034-89102012000300020





10.1590/0103-11042018s416
10.1590/S1414-32831997000200008


10.1590/S0102-311X1997000300022
10.1590/S1413-81232010000500005
10.5752/P.1984-6606.2014v14n36p85

10.1590/S0104-12902005000300004
10.1590/s0104-12902017170017

10.18542/complexitas.v1i1.3413

10.1109/HealthCom46333.2019.9009439

10.1590/S1806-11172008000200009

</citations_diagnostic>
</record_diagnostic>
<batch_data>
<record_count>1</record_count>
<success_count>1</success_count>
<warning_count>0</warning_count>
<failure_count>0</failure_count>
</batch_data>
</doi_batch_diagnostic>

Hi @claudioazevedo. Thanks for your message, and welcome to the community forum.

The error message ‘Record not processed submitted because version: 1643750256 is less or equal to previously submitted version {1} (403 Forbidden)’ indicates that the timestamp in your deposit is numerically lower than the timestamp used in a previous deposit.

Every deposit has a value, and that value needs to be incremented each time the DOI is updated. The timestamp errors do indicate that the DOI has been deposited, so if the metadata and URLs previously deposited for the DOIs are correct no further action is needed. You can find the most recent timestamp by reviewing your past deposit XML. Timestamps are also listed in the depositor reports available here: crossref.org : : depositor

This sometimes happens for OJS users when a DOI or set of DOIs was previously registered using a different submission method (our web deposit form or via an XML deposit).

I have reset your timestamps for the DOIs in submission https://0-doi-crossref-org.lib.rivier.edu/servlet/submissionAdmin?sf=rerun&submissionID=1519868684 and successfully reprocessed that submission (see submission log below).

For the references in the submission with the status of ‘resolved_reference’, it means we have matched that reference to an existing Crossref DOI. For the references in the submission with the status of ‘stored_query’, it means that we do not match this reference to an existing Crossref DOI. Thus, we have stored this reference and we’ll retry it in the future in case a DOI is registered that matches that reference.

<?xml version="1.0" encoding="UTF-8"?>
<doi_batch_diagnostic status="completed" sp="ds4.crossref.org">
   <submission_id>1519868684</submission_id>
   <batch_id>_1643935227</batch_id>
   <record_diagnostic status="Success">
      <doi>10.52572/revchronosurg.v1i1</doi>
      <msg>Successfully updated in handle</msg>
   </record_diagnostic>
   <record_diagnostic status="Success">
      <doi>10.52572/revchronosurg.v1i1.26</doi>
      <msg>Successfully updated</msg>
      <citations_diagnostic>
         <citation key="694" status="resolved_reference">10.1590/1413-812320212610.26102020</citation>
         <citation key="695" status="resolved_reference">10.1590/1413-81232014192.18032012</citation>
         <citation key="696" status="resolved_reference">10.1590/S0034-89102012000300020</citation>
         <citation key="697" status="stored_query"></citation>
         <citation key="698" status="stored_query"></citation>
         <citation key="699" status="stored_query"></citation>
         <citation key="700" status="stored_query"></citation>
         <citation key="701" status="stored_query"></citation>
         <citation key="702" status="resolved_reference">10.1590/0103-11042018s416</citation>
         <citation key="703" status="resolved_reference">10.1590/S1414-32831997000200008</citation>
         <citation key="704" status="stored_query"></citation>
         <citation key="705" status="stored_query"></citation>
         <citation key="706" status="resolved_reference">10.1590/S0102-311X1997000300022</citation>
         <citation key="707" status="resolved_reference">10.1590/S1413-81232010000500005</citation>
         <citation key="708" status="resolved_reference">10.5752/P.1984-6606.2014v14n36p85</citation>
         <citation key="709" status="stored_query"></citation>
         <citation key="710" status="resolved_reference">10.1590/S0104-12902005000300004</citation>
         <citation key="711" status="resolved_reference">10.1590/s0104-12902017170017</citation>
         <citation key="712" status="stored_query"></citation>
         <citation key="713" status="resolved_reference">10.18542/complexitas.v1i1.3413</citation>
         <citation key="714" status="stored_query"></citation>
         <citation key="715" status="resolved_reference">10.1109/HealthCom46333.2019.9009439</citation>
         <citation key="716" status="stored_query"></citation>
         <citation key="717" status="resolved_reference">10.1590/S1806-11172008000200009</citation>
         <citation key="718" status="stored_query"></citation>
      </citations_diagnostic>
   </record_diagnostic>
   <batch_data>
      <record_count>2</record_count>
      <success_count>2</success_count>
      <warning_count>0</warning_count>
      <failure_count>0</failure_count>
   </batch_data>
</doi_batch_diagnostic>

Please let me know if you have any additional questions.

Kind regards,
Isaac

thanks for all Isaac.

I haven’t more questions

1 Like

Hello @ifarley

How to know/monitor if one reference with the status=“store_record” had a DOI associated to it after the DOI registration.

Fabio

Hi @fabiobatalha ,

How to know/monitor if one reference with the status=“store_record” had a DOI associated to it after the DOI registration.

Good question! We do store these references and then attempt to match them to DOIs registered with us in the future. We rerun these stored records on a rolling basis. Time between when we perform those reruns is increasing as the amount of records and references registered with us increases (it’s a resource-intensive process). Right now, we rerun these stored records about once per year to see if anything has been registered that matches the information in the reference metadata.

The easiest way to confirm if a stored record has converted into a matched reference is using our cited-by service. Our admin tool provides the most straightforward way to do this.

I’m including an example from DOI 10.1590/1413-812320212610.26102020, one of the DOIs included in the reference list of DOI 10.52572/revchronosurg.v1i1.26, which has been discussed above in this thread.

Using the Queries > Cited By Links tabs in the admin tool, you can see that DOI 10.52572/revchronosurg.v1i1.26 is one of the 8 Crossref DOIs that has cited DOI 10.1590/1413-812320212610.26102020.


I hope this is helpful,
Isaac

Thanks @ifarley . Yes it is helpful to know.