Italo Giurizzato Junior

Olá pessoal, Foi publicado a NT 2024/002 que trata sobre o CT-e Simplificado. O que vem a ser o CT-e Simplificado: O CT-e Simplificado poderá ser utilizado nas prestações de serviços de transporte intermunicipal ou interestadual de mercadorias, que envolvam diversos remetentes ou destinatários, e um único tomador de serviço. O transportador poderá emitir um único CT-e referente a todas as prestações realizadas para este tomador, por veículo e por viagem. A forma de processamento do serviço de recepção é síncrona sem a formação de lotes. O contribuinte deve transmitir o CT-e simplificado através do Web Service de recepção exclusivo que atenderá esse leiaute e receberá o resultado do processamento na mesma conexão. O Layout do XML do CT-e Simplificado é bem diferente do CT-e (modelo 57) que estamos acostumados a ver. Sendo assim não da para expor nesse tópico os novos campos ou campos com novos valores, pois trata-se de uma estrutura de XML totalmente nova para o CT-e Simplificado.. Sobre os Prazos A previsão para implementação no ambiente de homologação é para o dia 02/09/2024 e produção para 07/10/2024. Mudanças no ACBr e/ou na Sua Aplicação A alteração no componente vai ser realizada em Julho e Agosto para que fique tudo pronto para a data prevista de implementação em ambiente de homologação. Dica de sempre, mantenham todos os fontes de todas as pastas atualizados, já se encontra no SVN a atualização dos Schemas que contempla o CT-e Simplificado

Boa tarde @Fabricio Fries, Você usa o componente ou a Lib (DLL)? Esse tópico trata do uso da Lib e não do componente.

