Esempi fiscale motore

Question

Creiamo punto vendita di software per il Mac, e stanno cercando di rinnovare il nostro motore di imposta. E 'piuttosto semplice ora, con le tasse che consistono di un nome, codice e tasso che può essere applicato a tutti i prodotti singolarmente. Anche se questo è sufficiente per alcune persone buone, abbiamo avuto un sacco di richieste per gestire le situazioni più avanzate. Alcuni esempi sono IVA US Città / Provincia di vendita, composte canadese (impilate) le tasse, ecotassa francese e tassa di lusso di New York.

Abbiamo identificato la maggior parte delle caratteristiche che queste tasse hanno e sono sporgendosi verso una sorta di implementazione basato sulle regole del motore. Non abbiamo per sostenere tutti i casi non mancano, ma noi vogliamo essere in grado di estendere, se necessario (per evitare un'altra riscrittura).

Siamo alla ricerca di consigli da parte di persone che hanno costruito qualcosa di simile prima, o esempi di progetti che cercano di risolvere lo stesso in modo elegante.

Answer 1

mi sento di raccomandare una serie di tabelle di database e si unisce.

Esempio:

• Giurisdizione :. Lista degli stati, contee, paesi, città, ecc
• prodotto : ovvio
• Conservare : elenco delle località che si vendono da
• StoreJurisdiction (StoreID, JurisdictionID): l'elenco delle giurisdizioni del negozio è responsabile di raccogliere le tasse per
• ProductTaxCode (ProductID int, TaxCodeID int): il tipo di prodotto ai fini delle imposte:. Di base, di lusso, ecc
• JurisdictionTaxCodeRate (JurisdictionID, TaxCodeID, InterestRate, RateType): per ogni combinazione del caso di Giurisdizione e Codice Fiscale, fornire l'aliquota da applicare, e il tipo di tasso (composto, semplice, ecc .).

Per trovare l'elenco delle tasse da applicare, tutto ciò che serve è un INNER JOIN del negozio, le sue giurisdizioni, le jurisdictiontaxcoderates per Giurisdizioni, e codici fiscali del prodotto.

Si potrebbe definire come un ProductTaxCode Visualizza in modo che tutti i prodotti ricevono un TaxCode di default a meno che non è previsto uno speciale. Astraendo TaxCode, si può avere gli stessi metadati su un prodotto ( "Food", per esempio) si applicano alle diverse regioni in modi diversi. Se una particolare giurisdizione ha la propria definizione di "cibo", basta aggiungere un codice specifico per la competenza e la applicherà ai prodotti a seconda delle necessità.

Questo potrebbe richiedere qualche ritocco per gli acquisti su Internet, gli acquisti all'ingrosso, e altre situazioni in cui la vendita è in qualche modo esente da tasse o il cliente è responsabile per i loro remittente. Sarebbe anche bisogno di tweaking per situazioni in cui la sede del cliente, piuttosto che il negozio, decide l'aliquota fiscale.

Altre modifiche: qui in Texas, per esempio, abbiamo un week-end "tax-free", in cui tasse statali e locali non sono raccolti su alcuni classi di prodotti in cui il prezzo di vendita del singolo elemento è meno di $ 100. L'idea è quella di fornire materiale scolastico meno costosi, abbigliamento, ecc per i bambini di andare a scuola per un nuovo anno. Questo tipo di ritocco potrebbe essere implementato da avere un tavolo intervallo di date per ogni JurisdictionTaxCodeRate andare fuori in futuro nella misura in cui possono essere pianificate.

Answer 2

Il mio suggerimento sarebbe quello di utilizzare le tabelle del database per quello che sono buoni per (la memorizzazione di valori) e le regole per quello che sono buoni per (logica di business). Non avrei certamente messo le cose come i tassi o le liste di giurisdizioni nelle regole fiscali - chi dovrebbe essere in tabelle. Quello che vorrei usare un motore di regole per definire è la logica che determina quale aliquota da applicare al cui le transazioni. Così, per esempio, se compro un set di prodotti online da una società con sede nello Stato X che le navi da State Y a tre luoghi diversi, quello fiscale tariffe si applicano a quali parti della transazione? Questa combinazione di regole e tabelle di database è molto comune - le regole assicurarsi che si guarda le cose giuste, mentre l'aiuto tabelle nel riportare ecc Per esempio, la California DMV ha fatto questo con le tasse di immatricolazione dei veicoli - tutte le varie tasse sono memorizzati in un database, mentre le regole che determinano quali tassa si applica a quale auto siano gestiti in base di regole. Se si tenta di mettere tutto in regole non sarà in grado di riferire bene e se si cerca di mettere tutto in tabelle di database si finirà con decine di tavoli per gestire tutte le eccezioni e casi d'angolo. JT

Answer 3

Ecco un esempio di una città "regola casa" in Denver, CO area metropolitana:

http://www.c3gov.com/pages/about/division_salestax.html

, come rivenditore, potrebbe anche essere necessario inviare i pagamenti fiscali in diverse posizioni. Per le città che non sono città "Home Rule" (che è un termine speciale che probabilmente si applica solo a Colorado, ma poi probabilmente ogni stato ha qualche termine altrettanto speciale come it), potrai inviare tutti i pagamenti fiscali per lo stato chi lo farà poi di affrontare fuori alle parti interessate. Colorado ha una caratteristica in cui ci sono "i distretti fiscali speciali" che sono autorizzati a riscuotere le tasse di vendita per alcune prestazioni (sul link esempio, RTD è il quartiere di trasporto pubblico, e "Invesco Field" è lo stadio in cui i Denver Broncos giocare).

Per espandere su risposta del sig Tallent su questo thread, è necessario includere anche nella tabella Giurisdizione qualche modo di rappresentare che le tasse possono andare in posti diversi.