EMBarbosa

Olá, o problema é que na geração do S-2206 esse campo é Ocorrência 1 (layout Simplificado). Veja: Assim, se formos alterar, precisamos tratar os dois casos.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 23469. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

@alexcamilo01 @IMATECH Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 23468. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 23466. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 23465. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

@Sandro Felipe Adad, @Alisson Souza Pereira e @Jeihcio Francis, Subi as alterações do Alisson para o SVN na Revisão 23464 . Acho que isso resolve o problema. Queiram por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

A tag correta seria "infocomplem"

Bom dia. Você escreveu que o erro está no nrInsc, mas a mensagem de erro que colou é que deveria ter um elemento "evento" dentro do elemento "eventos". Poderia detalhar melhor o problema? Tem mais alguma mensagem de erro? Em qual versão do leiaute foi gerado esse xml? Como foi gerado esse xml?

O instalador do Fortes report não tem separação dos pacotes desingtime e runtime. Por isso não se consegue compilar esses pacotes para outras plataformas que não sejam win32. Mas é como você disse, isso é nos pacotes do Fortes e não do ACBr. Vamos avaliar suas sugestões, obrigado.

Poderia anexar o arquivo alterado por favor?

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 23251. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Que bom. Como eu não tenho uma balança dessas para testes, por favor, me dê um retorno depois dos seus testes.

Olá Luciano, Avaliando seu código aqui... Notei que o arquivo teve o layout totalmente alterado. Além disso, ele está desatualizado. Queira por favor sempre atualizar antes de enviar e manter o mesmo layout do arquivo original. Isso facilita pra gente poder analisar. O que eu percebi no entanto é que você está utilizando um modelo para enviar diretamente para a balança. Então teria que ser o modelo modUrano ou o modUranoS. O modelo modUranoURF32 é apenas para quem utiliza o software URF32 para balanças Urano. Você pode notar que nesse tipo de arquivo, não vai caracteres de controle logo no início como está descrito na documentação que você anexou. Além disso, pode notar que que esses outros dois modelos já citados já não colocam separadores de milhares nos valores. A menos que tenha entendido algo errado, e nesse caso peço que me esclareça onde errei, não podemos enviar essa alteração, pois ela pode quebrar o funcionamento de quem utiliza o URF32...