Olá Pessoal, Foi publicado hoje (12/04/2024) a NT 2024/001 que trata sobre o CRT para quem é MEI (Micro Empreendedor Individual) e o fim da Denegação. Alterações relacionadas ao MEI 1. O campo CRT do grupo Emitente agora vai poder conter o valor 4 que indica que se trata de um MEi. 2. Abaixo temos uma lista de CFOP que o MEI (CRT=4) deverá utilizar nas operações internas e interestaduais: • 1.202 - Devolução de venda de mercadoria adquirida ou recebida de terceiros, ou qualquer devolução de mercadoria efetuada pelo MEI com exceção das classificadas nos códigos 1.503, 1.504, 1.505 e 1.506. • 5.102 - Venda de mercadoria adquirida ou recebida de terceiros, ou qualquer venda de mercadoria efetuada pelo MEI com exceção das saídas classificadas nos códigos 5.501, 5.502, 5.504 e 5.505. • 1.904 - Retorno de remessa para venda fora do estabelecimento, ou qualquer entrada e retorno de remessa efetuada pelo MEI com exceção dos classificados nos códigos 1.202, 1.503, 1.504, 1.505 e 1.506. • 2.202 - Devolução de venda de mercadoria adquirida ou recebida de terceiros, ou qualquer devolução de mercadoria efetuada pelo MEI com exceção das classificadas nos códigos 2.503, 2.504, 2.505 e 2.506. • 2.904 - Retorno de remessa para venda fora do estabelecimento, ou qualquer entrada e retorno de remessa efetuada pelo MEI com exceção dos classificados nos códigos 2.202, 2.503, 2.504, 2.505 e 2.506. • 5.102 - Venda de mercadoria adquirida ou recebida de terceiros, ou qualquer venda de mercadoria efetuada pelo MEI com exceção das saídas classificadas nos códigos 5.501, 5.502, 5.504 e 5.505. • 5.202 - Devolução de compra para comercialização, ou qualquer devolução de mercadorias efetuada pelo MEI com exceção das classificadas no código 5.503. • 5.904 - Remessa para venda fora do estabelecimento, ou qualquer remessa efetuada pelo MEI com exceção das classificadas nos códigos 5.502 e 5.505. • 6.102 - Venda de mercadoria adquirida ou recebida de terceiros, ou qualquer venda de mercadoria efetuada pelo MEI com exceção das saídas classificadas nos códigos 6.501, 6.502, 6.504 e 6.505. • 6.202 - Devolução de compra para comercialização, ou qualquer devolução de mercadoria efetuada pelo MEI com exceção das classificadas no código 6.503. • 6.904 - Remessa para venda fora do estabelecimento, ou qualquer remessa efetuada pelo MEI com exceção das classificadas nos códigos 6.502 e 6.505. Quando se tratar de operações de comércio exterior, ativo imobilizado e ISSQN, o MEI que informar CRT=4 poderá utilizar os seguintes CFOP: 1501, 1503, 1504, 1505, 1506, 1553, 2501, 2503, 2504, 2505, 2506, 2553, 5501, 5502, 5504, 5505, 5551, 5933, 6501, 6502, 6504, 6505, 6551 e 6933. Sobre o Fim da Denegação 3. Nessa mesma NT trata sobre a eliminação do processo de denegação na NF-e (modelo 55) que vai passar a ser apenas um processo de rejeição conforme ajuste SINIEF 43/2023. Antes quando o Emitente possuía alguma situação irregular perante ao Fisco a nota era Denegada, agora ela vai passar a ser rejeitada através da Rejeição 781 com a seguinte mensagem: Emissor não habilitado para emissão da NF-e/NFC-e. Mudanças nas Regras de Validação 4. Por fim a NT também traz as alterações e exclusões de algumas Regras de Validação: Alteração nas Regras de Validação I03-30 e I12-60 Alteradas as regras I03-30 e I12-60 para tornar o GTIN e o GTIN da unidade tributável facultativos quando o CRT for igual a “4=Simples Nacional – Microempreendedor Individual – MEI”. Alteração na Regra de Validação I05-10 Alterada a regra I05-10 para não exigir o NCM completo para CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI” em operações internas. Portanto, quando o emitente da NF-e for MEI e a operação for interna poderá informar NCM 00000000. Porém, em operações interestaduais e de comércio exterior é necessário informar o NCM correto e completo. Alteração das Regras de Validação N12-20 e N12a-10 Alterada as regras N12-20 e N12a-10 para exigir o preenchimento correto do CSOSN quando CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI”, e não permitir CST para este CRT. Alteração da Regra de Validação NA01-20 Alterada a regra NA01-20 para não exigir o grupo de ICMS para a UF de destino quando CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI”. Alteração da Regra de Validação 7C21-10 Alterada a regra 7C21-10 para verificar se CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI” é realmente utilizado por contribuinte enquadrado como MEI. Alteração das Regras de Validação N12a-40, N12a-44, N12-40 e N12-44 Alteradas as regras para incluir o CFOP - Inclusão de utilização na NFC-e do CFOP 5910 - Remessa em bonificação, doação ou brinde, na NFC-e para tratamento de cortesias. Regras de Validação 1C17-38 Alterada a RV 1C17-38 que amplia a rejeição por não autorização de emissão ou irregularidade fiscal do emitente também para o modelo 55, visto que a denegação também deixa de existir para a NF-e. Regras de Validação 5E17-40 e 5E17-60 Alteradas as RV 5E17-40 e 5E17-60, transformando as respectivas denegações em rejeições para os destinatários do modelo 55. Exclusão da Regra de Validação N17c-30 Regra N17c-30 foi excluída a pedido do Estado do Ceará. Exclusão da Regra de Validação 1C17-40 Excluída a RV 1C17-40, eliminando a denegação também para o modelo 55. Regra de Validação N11-10 Criada a regra de validação N11-10 para exigir o preenchimento da origem da mercadoria quando o emitente não for CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI” Regra de Validação N12a-80 e N12a-81 Incluídas as regras N12a-80 e N12a-81 que verifica o correto preenchimento do CSOSN quando CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI”, nas operações internas e interestaduais. Regra de Validação N12a-90 Incluída a regra N12a-90 que verifica o correto preenchimento dos CFOPs quando CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI”, nas operações internas e interestaduais. Essa Nova NT se encontra disponível em nossa biblioteca, clique aqui para ter acesso a ela. Sobre os Prazos Essa NT esta prevista para ser implantada em homologação em 03/06/2024 e em produção em 02/09/2024. Sobre as Mudanças no ACBr e/ou na sua Aplicação A SEFAZ ainda não publicou os novos schemas, portanto vamos aguardar a publicação para podermos realizar as alterações no componente ACBrNFe, na lib ACBrLibNFe e no ACBrMonitor Plus.

