Version 11

When using a customization that automatically Selected an order when the ShippingEasy Connector was run, we discovered that our process was Selecting the entire order instead of just lines that were shipped. This was important if a customer, for example, split up an order in ShippingEasy and shipped out only some of the lines on the order.

When trying to print an Order Acknowledgement, it failed with a "Report could not be found" error even though report paths were set up correctly in Enterprise for Windows, report files exist in the specified folder and the FormType is set to the correct filename in Enterprise for Windows | Maintain | Setup | Distribution Forms.

Updated the process of setting tax on an order being downloaded from Shopify using the Shopify Connector to not error out if the percentage can't be represented; it now reports a warning and downloads the order.

Unreconcilable errors caused by order changes were showing up on every Amazon Connector run. They are now reported as an error one time.

A low-level function that duplicates shopping carts was missing a handful of properties such as Bill_To_Addr_3, Ship_To_Addr_3, Sales_Person_No, Ship_Via_Code, Loc, and Taxable.

When using the BirdDog Connector Sub-System for Magento, changes made to prices in the ERP were not syncing up correctly.

The Estimated Duration field on the Incident Form page was not properly autocalculating into a proper date format based on Due Date minus Start Date and instead, displayed as (for example): 2020y 41w 2d.

Adjusted the code to handle bad data better with M1 using the BirdDog Connector Sub-System by changing an Error (that stopped all progress of the connector run) to a warning.

When creating a new cart from a saved cart, items in the new cart were using the saved cart price, rather than using the current item price.

In Ecommerce, when editing saved Ship-Tos in the Address Book, clicking Save didn't make the edit screen disappear and changes weren't saved.

Some default data in Inventory Setup was not being set correctly to match data in M1 using the BirdDog Connector Sub-System.

The value in cicmpy.cnt_id should normally match a value in cicntp.cnt_id. If it doesn't, you have invalid data. When a user connected to a customer with invalid data like this attempts to login, they get weird errors and had to log in twice.

Previous versions of the software required an email address for any customer to be uploaded since Avalara CertCapture can send certificate requests via email. However, this caused integration issues when customers were uploading existing sales tax certificates to CertCap for customers without an email address on file. Email addresses are no longer required to upload a customer to CertCapture.

When using the Auto Cash Receipts import tool with Macola Progression, the [reference] field that is set in the [ARCSHAPL_SQL] table when importing a Wire payment (code=W) did not match the standard format that Progression uses.

Fixed a typo in an error message. Company was misspelled.

Orders generated in Woo Commerce that were pulled down into a Sage 100 environment while using the BirdDog Connector Sub-System were writing into Sage with 0 quantities.

At Checkout, if you selected a Ship-To other than the default and then navigated away from the Checkout page and back to Checkout again, the Ship-To displayed under Shipping Information reverted back to displaying the Default Ship-To (or No Address Selected, if there is no SelectedShipTo assigned to the cart), but the system still used the Ship-To that was selected before navigating away from Checkout (i.e. freight rating is still for the selected Ship-To, even though the default Ship-To is now being displayed under Shipping Information). Now, the system keeps the Ship-To that you've selected.

Contacts created or edited in Sage 100 now write up to the BirdDog environment when using BirdDog Connector Sub-System.

With this build, we updated the BirdDog Connector Sub-System to upload all BirdDog Contacts that have a relationship with an Organization that have a Customer Number. When downloading an order from WooCommerce, we assign the order to the customer number that the contact is related to. If the contact is related to more than one customer, we then use the Customer that the User is linked to, and if the contact has more than one User/Customer, than we report an error and don't download the order until it is corrected.

With this build, we mapped Macola ES customer contacts to BirdDog contacts. A connector entry must be created for BirdDog Connector Sub-System for this functionality to work.

Contacts created or edited in BirdDog now write down to the Sage 100 environment when using BirdDog Connector Sub-System.

With this build, we mapped BirdDog contacts back to Macola ES contacts. A connector entry must be created for BirdDog Connector Sub-System for this functionality to work.

The My Account>Address Book has two different layouts depending on the number of addresses you have: list all or search. Before this update, the system switched from the list to the search when you had 5 or more addresses. This update increases that threshold to over 20. We also added the ability to customize this setting; see this page to see how to use this.

Previously, the utm_cid as a query string parameter needed to be a value from the BirdDog BRAIN campaign system. We updated the process page hits job to support this value also being a BirdDog User ID to support integrating with email systems such as Constant Contact or Mail Chimp.

