Конкретный вопрос программирования в отношении налогов США (например, Zip + 4 или Город / Штат / и т. Д.) - PullRequest
0 голосов
/ 02 августа 2011

Я не уверен, что это правильное место, чтобы задать это, но это общий вопрос программирования, и я уверен, что многие из вас, кто разрабатывает корпоративные приложения, уже сталкивались с этим раньше. Компания, в которой я работаю, в настоящее время использует «стандартную» модель для сбора налогов на заказы: город / штат / почтовый индекс (мы могли бы включить округ).

Я посмотрел несколько сайтов, и они предлагают несколько разных налоговых пакетов, и это здорово. Тем не менее, единственное, что соответствует нашим требованиям, это Zip + 4. Нам, вероятно, нужен этот б / у, в некоторых городах Техаса будет примерно 6 налоговых «округов», некоторые из которых пересекаются. Таким образом, Zip + 4 был бы идеальным, но после просмотра данных один только Техас имеет около 300 МБ (умножение этого на 50 сделало бы запрос ужасным в нашей базе данных).

К сожалению, мы не можем использовать веб-службы для отдельных вызовов и не можем настроить базу данных SQL-сервера (или любую другую). Наша единственная система - относительно неясная база данных + среда разработки. Поэтому, если по какой-либо причине наша база данных SQL-сервера или веб-служба вышли из строя, мы не можем обрабатывать заказы.

Кто-нибудь еще сталкивался с чем-то подобным? Массивные базы данных, предназначенные только для налогов, кажутся нелепой идеей, но, к сожалению, я не могу использовать веб-сервисы.

У кого-нибудь есть идеи? Я действительно застрял на этом ...

Заранее спасибо !!!

1 Ответ

3 голосов
/ 03 августа 2011

Расчет налогов нетривиален по разным причинам. Вы уже упомянули налоговые районы. Другие причины включают в себя:

  1. Налоги для конкретного продукта. Например, Нью-Джерси раньше не облагал налогом одежду
  2. Налоговые выходные. Очень часто перед началом школы, например
  3. Отчисления, обусловленные политикой. Как отчисления для высокоэффективных приборов

Так что было бы неплохо купить пакет и интегрироваться с ним. И купите лицензию на техническое обслуживание, чтобы получать обновления метаданных ежегодно или как угодно.

Но с точки зрения программирования вы можете использовать древовидную структуру для расчета налогов. Вот как я бы это настроил.

Во-первых, определите некоторые конструкции следующим образом:

public class AddedTaxes {
  public void add(double amount, double description) { ... }
}

public interface TaxAdder extends Serializable {
  void configure(Map<String, String> settings);
  add(double preTax, AddedTaxes taxes, Object productDetails);
}

Во-вторых, соберите необходимый набор сумматоров:

public class FixedRate implements TaxAdder {
  private double _rate;
  private String _description;
  public void configure(Map<String, String> settings) {
    _rate = Double.parseDouble(settings.get("rate%")) / 100.0;
    _description = settings.get("desc");
  }
  public add(double preTax, AddedTaxes taxes, Object productDetails) {
    taxes.add(preTax * _rate, _description);
  }
}

public class FixedProductSpecific implements TaxAdder {
  private double _amount;
  private String _product;
  private String _description;
  public void configure(Map<String, String> settings) {
    _amount = Double.parseDouble(settings.get("amount"));
    _product = settings.get("product");
    _description = settings.get("desc");
  }
  public add(double preTax, AddedTaxes taxes, Object productDetails) {
    if (_product.equals(productDetails)) {
      taxes.add(_amount, _description);
    }
  }
}

В-третьих, я бы собрал налоговые правила в одном или нескольких файлах, потребляемых человеком:

// zip code range <tab> adderClassName <tab> parameters
// general texas taxes
75000.0000-79999.9999     FixedRate       rate%=8.25, desc=Sales tax
78700.0000-78999.9999     FixedProductSpecific  amount=2.00  product=LeadAcidBattery  desc=Lead acid battery sales
...

Получив эти данные, вы можете пройти этап «компиляции» для ваших данных, где вы, например, создаете дерево с 10 путями. На каждом узле (а не только листе) у меня будет список TaxAdders. В этом случае 7/5, 7/6, '7/7', ... будут иметь первый сумматор, в то время как только узлы 7/8/7, 7/8/8 и 7/8/9 будут иметь второй сумматор.

Как только вся структура собрана, сериализуйте ее. Теперь ваша компиляция завершена. Во время выполнения вы просто загрузите сериализованную структуру вычислений, и для любого заданного zip + 4 пройдитесь по дереву, чтобы найти каждый (возможно) применимый калькулятор.

Если вы не хотите поддерживать данные, вы все равно можете подвергнуться тому преобразованию, о котором я говорю, и построить «скомпилированную» вычислительную структуру.

Я могу добавить больше деталей, если хотите, но я удерживаюсь на этом, пока не узнаю, что это идет в направлении, которое вас интересует.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...