Bom dia @Enéias Rodrigo, Gramado é atendido pelo provedor IPM, correto? Esse provedor exige que seja informado o usuário e senha. Você configurou o WSUser e WSSenha ? Configura a Lib para salvar os arquivos Soap, faça um novo teste e anexa aqui para que eu possa analisar. Caso tenha configurado o WSUser e WSSenha, favor verificar se estão corretos, pois o provedor pode ter um usuário e senha para emissão via portal e outra para emissão via webservice.

Bom dia @power, Essa nota foi enviada para o ambiente de homologação? Se sim, esse T pode significar "Teste". Verifica isso para mim, por favor.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia @PrimeSoftware, Se tratando do provedor ISSNet já um bom tempo um colaborador (membro do Fórum) nos enviou uma alteração no DANFSE feito em Fortes visando a impressão do mesmo segundo o layout do referido provedor. Sendo assim toda vez que você configura o componente com uma cidade que é atendida pelo provedor ISSNet o componente automaticamente imprimi o DANFSE segundo o layout do provedor. Se você estiver com todos os fontes de todas as pastas atualizados isso é para ocorrer. Lembrando que a impressão do DANFSE segundo o layout do provedor ISSNet só esta disponível em Fortes Report.

Bom dia @Facil Sistemas Ltda, Se você não atualizar os schemas vai ocorrer esse erro de validação.

Bom dia Maiquel, Já esta no SVN.

Bom dia @kohzito, Já esta no SVN.

Bom dia @eraldocg, Já esta no SVN.

Bom dia Jeferson, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5328

Bom dia @luisclaudio_jr, Não foi só isso que eu fiz. Realizei uma correção no código da unit que gerava um AV ao ler o XML. Dos 2 XML que você disponibilizou um foi lido com sucesso sem a necessidade de fazer nenhuma alteração, mas o outro ocorreu o AV. Detectei a linha onde isso ocorria e fiz a correção. Uma duvida: O XML que você esta tentando carregar esta salvo em disco ou no banco de dados? Se esta no banco de dados, pode ser que ele esteja acrescentando na string o caractere #$A que se não me falha a memória é quebra de linha. Neste caso basta executar um StringReplace no XML lido do banco de dados antes de ser carregado pelo LoadFromString.

Bom dia @Cristian Duarte Da Silva, É a sua aplicação que deverá ADD ao componente lotes de até 50 eventos. Se o componente detectar que foi ADD mais de 50 eventos vai ocorrer uma mensagem de erro e não vai ser enviado.

Boa tarde @Jeferson S Lima, Favor anexar a unit alterada para que possamos validar.

@eraldocg, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5324

@PrimeSoftware, Acho que não me expressei direto, no componente não temos a impressão do RPS somente da NFS-e (DANFSE) tanto em Fortes quanto em Fast Report. O que tem a ver a impressão com a os teste para saber se esta funcionando o envio, as consultas e o cancelamento?

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

@tryideas sistemas, Desculpa, não vi que você já tinha anexado. Vamos lá, se você abrir esse arquivo com o Bloco de Notas (não abra com o Notepad++) vai descobrir que ele esta no formato ANSI apesar que no inicio consta o encoding informando que esta no formato UTF-8. Com o Bloco Notas manda salvar com outro nome e mude o formato para UTF-8, depois tente abrir ele em um navegador. Resumo: O provedor esta gerando o XML no formato ANSI colocando o encoding UFT-8, isso esta errado. Entre em contato com o provedor e reporte o problema.

Boa tarde @kohzito, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5321

Boa tarde @Jonathan Gonçalves, A principio já era para estar funcionando desde de março/2024. Não vejo outra saída, você entrar em contato com a SEFAZ-RS e expor o problema.