We implemented SAP ECC 6.0 about 3 years ago, including all core modules, as well as SCM ICH , APO/DP and BW. As part of the implementation, we chose Vertex Q Series for the Sales Tax Jurisdiction and Tax rate determination functions since it was one of the SAP certified offerings available in the market.
At the time of selecting the software, we had a choice between Vertex Q series and Vertex O series product lines. We were assured by Vertex that both these products were fully capable of meeting our needs. We were also told that the ‘O’ series implementation was more involved while the ‘Q’ series product was easily installed and implemented.
We were on a very aggressive implementation schedule, due to various business considerations, including the fact that our business by nature is very seasonal and our window of going live were between the months of July through September, otherwise, we would have to wait a whole another year.
We started the project in December ’07 and were to go live August 1, ’08! In addition to Vertex, we had to also implement other packages such as Open Text Livelink, Paymetric PCI and also build custom interfaces to other legacy systems that would continue to exist post-SAP go-live. In addition, we had to interface a ton of EDI transactions as well.
Given this backdrop, we opted to implement the ‘Q’ series from Vertex. As advertised, the install and implementation of this product were fairly straight forward. We did have some issues integrating with SAP, but that was mainly due to the SAP implementation team’s inexperience in this regard.
We went live on Oct 1, ’08 and had a very difficult first 6 months thereafter as is quite common with any ERP implementation and especially with projects like ours, with such aggressive implementation times. We immediately started facing numerous issues with the Vertex Q series, almost all of them relating to US City/Zip codes that when entered on SAP Customer Masters / Vendor Masters or Ship-To addresses in Sales Orders returned ‘No Jurisdiction Determined’ error, even though these were either ‘Actual’ city names or ‘Acceptable’ city names according to the United States Postal Service official web site.
We called Vertex support and each time, we were told that the cities in question were not supported in their database because those cities did not meet their ‘criteria’ for inclusion. They always also made it a point to tell us that the Q series was not an ‘Address Verification’ system, even though we were not using it for such purposes.
Initially we asked users taking the orders to enter a suitable city for that zip code that was the one stored in Vertex for that zip-code and in the same county as the ‘missing’ city. However, we ran into problems with this because we had shipments going to the wrong place when the same street name existed in both cities!
We then implemented a workaround via user exit and z-table to pass the actual city name to Vertex, for such instances and adding entries to this table as and when users reported new instances. This was manageable for a while, but over time, we are seeing more and more entries being added to the table as our company begins collecting taxes in more states.
Recently we ran a listing of such missing cities in the Vertex database using a zip-code database we subscribe to for our Dealer location calculation and found almost 7000 missing cities that USPS considers ‘Acceptable’. We also found more than 100 cities that USPS terms as the ‘Actual’ cities for those zip codes.
We also discovered that the Vertex Q series only stores first 25 characters of the city name, even though SAP allows up to 40 characters and there are a number of cities in US / Canada whose city name exceeds 25 characters.
We have sent this list to both Vertex and SAP. We had conference calls with Vertex , including personnel from their ‘Research’ department and Product Development and while sympathizing with our problems and admitting that there is a gap in the core functionality, they have refused to add any of the cities in the list provided and also refused to add any expansion of the functionality to accommodate these cities. Instead, they are asking us to implement an address verification software (3rdparty) that will sit between SAP ECC and Vertex and provide Zip+4 codes that may find a hit in the Vertex Q series database. They do not have a solution using this approach that they can demo and have been very vague as to what kind of custom development will be needed to interface this additional software to either SAP or Vertex. Alternately, they want us to implement their ‘O’ series product – which would involve additional acquisition costs and would be a full implementation project, since there is no automated upgrade path from Q series to O series. We would need to use their consulting services to accomplish this as well.
We have not heard back yet from SAP; our Rep tells us that the matter has been referred to Germany. He has also started talking about the Business Objects Address Verification services, leading us to believe that SAP will not be forcing Vertex to close the gap in functionality.
We cannot be the only ones facing these issues and we feel quite strongly that the ‘Q’ series should not be certified by SAP and Vertex should not be marketing this product for use with SAP.
I would like to invite those of you who have experienced the same problems and would like to hear how you are handling this.