Broadleaf Microservices
  • v1.0.0-latest-prod

Avalara Tax Module

Environment Setup

Include the Broadleaf Avalara dependency in your CartOperationServices component:

<dependency>
  <groupId>com.broadleafcommerce.microservices</groupId>
  <artifactId>broadleaf-avalara-tax</artifactId>
</dependency>

Configuring Your Integration

  • broadleaf.tax.provider.avatax.environment

    • The AvaTax environment. Accepted values are "Sandbox" or "Production". Defaults to "Sandbox". Ignores case.

  • broadleaf.tax.provider.avatax.username

    • The AvaTax username.

  • broadelaf.tax.provider.avatax.password

    • The AvaTax password.

Optional Configuration

  • broadleaf.tax.provider.avatax.appName

    • The application name passed to AvaTax. Defaults to "Broadleaf Commerce"

  • broadleaf.tax.provider.avatax.appVersion

    • The application version. Defaults to "app-version-not-set"

  • broadleaf.tax.provider.avatax.machineName

    • The machine name. Defaults to "machine-name-not-set"

Register the AvalaraTaxProvider Bean & Configuration Properties Class

@Configuration
@EnableConfigurationProperties(AvaTaxProperties.class)
public static class AvalaraTaxAutoConfiguration {

    @Bean
    public TaxProvider<TaxRequest, TaxResponse> avaTaxProvider(AvaTaxProperties avaTaxProperties,
            TypeFactory typeFactory,
            ObjectMapper objectMapper) {
        return new AvalaraTaxProvider<>(avaTaxProperties, typeFactory, objectMapper);
    }
}

Configuration for Post-Checkout Tax Interactions

Tax commits, adjustments, voids, and refunds are disabled by default. To enable these interactions, see the order operations docs on post-checkout tax operations.

To enable the ability to commit, adjust, refund, and void transaction via Avalara, you must ensure that the AvalaraTaxProvider bean mentioned above is also accessible within the OrderOperationService. Depending on the organization of your flex packages, this may already be accomplished, or you may need to register the same dependency & configuration in an additional context to make it accessible to the OrderOperationService

Retail Delivery Fees

Retail Delivery Fees (RDFs) are additional charges added for retail items when they are delivered to a customer, primarily designed to fund transportation infrastructure and other state initiatives. These fees are described by Avalara as part of an items tax response, and they are distinct from standard sales taxes.

In Broadleaf’s integration with Avalara, if RDFs are enabled, we build a new line item to send to Avalara based on the expected tax code. This tax code is configurable in the case that this value were to change, but by default is set to Avalara’s expected value of "OF400000". Avalara will respond with a line item that contains any fee amounts listed as tax details, and any tax applicable to the RDF (this is often dependent on home rule jurisdiction taxes). If the line item is returned with fee amounts, then the item is mapped into a new RETAIL_DELIVERY_FEE-typed CartItem. The fee amount is set as the cart item’s unit price, and the taxes are added to the item’s tax details.

There are some additional expectations for the RDF cart items which are maintained within the Broadleaf framework:

  1. The RDF cannot be removed from the cart, except through repricing. As part of the repricing flow, Broadleaf removes any existing RDF CartItems, before calling Avalara. If RDFs are still applicable, then new RDF CartItems are produced. This process keeps the fees up-to-date as the cart and fulfillment data change.

  2. The RDF will not be included in the cart subtotal or other standard item-specific calculations. Instead, these fees will be totaled in the feeTotal on CartPricing.

  3. The RDF will not be included as a FulfillmentItem on any FulfillmentGroup. The fee lives at the cart/order level since only one RDF can be applied on the order per jurisdiction.

  4. RDF is not refundable to the state, but some companies may wish to absorb the cost of the RDF fee when they refund the customer. Broadleaf allows the ability to refund the RDF to be configurable. If enabled, the Admin portal will provide the option to refund the fee to the customer.

    1. To give CSRs the opportunity to refund RDFs as part of a return, set broadleaf.order.metadata.enable-refunds-on-retail-delivery-fees to true.

Configuring Retail Delivery Fees

  • broadleaf.tax.provider.avatax.rdf-enabled

    • Whether retail delivery fees are enabled. If this is set to true, then retail delivery fee line items will be generated with the broadleaf.tax.provider.avatax.rdf-tax-code.

    • Default is false.

  • broadleaf.tax.provider.avatax.rdf-tax-code

    • The tax code to set on generated retail delivery fee line items.

    • Default is OF400000

  • broadelaf.tax.provider.avatax.excluded-rdf-locations

    • The locations to exclude when generating retail delivery fee line items. This allows your business to declare specific states/regions where RDFs should not be collected. For example, this may be useful if you know your business will need to process Colorado RDFs, but Minnesota RDFs are not applicable to your business.

    • Default is empty

    • Example format: MN

Release Notes

2.0.2-GA

2.0.1-GA

Important Updates

Spring Boot Upgrade

Requirements

  • JDK 17 is required for Broadleaf release trains 2.0.0-GA, and beyond.

Important Updates

Spring Boot Upgrade

  • As of Broadleaf Release Train 2.1.3-GA, all microservices have been upgraded to Spring Boot 3.3

1.1.6-GA

  • Updated AvalaraTaxProvider to correctly declare TaxInfo#isVat & TaxDetail#isVat based on whether taxes are included in the item prices. Note: These fields are misnomers & this change causes the values to align with the intention of the fields.

  • Updated AvaTaxProperties#environment to use a default value of "Sandbox".