Once an outgoing document is being sent to the Trade Partner through the Procuros API, it should be marked for two reasons:
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:
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:
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.
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.
Once an outgoing document is being sent to the Trade Partner through the Procuros API, it should be marked for two reasons:
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:
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:
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.
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.