Olá pessoal, Recebemos nas últimas semanas muitos relatos sobre problemas com emissão de NF-e ou NFC-e aparecendo uma das seguintes mensagens: "815-Rejeição: Erro não catalogado (código de status não localizado: 815)" "816-Rejeição: Erro não catalogado (código de status não localizado: 816)" Outra possibilidade são essas mensagens aparecerem como deveriam que é: 815 - Rejeição: Valor do ICMS Interestadual para UF de Destino difere do calculado [nItem: 999] (Valor Informado: XXX, Valor Calculado:XXX) 816 - Rejeição: Valor do ICMS Interestadual para UF do Remetente difere do calculado [nItem: 999] (Valor Informado: XXX, Valor Calculado:XXX) Queremos explicar o motivo dessa rejeição e como você pode fazer sua nota de um jeito aceitável. Vamos por partes.... O que sabemos sobre o problema? Não conseguimos ainda retorno de todas as SEF onde ocorreu a mensagem estar como erro não catalogado sobre o motivo de estar assim... Mas provavelmente é alguma atualização que foi feita de forma incompleta nos servidores da SEFAZ. (EDIT: Você pode ver nesse mesmo tópico nos posts seguintes, logo abaixo, os retornos que tivemos). Mas sabemos que a rejeição é porque os valores para o ICMS interestadual não estão batendo com o que a UF espera. Realmente, os cálculos mudaram com a NT 2020.005, mas teoricamente essas regras deveriam ter entrado em vigor em 01/09/2021 e não agora. Se você estiver recebendo a mensagem completa com o "valor informado" e o "valor calculado", fica mais fácil você avaliar as opções e saber o que o webservice está esperando. O detalhe é que pelos relatos que estamos recebendo, as UFs estão calculando de maneira diferente. Elas calculam diferentes dependendo do ambiente que você está (homologação ou produção), diferentes uma das outras (como é o caso de MG e BA), diferentes dependendo da situação (como está na NT 2020.005), mas também até diferente da forma que está na Nota técnica. Para piorar, se você não recebe a mensagem completa, não dá para saber qual o valor que a SEFAZ esperaria no seu caso. Ainda não recebemos confirmação sobre se isso vai ser alterado logo... mas manteremos todos informados (EDIT: Atualizações podem estar nesse mesmo tópico, em posts abaixo). O que causa a rejeição? Como dito, essa rejeição é causada porque o cálculo dos valores estão diferentes do esperado. Esses cálculos estão definidos na NT 2020/005, cuja última versão é a 1.20. Como essa NT foi atualizada esse ano, parece que o MOC ainda não consta as alterações. O melhor é verificar essa NT e o MOC. Essas são as rejeições conforme a NT, veja: Então em teoria seria apenas seguir esses cálculos que o seu problema seria resolvido. Continuo com problema... Como resolver? Em primeiro lugar queremos deixar bem claro que não somos uma consultoria contábil e que ainda estamos levantando mais informações. O objetivo desse tópico é ajudar a todos por dar alguma explicação e direção, de modo que ninguém fique perdido e possa consultar o contador dos clientes entendendo o problema. Isso evita perda de tempo e mal entendidos. Então lembre-se de consultar o contador de confiança e/ou o contador do cliente ao definir os cálculos de impostos. IMPORTANTE: Os valores para os cálculos podem depender da UF de origem e da UF de destino (por exemplo sudeste para nordeste, SP para BA, etc...). Essa informação é muito importante porque você pode receber rejeição para uma UF de destino, mas não para outras... Nesse caso, reveja a sistemática do cálculo nesse outro artigo aqui. Dito isso: Está havendo uma inconsistência nos relatos que temos recebido (como foi dito acima), assim, vamos passar o que alguns tem feito para resolver os problemas. 1) Rever a fórmula do cálculo. As fórmulas mudaram com as novas versões da NT 2020.005. Então a possibilidade de seu software estar fazendo o cálculo de forma desatualizada é real. As fórmulas novas são: vICMSUFDest = ((vBCUFDest * pICMSUFDest) - (vBC * pICMSInter)) * pICMSInterPart (explicação nesse link) vICMSUFRemet = ((vBCUFDest * pICMSUFDest) - (vBC * pICMSInter)) – vICMSUFDest (explicação nesse link) Essa é a melhor opção. Se isso funcionar significa que foi apenas uma atualização normal e já esperada... IMPORTANTE: A NT 2020.005 explica que benefícios fiscais no destino devem ser incluídos no valor da base de cálculo (vBCUFDest) Consulte o contador do seu cliente sobre quais produtos podem cair nessa situação, de forma a incluir esses valores no cálculo. Isso pode afetar o imposto que seu cliente paga. 2) Use as fórmulas antigas Parece que alguns webservices não foram atualizados e ainda estão usando as fórmulas antigas. Nesse caso, as fórmulas antigas são: vICMSUFDest = vBCUFDest * (pICMSUFDest - pICMSInter) * pICMSInterPart vICMSUFRemet = (vBCUFDest * (pICMSUFDest - pICMSInter)) – vICMSUFDest Note que eu não destaquei essas fórmulas, porque elas estão desatualizadas. Assim, se algum webservice estiver calculando desta maneira logo vai ter uma atualização e vai parar de aceitar esse cálculo novamente... (pelo menos em teoria...) Se testar essa opção e ela funcionar, sugerimos entrar em contato com a SEFAZ para esclarecer o motivo deles não terem atualizado ainda. 3) Zere os valores das tags do grupo ICMSUFDest deixando apenas os valores pICMSInter e pICMSInterPart preenchidos (veja também o ponto 5) Essa é uma opção que parece funcionar e recebemos relatos por meio do nosso discord por meio de um usuário ACBr PRO. Parece que pra consumidores que não são contribuintes do ICMS e são pessoa física, essa seria a única solução em alguns casos. Mas, não temos como dizer se está correta ou não. Consulte seu contador. Exemplo de como ficaria no XML nesse caso: -<ICMSUFDest> <vBCUFDest>0.00</vBCUFDest> <vBCFCPUFDest>0.00</vBCFCPUFDest> <pFCPUFDest>0.0000</pFCPUFDest> <pICMSUFDest>18.0000</pICMSUFDest> <pICMSInter>7.00</pICMSInter> <pICMSInterPart>100.0000</pICMSInterPart> <vFCPUFDest>0.00</vFCPUFDest> <vICMSUFDest>0.00</vICMSUFDest> <vICMSUFRemet>0.00</vICMSUFRemet> </ICMSUFDest> 4) A operação não envolve ICMS interestadual Verifique se a operação realmente envolve o cálculo de DIFAL. Por exemplo, se o consumidor é final e faz a compra presencial, mesmo que ele seja de outro estado, não houve operação interestadual. 5) A empresa é Simples Nacional e não deveria recolher o ICMS Interestadual (veja também ponto 3) Alguns usuários reportaram que o Supremo Tribunal Federal suspendeu a aplicação das novas regras de partilha do ICMS nas operações e prestações interestaduais destinadas a consumidor final não contribuinte do imposto, quando realizadas por optantes pelo Simples Nacional, por meio da Ação Direta de Inconstitucionalidade (ADI) 5.464/2016. Isso pode estar sendo levado em conta e por isso a rejeição em alguns casos. Outras informações importantes Os cálculos para ICMS interestadual (DIFAL) no momento são um pouco complicados mesmo. Em especial porque existem maneiras diferentes de calcular. Mas é possível entender com um pouco de paciência. Existem o chamado cálculo DIFAL por fora (ou cálculo com base única) e cálculo DIFAL por dentro (ou cálculo com base dupla). Encontrei esse link sobre o assunto e parece bem completo... Se você ver no link, esse cálculo muda de acordo com as UFs. Algumas UFs tem em sua legislação estadual alguma orientação sobre o assunto (como por exemplo essa de MG). Por outro lado, essas orientações talvez precisem ser adaptadas, incluindo um valor a mais ou a menos na base de cálculo por exemplo... Talvez uma consulta ao Fale conosco de sua SEFAZ ajude a resolver a dúvida. Temos certeza que essas informações são úteis, mas nos comprometemos a assim que tivermos mais informações voltar com novidades para todos. Mais uma vez queremos aproveitar a oportunidade para agradecer a todos os nossos usuários PRO pelo apoio que nos permite buscar mais informações. E queremos agradecer a todos que participam ativamente do Projeto ACBr no fórum e Discord. Bom trabalho pessoal.

