Search
Search Indirect Tax Help and Support.

Usar campos personalizados para dados de transação

Se você tiver dados de transação que não se encaixam nos elementos XML padrão do Determination, poderá usar campos personalizados que são elementos XML especiais.
Estes são elementos de entrada XML que você define para atender às necessidades de sua implementação. Cinquenta elementos separados são fornecidos nos níveis de documento e linha, embora alguns sejam reservados para uso pelo software de integração que vincula seu sistema financeiro ao Determination.
Dentre os usos comuns para campos personalizados encontram-se:
  • Envio de dados de repasse para armazenamento no banco de dados de auditoria. Por exemplo, talvez você queira armazenar dados extras de localidade, informações de contato ou comentários para uma transação não suportada pelo conjunto padrão de elementos XML.
  • Envio de dados que podem corresponder aos critérios de "uso limitado" do certificado de isenção.
  • Envio de dados que, quando avaliados pelo TransEditors, podem acionar modificações na entrada XML e nos cálculos resultantes.
  • Envio de dados que, quando avaliados pelos Qualificadores de regra, podem determinar a aplicabilidade de uma regra a uma transação.

estruturas <USER_ELEMENT>

Os campos personalizados são enviados nas seguintes estruturas de entrada XML:
<INVOICE> <USER_ELEMENT> <NAME>ATTRIBUTE[1-50]</NAME> <VALUE> </VALUE> </USER_ELEMENT> </INVOICE>
<INVOICE> <LINE> <USER_ELEMENT> <NAME>ATTRIBUTE[1-50] </NAME> <VALUE> </VALUE> </USER_ELEMENT> </LINE> </INVOICE>
Por exemplo, você pode definir o ATTRIBUTE20 no nível de linha para conter uma ID de projeto usada em sua implementação que pode ou não ser preenchida para cada transação. A presença deste campo e seu valor podem ser avaliados para acionar regras, certificados de isenção ou TransEditors. Além disso, essa avaliação pode levar em conta esse único campo personalizado ou outros, além de elementos padrão combinados.
Como mencionado anteriormente, as integrações do Determination reservam alguns dos cinquenta elementos em cada nível para seu próprio uso e não devem ser preenchidas. Em geral, os campos personalizados de 1 a 30 estão sempre disponíveis, de 31 a 39 podem estar disponíveis e de 40 a 50 nunca estão disponíveis.

Conversão automática para Qualificadores de regras e TransEditors

Os campos personalizados são definidos como strings pela implementação do Determination XML. No entanto, você pode usar esses elementos para passar números ou datas, e o sistema os avaliará corretamente em comparações de Qualificadores de regras ou TransEditor que usam os operadores <, <=, > ou >=. Por exemplo, um TransEditor pode comparar o valor ou <ATTRIBUTE25> com o valor de <INVOICE_DATE> no nível da fatura usando um dos quatro operadores. Ou um Qualificador de regra poderia compará-lo com uma constante como 2007-03-05.
A ordem das tentativas de conversão é número, data e sequência.
Conversões de números
O sistema primeiro tenta converter para um número de modo que as mãos esquerda e direita da expressão sejam números.
Por exemplo:<ATTRIBUTE25> > <ATTRIBUTE24>
<ATTRIBUTE25> contém a string "10" e <ATTRIBUTE24> contém a string "5". Ambos são convertidos em números e a expressão avalia como "verdadeiro":
10 > 5 avalia como “verdadeiro”.
Conversões de data
Se as conversões de números falharem, o Determination tentará uma comparação de datas.
Por exemplo:<ATTRIBUTE20> < <INVOICE_DATE>
<ATTRIBUTE20> contém a string "2007-03-05" e <INVOICE_DATE> é "2007-03-04". O Determination primeiro tenta converter e comparar números, que falha, depois tenta converter e comparar por datas, que é bem-sucedido:
2007-03-05 < 2007-03-04 avalia como "falso"
Conversões de strings
Se as conversões de número e data falharem em gerar uma comparação válida, o Determination tentará tratar ambos os valores como strings e provará uma comparação lexicográfica.
Por exemplo:<ATTRIBUTE15> <= aab
<ATTRIBUTE15> contém a string "aaa" e a constante avaliada é "aab". O valor "aaa" não pode ser convertido para o formato de número ou data e, portanto, é avaliado em relação à constante como uma string.
aaa <= aab avalia como “verdadeiro”