Feature Request to AVOID Duplicate Order Numbers


#1

Description: Add a business rule to order creation using the API that effectively does not allow duplicate order numbers/names (order_number) - even when 2 simultaneous requests are made to create an order.

Why is this feature important? We currently use the API to push/import orders into Tradegecko from multiple external sources. Sometimes if a order is created at the “same time” Tradegecko will assign the SAME next sequential order number to multiple orders. This causes issues from us when we need to use the API to lookup orders by order number - basically it finds the wrong order due to the duplication.

If we do not work on this feature, how will this impact your business? I will continue to have more instances where duplicates must be sorted out manually. When there are delays due to these conflicts I will lose customer trust and profit.


#2

+1 for this - we have the same thing, for the same reason - order created by the API. If we get two in the same minute we get a duplicate PO.


#3

Just had it happen again last week - caused all sorts of issues for us until I tracked down the culprit. Ugh!


#4

Hi Marc,

Thanks for following up here! I have opened the conversation with my engineering team to see if this is possible and will follow up with an update shortly!

Thanks!


#5

It is possible to update the PO number? Does the api let you? So within the code that calls the API you could then do a quick search for that PO number once you’ve created it, and make sure you only get 1 back, then assign a new PO if necessary?


#6

Roger, I have thought of how to solve this but have not attempted yet to address it - since I believe this is a TG issue (until they tell me otherwise). By the way, it is not as easy as checking first if the order number exists - for 2 reasons: 1) the issue is occuring due to simultaneous requests, so by the time I check and respond, the number could be in use… and more importantly, I am not assigning the order numbers - they are auto-generated by TG each time we create a new order using the API…

Solution 1: I could no longer have TG assign my order numbers sequentially, and instead have my code assign order numbers (but will need to check on last order number used - since TG would take web-portal orders and continue my progression)

Solution 2: I could use the API as I currently am, but after every order the API creates in TG I would then check to see if the order number just assigned already exists in TG - and if so, change it using the API. In the web portal you CAN change an invoice number - but only if it is in draft or active (not finalized) - So, assuming the API also allows this (untested) I would need to change my initial creation of each order to be status:“active” and then only change status to “finalized” after confirming the order number is unique.

Thoughts?


#7

I have reduced the occurences of this happening in my app using semaphores. Because I only have one API application this means I can wrap a whole business process in one semaphore and effectively prevent writes from more than one place at once - they just queue up. This seems to have solved the problem without having to query for order numbers. Now, if you have multiple applications running in multiple contexts all calling your TG account you may need to create a front door for TG to do this - basically to act as a dispatcher to control the number of accesses you are making to TG. I’m working in Node at the minute, and am using the semaphore library, but the same would be true in Java using synchronized methods. You need to add your own API call which acts as a gatekeeper to the TG API, and you can then limit access. There are probably other ways of doing it with Apigee or other API gateway technologies.

Also, I’ve found that updating a PO number appears to work, but clearly doesn’t quite update everything because a search for the old number will still bring up both POs, even though in the results the new PO is showing the new number, which is a little odd. It could be a result of search indexes not being updated - I don’t know.

This also means I am only using PO IDs to look up POs now, and not PO numbers. So I have a dropdown list the user selects from (which could have two POs with the same ID but (probably) different suppliers) but the “value” parameter behind it is a PO ID not the PO number.

This combination of things seems to have solved our problem. If you want more technical details / assistance drop me an email on roger AT softfox.com