Boa tarde. Muito obrigado pela contribuição. Estou avaliando aqui. Eu notei que já tem um tratamento assim algumas linhas acima, mas pensando bem, não me parece correto. Eu digo, não me parece correto fazer esse tipo de tratamento na classe de geração do XML. Isso parece mais uma regra de negócios do que da geração do XML. O que você acha? Será que conseguiríamos achar uma outra forma de evitar a tag ser gerada sem que tivéssemos que adicionar um if tão específico?

O tópico que você citou responde, veja: E aqui também:

MODERAÇÃO: Tópico Dividido de: https://www.projetoacbr.com.br/forum/topic/63544-evento-s-1005-o-fap-do-estabelecimento-não-foi-localizado-na-base/

Boa tarde. Me parece que as alterações já estão no SVN. Se não estiverem, teria como você postar uma versão atualizada das suas modificações?

Eu não sei se o Fortes foi preparado para trabalhar em aplicação console. Ele geralmente precisa conseguir detectar uma impressora padrão. Talvez esteja relacionado a isso.

Mas o arquivo não deve se chamar SIARE. Esse arquivo deve ter um nome específico. Você precisa verificar o objetivo do arquivo, as especificações e o nome. Senão, vai ser difícil ajudar.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 23068. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Bom dia... Sim, a solução está em outro ponto. Se você quer que seja levantado uma exception, basta você alterar a propriedade "RaiseExcept" do componente para "True".

Na verdade, você precisa verificar como vai ser enviado. E aí, geralmente depende do contrato com os correios. Se você for enviar pacotes separados, precisa olhar um por um mesmo. Se você for juntar numa caixa grande, então precisa passar os valores de tamanho da caixa grande somando o peso dos produtos. Por fim, se você tem dúvidas, então o melhor é verificar: Como o usuário faria na mão? Quais as orientações dos correios para o envio?

Verifique essa postagem por favor: Embora esteja falando do DANFe, a ideia é a mesma para a impressão de boletos do Fortes.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 23056. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.