A procedure was added to OneBox SRM, which records the value '1' in an additional field every time an order is saved. On the basis of this field, the implemented integration between the OneBox - 1C system has currently disappeared
Description of the problem:
A procedure has been added to OneBox SRM, which records the value '1' in an additional field every time an order is saved. On the basis of this field, the integration between the OneBox - 1C system is implemented (this additional field serves as a sign of the need to update
of the order object). After the update (we assume the last one), the response behavior of this procedure to the update of the order through the API has changed.
Previously, before the update, editing an order through the API did not "trigger" this procedure, and after reading/integrating the changes, each read order was assigned a corresponding flag ('0'), based on which such an order is made in the future
was not processed.
At the moment, when editing an order through the API (writing '0' in the additional attribute field) triggers the procedure described above, and the system interprets such an order as an updated one and accordingly re-writes the value of the attribute to '1'.
Thus, there is no way to mark the completion of reading and you have to read absolutely all orders (of which there are thousands)
Description of a possible modification:
Option 1. Do not interpret the order (or other process) as changed when a specific additional field is updated (field name - 'update_o', field identifier in the system - 'update')
Option 2. Do not treat the order (or other process) as changed when its additional fields are updated through the API
Option 3. Do not treat the order (or other process) as changed when it is updated via the API
Priority is in descending order. We want to order a solution to this problem for money!!!!!!!
Original question is available on version: ua
A procedure has been added to OneBox SRM, which records the value '1' in an additional field every time an order is saved. On the basis of this field, the integration between the OneBox - 1C system is implemented (this additional field serves as a sign of the need to update
of the order object). After the update (we assume the last one), the response behavior of this procedure to the update of the order through the API has changed.
Previously, before the update, editing an order through the API did not "trigger" this procedure, and after reading/integrating the changes, each read order was assigned a corresponding flag ('0'), based on which such an order is made in the future
was not processed.
At the moment, when editing an order through the API (writing '0' in the additional attribute field) triggers the procedure described above, and the system interprets such an order as an updated one and accordingly re-writes the value of the attribute to '1'.
Thus, there is no way to mark the completion of reading and you have to read absolutely all orders (of which there are thousands)
Description of a possible modification:
Option 1. Do not interpret the order (or other process) as changed when a specific additional field is updated (field name - 'update_o', field identifier in the system - 'update')
Option 2. Do not treat the order (or other process) as changed when its additional fields are updated through the API
Option 3. Do not treat the order (or other process) as changed when it is updated via the API
Priority is in descending order. We want to order a solution to this problem for money!!!!!!!
Answers:
Please join the conversation. If you have something to say - please write a comment. You will need a mobile phone and an SMS code for identification to enter.
Log in and comment
Copyright © OneBox 2024
