Once an outgoing document is being sent to the Trade Partner through the Procuros API, it should be marked for two reasons:

  1. To make sure it is not sent again
  2. To give users transparency regarding the status of their documents

Most ERP systems have some way to attach information to documents. If the ERP system you are building a connector for does not support this, please get in touch with us to find an alternative solution.

These data fields should be made available on all outgoing documents:

​
Rules

  • If Procuros accepted the transaction and intends to forward it to the receiving Trade Partner, it will respond with a 201: Created status code. In this case, the document Status field should be set to TRANSMITTED.

  • If Procuros accepted the transaction but does not intend to forward it to the receiving Trade Partner, it will respond with a 202: Accepted status code. In this case, the document Status field should be set to NO_ACTION. Possible reason for Procuros not to forward documents:

    1. The trade relationship between the sender (you) and the receiving trade partner is not (yet) active.
    2. The receiving trade partner is (currently) not accepting documents of this type

  • If Procuros did NOT accept the transaction, it will respond with either a 422: Validation Error or a 400: Bad Request status code.

    In this case, the document Status field should NOT be set to make sure the document will be retried the next time you are processing outgoing transactions. The response from Procuros will contain a link to view the error on the Procuros Portal. You can optionally add this link to a “Error URL” field attached to the document you were trying to send, giving users easy access to view and resolve errors.

  • Only documents that have an empty Status field should be retrieved from the ERP for sending via Procuros.

​
Retrying Documents

If a document has failed to send to Procuros, as per the rules above it should not be marked with one of these statuses: TRANSMITTED or NO_ACTION.

You should instead retry the document until it is able to be handled by Procuros. This should occur by the ERP administrators making changes to the document to resolve why it was not valid.

This is why you must report any errors documents have via the API, in order for Procuros to notify the customer.

​
Caveats

  • Depending on your use case, if you are polling for data very often, you may not want to send a document error every time you poll for data. Instead, you may want to send an error only after a certain number of retries. This is up to you to decide.