Bug Fixes - Version 10.1.47 - Released 5 June 2020

×
This build has the following bug fixes implemented: 
Better
11825548 - Change M1 Connector Error to Warning
If a part in the M1 ERP has no WarehouseBins, the BirdDog Connector Sub-System was throwing an error that would not allow the system to progress. We changed that to a warning per standard policy.
Fixed
11825626 - CyberSource Trx Showing as Unknown Tender in Cash
When using our Ca$h software to captured credit card orders from the web that utilize CyberSource as the payment gateway, these orders were displaying Unknown Tender instead of Visa or MasterCard, etc. Now they showing the tender type properly.
Better
11825806 - Ship Date or Fulfillment Date Not Between Order Date and Now
The Amazon connector was not handling time zones correctly causing errors in certain scenarios.
Better
11825875 - Price Change on Charge Type Misc. Item in Service Pro Order is Not Synced To Sage
When a miscellaneous item with Item Type set to "Charge" was added to an order in Service Pro and the Unit Price was changed, the price change was not synced down to Sage properly with the BirdDog Connector Sub-System.
Fixed
11826029 - Shipping Easy Throws Error on Run
A low-level update to the change tracking sub-system broke the ShippingEasy Connector.
Fixed
11826112 - Orders Not Downloading From Amazon
While using the BirdDog Connector Sub-System against Amazon, some orders were not downloading properly due to a "Request is throttled" error. This resolves that issue.
Better
11826393 - Unknown Debtor Attempting to be Uploaded on Every Run
When attempting to run the ServicePro Connector against a Macola M10 ERP for the first time, the connector attempted to upload customer #000000 (Unknown Debtor) on every run and threw an error referring to an Invalid Terms Code refenced by Customer '000000'. This code references a default account created by Macola (along with CusNo 000001), so we changed this message to a warning that fires once and goes away.
Fixed
11826627 - Fixed Guest Customer Handling in WooCommerce Connector
Originally observed when trying to download an order with from WooCommerce with a newly created customer on that side, we determined that this was initially due to Woo not being setup properly to handle new customers so you could generate an order that did not actually have a customer on it (which is not legal in BirdDog); in the process, however, we determined that we were not handling Guest Customers (which is what this really was) properly. Now, if no customer is actually assigned to the order, the BirdDog Connector Sub-System will automatically presume this is a guest checkout and use the guest customer set up for this purpose.
Better
11826701 - Customer Data Not Downloaded Prior to Running Two-Way Customer Sync
To deal with a prior mapping issue, after updating to this build, we will do a one-time re-download of all customers from Sage 100 the next time BirdDog Connector Sub-System is run.
Fixed
11826747 - WooCommerce Orders Without Shipping Address Should Automatically Download with Shipping Set to Billing Address
In the process of resolving 11826627 above, we also made an adjustment to how we handle WooCommerce orders and Shipping Addresses; depending on how your WooCommerce site is set up, a new order might not have a Shipping Address on it, which was causing additional heartburn as it is not legal in our system. We tweaked the code so if no such address exists, the system will automatically use the billing address.
Fixed
11826797 - ShippingEasy Error Sequence contains more than one element
The ShippingEasy system, which we began supporting in 10.0, offers the ability to split up an order so, for example, you could ship one widget immediately, two more next week, and two more the week after. Unfortunately, our initial support of the ShippingEasy integration did not anticipate that scenario, so when it the BirdDog Connector Sub-System tried to write back to the ERP with tracking numbers for the second shipment, the system choked and threw an error. In retrospect, this was a pretty obvious scenario and a concept we already supported elsewhere, so we fixed the code.