Greetings. I’m working on modifying a process stream that imports sales orders and places them as open sales orders along with manually created sales orders in xTuple 5.0. All manual orders and imported orders flow into the same stream and are fulfilled within the standard xTuple order handling processes.
I’ve been using this process for a number of years to seamlessly process orders created on a drupal commerce website and use the same function to process orders entered on the Amazon shopping site and collected using the Amazon api. A simple cron job is used to process both of those streams of orders and once they get into xTuple they are good to go.
My need to modify the process is triggered by the adoption of the Avalara tax integration now available within the xTuple client. This is not an issue with the Amazon orders as Amazon assumes responsibility to collect the sales tax there. However within the Drupal site we are using the Avalara APIs to provide a total with tax calculated by Avalara to ensure the credit card gateway collects the appropriate amount. Again, this is a simple task and we have access to all the data.
My question regards the actual import functions for the Drupal orders. We have been using the two xtuple “views” named api.salesorder and api.salesline to process the incoming records. However it looks like these two views do NOT touch either the taxhead or taxline tables. Whereas a manual order does create tax info for a sales order.
I was just wondering what is the “Best Practice” for importing a sales order with tax info for the line items? Does the standard xTuple code use a trigger to produce the taxhead and taxline tables or should I do it manually? I was also wondering what role the taxdetail records play. If there is any publicly available info on the current flow of tax info within the xtuple system id go there for my answers. Thanks.
Jim Wirt