Using Sage Sales Tax X-REF to Zip Code during VI of Sales Orders

SUGGESTED

A customer is just setting up sales tax schedules by zip code. They are aware of the various third-party solutions and have made a business decision to use the included Sage functionality.

They are using VI to import sales orders.

They say that the sales tax schedule is NOT changing to the proper schedule based on zip code.

One reason for that - I think - is that the zip code/x-ref for sales tax seems to ignore changing tax schedule for an order if the order is already assigned NONTAX.

So I recommended that they fix that issue and assign an appropriate tax schedule to the customer master that isn't NONTAX

The concern I have now is that I ran across a KB somewhere stating that when you use VI --- if it runs into a prompt ( as I see when manually changing a zip code in a test SO ) then it accepts the DEFAULT ( which in the case of "Do you want to change the sales tax schedule" appear to be NO).

Has anyone run across this with VI? More specifically, can a VI import be used to auto-assign the sales tax schedule based on zip code without any additional scripting? 

The reason that the zip code may change for the customer number from order to order is that they are processing orders from a third-party marketplace. Rather than create a new customer for each order ( when that customer likely will only order once ) they use one customer number and just change the ship to.

TIA

  • 0
    SUGGESTED

    You could either use a post validate event script on the post validate of the customer number or perform logic on the after assign of the customer number. 

    If you use the post validate event script, you can use oBusObj.SetValueNoValidate "TaxSchedule$", "" to blank out the tax schedule that was sourced from the customer record.  This would probably need to be filtered to specific customers, start program, and/or other criteria so it doesn't do this during normal data entry.

    If you use the after assign perform logic, you can use coBusiness'SetPartialRecord("", CPL("IOLIST TaxSchedule$") to blank out the tax schedule that was sourced from the customer record.  This would only occur when importing using the import job so no need to filter it like you would have to with the post validate event script.

    Either approach makes it so when you set the ship to zip code, which should occur after the above executes, it won't expect to prompt to change the tax schedule because the current tax schedule will be blank.