VERIFIED SOLUTION i
X

Same ZIP returning different results in Geotax

Issue

Problem: Two different tax values are received when the below APIs are call=
ed from FDT

********* In the first case when API calls calculateEquipmentTax the tax is=
 calculated using the above billing module in CSM service poGtOrdTax(server=
 rmsUOrd)

********* In the second case when API calls createEquipmentOrder the tax is=
 calculated using the above billing module in CSM service poClOrdTax(server=
 rmsUFDTOrd)

Analysis:

In both cases the same billing routine blbn_crcrg is called to get the tax =
details.According to Billing this is happening because input to quantum is =
set differently

That is why we are seeing different taxes being returned.

This difference was identified as difference in adr_incorp_ind. This value =
is set by API in the input buffer for the above services based on values re=
turned from csm service gnGtGeoCd00

Action:

Please check with Code1(Sprint side Application) why there is a difference =
between the two outputs. Even though the zipcode (81601) being sent is the =
same..

INCORPORATE_IND is expected to be Y but in one case we see it as N and in t=
he second call as Y depending on value sent to us by Code1

We see that the value is set on the basis of output received from Code1

switch (gnGcpOutRec.gcopinc)
       {
       case '0' :
         SET_C_YESNOIND_NO_INDICATOR(o_pGnAdrOutRec->incorporate_ind);
         break;

       case '1' :
         SET_C_YESNOIND_YES_INDICATOR(o_pGnAdrOutRec->incorporate_ind);
         break;
       default :

    INITIALIZE_YESNOIND_C(o_pGnAdrOutRec->incorporate_ind);
    break;
       }

Cause

This case was re-assigned to the GeoTax team as the Code1 team has determined that this issue has nothing to do with Code1.  having reviewed the Input_output document, the information there does not appear to be coming from our Geotax product as the field names and values are unfamiliar and also the API calls.
 

Resolution

UPDATED: March 27, 2017


The input ZIP+4 (81601-8529) in our GeoTax product and it correctly returns a ZIP+4 centroid match and location level for Glenwood Springs CO and Incorporated value "YES". 

The information shown makes reference to Vertex, maybe this is where the problem is.  Please verify which application/product you are using as it does not appear to be one of ours. 

Environment Details

Product Feature: General

Operating System: Not stated

Database: Not stated

Configuration: Not stated
 

Downloads

  • No Downloads