For use with the timesheet functionality in BRAIN, we added an Out Sick status that works pretty much the same way as Out for the Evening or Out on Holiday.

When running an initial download against an existing Service Pro company for a new BirdDog database using the Service Pro Connector, a considerable amount of orders threw a "You cannot change the sign of quanitity ordered on an existing line" error.

When attempting to download a G/L account from Sage 100 using the Sage 100 Connector with a Main Account Code of 0000, the connector threw an error and didn't download the G/L account.

Updated the Sage 100 Connector to handle invalid Ship To data better and report as a warning.

This fixes potential revision errors when updating older BirdDog databases.

When a field was synced down to Sage 100 from Service Pro via the BirdDog Connector Sub-System and it was changed in Sage, instead of syncing this new information back up to the Service Pro order, the changed data was being overwritten by the original data. While technically a bug fix, the amount of coding adjustment necessary to resolve this prompted a new branch.

When adding Orderlines that contain Miscellaneous items on an order in Service Pro, occasionally orderline data is not getting synced completely and sometimes an orderline doesn't go to Sage at all.

Updated the application controller (AppCon.vb) example code to show how to load a user from the current windows user. Updated the Getting Started docs to better explain what the Application Controller is responsible for.

When you ran "Fill Back Orders", the Promise & Required Ship Dates were not updated which could prevent the item from getting picked. While reviewing this, we determined that the Required Ship Date was defaulting from Promise Date instead of Request Date.

When receiving inventory against an item/location that was currently frozen if the transaction date was before the freeze date, the frozen quantity and cost were not being updated.

In Enterprise for Windows, the Send Request button on Maintain | Customers | Tax Certifications was hard-coded to submit "Form #48", which used to be Avalara's default request form. We changed that to be a value that can be set in the BirdDog Connector Sub-System screen for Avalara CertCapture.

This was a design flaw. By only uploading tax-exempt customers to CertCapture, we required our customers to set the customers they want to track to tax-exempt. This caused Macola to default all orders to tax-exempt. When communicating with AvaTax, we send the tax-exempt flag on the order which essentially sets every transaction as tax-exempt.

A bug in a specific process was causing the database revision process to create indexes with incorrect names which was causing certain schema changes to fail.

When using the BirdDog Connector Sub-System against Avalara CertCapture, you are able to test your CertCap credentials in the connector screen but it did not give you any idea what the issue was if something was wrong. We updated the test button to include the error message when it fails.

These missing indices caused two issues: the system could create duplicate records and performance problems on larger sites.

When the Sage 100 Connector was created in 2018, it was built upon the synchronization engine used by our Ecommerce platform for almost two decades. We refer to this system as Trigger Audit internally. This system was built with two purposes - audit row-level changes for every watched table and trigger synchronization based upon those changes. The change tracking was very helpful for auditing issues in an Ecommerce environment where it is difficult to get steps of what happened from an end user. The downside was that it generated a lot of data and the conversion of the audit logs to change events didn't always perform very well. Another issue was that the Ecommerce environment was almost exclusively a one-way sync - item and customer data would go up and sales orders would come down. The addition of two-way sync for customers, ship tos, and sales orders in 2019 across multiple connectors exacerbated the downsides of the trigger audit system. Because of these issues, we went back to the drawing board and created a system that was tightly focused on handling change events in the most efficient manner possible. We refer to this system as Row Version internally. This system was first deployed to our M1 Connector in 2019 with great success. With the completion of this project, the Sage 100 Connector has now been fully converted to the Row Version system. The change from Trigger Audit to Row Version requires a data conversion. This conversion is completely automatic but does require a managed cutover from a prior version. This data conversion is what caused the point increase from 10.x to 11.x. For customers that are not using the Sage 100 Connector, 11.x can be treated as a point release to 10.x.

Similar to 11831207 above, but for Service Pro instead of Sage 100. The change from Trigger Audit to Row Version requires a data conversion. This conversion is completely automatic but does require a managed cutover from a prior version. This data conversion is what caused the point increase from 10.x to 11.x. For customers that are not using the Service Pro Connector, 11.x can be treated as a point release to 10.x.

The Enterprise Windows client already allows for command line calls as noted here, but this build adds the Maintain |Customers | Tax Certifications functionality for use with Avalara CertCapture.