Add optional parameter to Get Business Partner By AccountingID

#1

Hello,

I need to be able to retrieve a specific Customer or Vendor via their AccountingID (where we are storing our accounting system’s ID) AND the PartnerType. This is because our accounting system has separate lists and numbering schemes for Customers and Vendors which can potentially overlap (e.g. Customer #1000 and Vendor #1000).

By my eyes, I do not see a way to do this in the API, but I may be wrong. It seems that GetBusinessPartnerByAccountingID only retrieves the first BusinessPartner record it finds, if there are multiple with the same AccountingID. If that is the case, I would think the cleanest solution would be to add an optional parameter (or an override) to the method, allowing you to pass in the PartnerType as well.

Please let me know if you need any clarification on this or have follow-up questions.
Thanks so much,
Alex

#2

Have you tried using BusinessPartner.GetBusinessPartnerByNumber(string partnerNumber) method instead? This will work better if your master data has a unique (human readable) string for each customer and vendor involved with your integration.

#3

Hey Matthew,

Good idea - I had thought about that but I am coming from the other direction unfortunately: from the accounting system to Quantify. Our accounting system is our system of record for Customers/Vendors, and then we generate transactions out of Quantify on those master data entities. So the only field I will have to look it up with with the API is the ID from the accounting system (the AccountingID).

My thought is if I need to work around it, we can append a ‘C’ or ‘V’ accordingly to make the AccountingIDs unique in Quantify, and then trim that off when we send transactions the other direction back to the accounting system (e.g. Invoices). However, I would like to avoid that if possible, so we will see what Avontus comes back with.

#4

I’m wondering why what Matthew brought up won’t work? If you’re coming at it from your accounting software, then you’ll essentially have the accounting ID. This line should work.

BusinessPartner.GetBusinessPartnerByNumber(string partnerNumber);
#5

Hello,

Apologies, I will explain more - we have a one-way integration of Customers and Vendors from our accounting system to Quantify, and a one-way integration of transactions on those Customers and Vendors from Quantify to our accounting system. Our accounting system’s Customers and Vendors can share an ID, because of how it is architected.

Here is the scenario I run into:

  1. Customer 1000 integrates from accounting system to Quantify.
  2. We run GetBusinessPartnerByAccountingID and see that it does not yet exist in Quantify, so a Customer record is created, with partner number CUS-1234 (for example). We store 1000 in the AccountingID field.
  3. Vendor 1000 integrates from accounting system to Quantify.
  4. We run GetBusinessPartnerByAccountingID, which comes back with a record - the Customer record. That causes the code to do an update - so the Customer’s data is overwritten with the Vendor’s data.

In step (4), if I coded it so: ‘if it exists and it is a Customer, create a Vendor’, then that would only work for the first integration - the second it would attempt to create another Vendor, and either create a duplicate or error (both of which are bad).

In step (4). if I did GetBusinessPartnerByNumber(1000), it would not work - because we do not store the ID from our accounting system in the PartnerNumber field.

The accounting system does not know what the PartnerNumber in Quantify is for its given AccountingID; all the accounting system knows of is the ID in the accounting system (AccountingID). That is how we architected it per recommendations - the accounting system’s ID belongs in the AccountingID field, and the partner number is Quantify’s ID - which in our case is different due to business requirements.

Does this clear things up as to why I need to look up by both AccountingID and PartnerType? Please let me know if I can clear it up any further.

Thanks,
Alex

#6

Currently, my workaround is I have the code throw an error if we try to integrate a Customer/Vendor and there is already one of the opposite entity with the same ID.

This at least prevents a Customer/Vendor from having its data updated erroneously, but it then requires manual user intervention to add in those Customers/Vendors into Quantify that error due to this.

#7

I would recommend that you use the unique ID for each customer or vendor (from your accounting system) in the AccountingID for the business partner in Quantify. If you do that then you won’t have any troubles looking them up. This is pretty much what we built it for, a lookup value for a 3rd party system.

I guess your other option is to retrieve the entire list of customers and vendors from Quantify and traverse through them to get the one you want based on some of your other criteria. Note that this will be a very expensive and time-consuming operation, so I’m not sure I’d really recommend this unless you only need to do it once/day or something like that.

#8

I had thought of the second option you outlined and I agree - that would be too expensive an operation, and this will likely run at least 5-10 times a day.

As far as the first option goes - I must not be makinig this part clear: our accounting system does not have a unique ID for the customer/vendor. So, we can have a customer #1000 and a vendor #1000 coming from the same accounting system.

#9

In other words - our accounting system has unique IDs for the list of Customers, and unique IDs for the list of Vendors, but not unique IDs for the combined list of both Customers and Vendors.

Does that make sense?

#10

If you know you need to fetch a vendor or a customer from your system, and know the type when you’re setting it up, maybe you could prepend “C” and “V”, or something like that? Seems really weird that they wouldn’t have unique numbers.

#11

I agree it is strange; unfortunately there is nothing that can be done on my end for that.

Yes - appending the ‘C’ and ‘V’ is a workaround solution I posed above, however I would like to avoid that if at all possible. There are already a steady stream of transactions running through this integration in production (we only noticed this post-rollout), so it would require a data fix script to resolve, as well as a cutover/user outage (since we will need to lock the system to ensure data integrity while our script runs).

We could append the C and V accordingly manually for existing Customers/Vendors, but there are roughly 4,000 active customers and 6,000 active vendors each in our production instance of Quantify currently. Finally, to send the transactions to our accounting system (POs, SOs, Invoices, etc.), I would need to then strip off that C and V to return the original ID. This is possible, but does require about a dozen or so touch points in my code.

Is there really nothing that can be done to accommodate this request? I know I do not know the architecture of the Quantify API as well as your team obviously, but I figured adding a method override to pass in the TradingPartnerType would not be a significant add. Unless it adds complexity that it is kept in a separate SQL table from the other BusinessPartner data?

#12

Gotcha! Would this override work?

BusinessPartner.GetBusinessPartner(PartnerTypes partnerType, string partnerNumber);
#13

Sorry, I meant to put accounting ID. This would be the suggestion, right?

BusinessPartner.GetBusinessPartner(PartnerTypes partnerType, string accountingID);
#14

Yes, that is exactly it - apologies I probably could have just typed it out myself too to avoid confusion.

Is that possible/does it work from a code architecture standpoint on the API side? This would solve the problem outright, and make our lives a lot easier.

Thanks so much,
Alex

#15

Hi Alex.

This has been updated in the API. Posting the URL to pre-QA build here -

Quantifyx64.exe (90.4 MB)

For the API applications, it may be required to refresh the Library DLL

Thanks for posting