How to change default tax class on ci_item?

SOLVED

Hello, 

We are making some changes regarding taxes at our company and are wanting to change the default tax class when adding new items. Currently, when a new item is added it is assigned 'NT' (non taxable) tax class,  and we want it to default to 'TX' (taxable). 

I'm thinking there has to be a way, but I've looked through all of the maintenance and set up windows but am unable to find a setting to do this. 

Thanks!

  • +1
    verified answer

    The Tax Class comes from the Product Line selected for the Item when creating a new item. Go into Setup, Product Line Maintenance  and change it there

  • 0 in reply to BigLouie

    Thanks @biglouie!

  • 0 in reply to BigLouie

    @biglouie We set the defaults for Purchase and Sales Tax Classes on a Product Line called "NEW" then used advanced field setting to default the Product Line to "NEW" for all new items added. It appears the Business Object is setting the Product Line to New, but not reading the Product Line Setup after that to get the default Sales Tax Class settings. I tried setting the Default Tax Class in Advanced Field Setting to "TX" but there is a warning there that says the Business Object will override that and set it to "NT". Is writing a UDS to set the Default Product Line to allow the business objects to read the default settings the only way to fix this and which event should it be?

  • 0 in reply to ampelec

    It sounds like the Advanced Field Settings isn't triggering the business object in the same way it does when the value is set by the user or with the SetValue method.  What you could try is a simple UDS on either the Post-Validate of the ItemCode or the Post-Read of the CI_Item table.  If you use the later, you'll need to make sure the SecurityAccess of the business object is 2 or greater and then check if the EditState property is 2.  If all conditions are correct, you can then use SetValue on the ProductLine$ field.  The conditions on the Post-Read event will make sure you are only setting the product line on new records being read from Item Maintenance.  You can also check for the presence of the UI and then use the UI object's GetScreenName method to make sure the current library is IM_Item.M4L.  The reason for the extra checks is because if you use the Post-Read event, it can be triggered by other processes and the EditState is always a valid property and can cause a hard error.  I suppose you could always first initialize a variable to 0, then use On Error Resume Next before trying to store the EditState property into the variable, then follow it with On Error GoTo 0, then check if the variable is 2.  I prefer to avoid relying on On Error Resume Next whenever possible though.