Estorno de transações
Um estorno pode ser iniciado pelo cliente, pela Thomson Reuters ou um banco emissor, e pode ser o resultado de uma transação sendo reembolsada (por exemplo, itens devolvidos em uma loja após a compra) ou qualquer outra coisa entre o comerciante e seu cliente que possa resultar em uma alteração na transação original.
Estorno de transação após um período de 2 anos
A partir de 15 de abril de 2025, o ONESOURCE Determination baseará o estorno de uma transação usando apenas os primeiros dois a partir da data da transação da fatura. Se o sistema iniciar o estorno de uma transação dentro desse prazo, ele o processará de acordo com a lógica deste procedimento. No entanto, se alguém tentar estornar uma transação após o período de 2 anos, o Determination não estornará a transação anterior.
Visão geral do estorno de transações
Para seguir o processo de sistemas de entrada dupla onde as transações são registradas como débitos ou créditos, em um cenário ideal, a exclusão de transações precisa ser tratada com estornos da transação original em vez de exclusão. Nesse sentido, as transações ou faturas processadas pelos sistemas (Enterprise Determination Cloud e Determination Anywhere (DA)) nunca são excluídas. Portanto, para que uma transação seja estornada, uma nota de crédito correspondente a uma fatura existente deve ser criada.
Os atributos a seguir devem ser obrigatoriamente incluídos na solicitação do sistema transacional do cliente (sistema de origem) para o mecanismo fiscal ONESOURCE Determination a fim de calcular as taxas:
Elementos obrigatórios (JSON / XML) | Descrição |
|---|---|
callingSystemNumber / calling_system_number | Um descritor do sistema de chamadas (origem) que está enviando a transação. |
companyName / external_company_id | O identificador usado pelas empresas ao chamar o Determination. Este elemento informa ao Determination qual empresa está chamando, permitindo que ele use as configurações específicas corretas da empresa. |
companyRole / merchant_role | O papel que a empresa desempenha em cada transação: B para Comprador, M para Mediador, S para Vendedor. |
documentNumber / invoice_number | Este número é passado para as tabelas de auditoria e atua como referência nas tabelas de auditoria, bem como para transações de crédito. |
externalCompanyId / external_company_id | O identificador exclusivo usado pelo aplicativo de negócios para indicar qual empresa usar no Determination. |
hostSystem / host_system | O nome da instância ERP que está enviando a transação. |
documentDate / invoice_date | A data da fatura ou documento. |
uniqueDocumentNumber / unique_invoice_number | O identificador exclusivo da fatura, conforme atribuído pelo sistema ERP ou gerado pelo ONESOURCE Indirect Tax Determination. Para o processo de estorno não relacionado, o valor aqui não pode corresponder a um valor existente no banco de dados de auditoria. |
MerchantId / Merchant_ID | O UID do locatário raiz. O identificador exclusivo para indicar qual empresa usar no Determination. |
Os seguintes atributos determinam a exclusividade de uma fatura de transação no banco de dados de auditoria:
- HostSystem / Host_System
- CallingSystemNumber / Calling_System_number
- uniqueInvoiceNumber / Unique_Invoice_Number – Em um caso em que essas informações não estão presentes na solicitação de transação, então {ExternalCompanyID|Invoice_Number|Company_Role} é usado para criar um número de fatura exclusivo no sistema do Determination.
- MerchantId / Merchant_ID
Esses quatro atributos são citados como Chave única nas informações a seguir.
Estorno de transações
O processo de estorno no sistema implica a negação da transação original armazenada no banco de dados de auditoria e a criação subsequente de um novo registro que corresponda à última solicitação. Os estornos podem ser diferenciados como Estornos não relacionados, Inversões implícitas e Inversões explícitas.
Estornos não relacionados – Esta é a melhor prática recomendada para estornar uma transação. Se o sistema de origem criar um documento de estorno/cancelamento ou um registro com um número de documento separado, o valor poderá ser passado como negativo. Nesse caso, o sistema não realizará um estorno e ambas as transações serão declaradas de forma independente na auditoria com determinados atributos (Número da fatura original) que podem ser usados para ver seu relacionamento.
Recomenda-se consultar a transação original para este processo:
Elementos opcionais | Descrição |
|---|---|
originalDocumentId | A ID do documento original, conforme mostrado no documento no sistema de origem. Não usado em cálculos. |
originalDocumentDate | A data da transação original. Usado nas regras de determinação de datas. |
originalDocumentNumber | Este número permite que uma fatura de crédito seja associada a uma fatura original nas tabelas de auditoria para fins de relatório. |
Estorno implícito – Esse processo segue a suposição de que o sistema de origem passará pelos atributos Chave exclusiva que permitem que os dados sejam combinados com um registro existente e pode ajudar com estornos parciais se esse for o objetivo do sistema de transação.
Se os atributos Chave exclusiva enviados para o Determination existirem anteriormente na auditoria, o Determination mantém o registro original (digamos, US$ 100,00), cria um estorno desse documento e, em seguida, um novo registro desse documento representando as informações mais recentes do documento aprovadas (digamos, a nova transação é de US$ 25,00). Haverá três registros na auditoria:
- Documento original 1234, linha 1 = US$ 100,00
- Documento de estorno no Determination 1234, linha 1 = -US$ 100,00
- Documento de estorno reenviado 1234, linha 1 = US$ 25,00
Como alternativa, se uma transação for enviada com atributos de Chave exclusiva correspondentes e um valor negativo, haverá três registros na auditoria:
- Documento original 1234, linha 1 = US$ 100,00
- Documento de estorno no Determination 1234, linha 1 = -US$ 100,00
- Reenviado documento de estorno 1234, linha 1 = US$ 100,00
Estorno explícito – Este processo segue a suposição de que o sistema de origem deseja fazer um estorno completo ou anular totalmente a transação original.
O Determination mantém o registro original (digamos, US$ 100,00) e cria um novo registro desse documento representando as informações mais recentes do documento aprovadas. Haverá dois registros na auditoria:
- Documento original 1234, linha 1 = US$ 100,00
- Documento de estorno reenviado 1234, linha 1 = US$ 100,00
Para Estornos explícitos, toda a carga útil para a solicitação ao mecanismo fiscal não é necessária, e apenas os elementos básicos são requeridos para fazer o estorno.
- Para solicitações de transação que utilizam Rest, um ponto final separado precisa ser alcançado. A documentação da API está disponível no Portal do desenvolvedor.
- Para solicitações de transação utilizando SOAP, o sinalizador IS_REVERSED deve ser definido como VERDADEIRO. <IS_REVERSED>true</IS_REVERSED>.
Os diagramas a seguir fornecem a transferência de alto nível do processo de estorno para aplicativos Enterprise Cloud e Determination Anywhere nas plataformas OCI e AWS onde o banco de dados de auditoria reside. A AWS é a plataforma em nuvem de serviços da web da Amazon. O OCI é a infraestrutura de nuvem da Oracle. O aplicativo Enterprise Cloud Determination está hospedado em ambas as plataformas de nuvem, com componentes do lado do servidor DA hospedados lá para clientes do DA.
Visualização de sequência de processo
Deve-se entender que o próprio mecanismo tributário, seja Enterprise Cloud ou DA, não realiza nenhuma atividade de estorno. Em vez disso, uma confirmação será devolvida para a solicitação imediatamente; o estorno é confirmado de forma assíncrona/off-line para o banco de dados de auditoria. Os clientes podem validar os registros transacionais nos relatórios (NGRA). Isso se aplica às solicitações de serviço da web SOAP e Rest na AWS Enterprise Cloud e DA, exceto no caso da OCI. Há um processo ETL que instala os dados do banco de dados de auditoria ao NGRA para fins de relatório.
Com estornos pelo Enterprise Cloud Determination na plataforma OCI, quando o sistema de origem recebe uma confirmação de uma transação processada, isso implica que o estorno aconteceu ao mesmo tempo, ou seja, o compromisso real ocorreu no banco de dados de auditoria.
Portanto, no caso de um estorno explícito, você pode esperar a seguinte resposta do mecanismo fiscal se uma fatura correspondente não existir, subsequentemente, a transação de estorno não será registrada no banco de dados:
Com estornos pelo Enterprise Cloud Determination na plataforma AWS, o sistema de origem receberá uma confirmação de que a transação é processada, mas a atividade de estorno ocorre fora do mecanismo fiscal ou off-line do processo de cálculo fiscal.
Assim, no caso de um estorno explícito, se um registro existe ou não, e se uma atividade de estorno ocorreu ou não posteriormente no processo, o mecanismo tributário responderá como:
A transação que foi enviada como estorno tentará corresponder à fatura existente. O processo tentará algumas vezes encontrar a fatura correspondente no banco de dados de auditoria; se no final ainda não puder, o registro será inserido no banco de dados de auditoria. Tais registros poderiam ser identificados a partir de relatórios (NGRA) da seguinte forma:
- O usuário pode criar um relatório personalizado, adicionar a coluna Estorno ao modelo e obter um conjunto de dados filtrado selecionando Reversão = “Y”.
- Além disso, o usuário pode usar o relatório padrão chamado Detalhes do documento dos EUA e obter um conjunto de dados filtrado selecionando a coluna Estorno como "Sim".
Com estornos pelo DA nas plataformas AWS ou OCI, o sistema de origem receberá uma confirmação de que a transação é processada, mas a atividade de estorno ocorre fora do mecanismo fiscal ou off-line do processo de cálculo fiscal.
No caso de um estorno explícito, se um registro existe ou não, e se uma atividade de estorno ocorreu ou não posteriormente no processo, o mecanismo tributário responderá como:
A transação que foi enviada como estorno tentará corresponder à fatura existente. Se nenhuma correspondência for encontrada, ela permanecerá em uma fila com falha e terá que ser consultada manualmente como um processo operacional, pois não será inserida no banco de dados de auditoria.
O cliente do DA não mantém um registro de transações históricas, pois as transações processadas são descarregadas dele para o banco de dados de auditoria o mais rápido possível.
Em todos os casos anteriores, para um processo de Estorno implícito, a resposta da mensagem de sucesso observada anteriormente é retornada quando a solicitação de cálculo de imposto foi processado sem erros pelo mecanismo tributário.