Italo Giurizzato Junior

Bom dia a todos, Foi publicado a versão 1.20 da NT 2020/006 (16/03/2021) . O que mudou? Alteração em algumas regras de validação da SEFAZ e data de ativação tanto no ambiente de homologação quanto de produção. Veja como ficou as datas: Versão Descrição Homologação Produção 1.00 Criação de campos e Regras de Validação - seção 2 desta NT 01/02/2021 05/04/2021 1.10 Prazo de implantação desta NT v1.00 e v.1.10 para SV-AN, SP, MG e GO 01/03/2021 05/04/2021 1.10 Inclusão das regras YB01-10, YB01-20 e YB02-10 para modelo 65 01/03/2021 05/04/2021 1.10 Regra YA02-50 , observação 2 01/03/2021 05/04/2021 1.10 Regra B25c-10, observação 2 05/04/2021 01/09/2021 1.10 Regra Y08-90, observação a critério da UF 01/03/2021 05/04/2021 1.20 Regras YA02-60, YA06-10 e B25c-10, YA02a-10 e YA02a-20, inclusão do campo YA02a - xPag até 03/05/2021 01/09/2021 1.20 Regra YA02-50 foi eliminada até 03/05/2021 - Regra YA02-60 que é aplicada tanto para NF-e quanto para NFC-e: Verificar se o código do meio de pagamento (tag: tPag) existe na Tabela de códigos dos meios de pagamentos publicada no Portal Nacional da Nota Fiscal Eletrônica Observação 1: Regra válida a partir de 03/05/2021 (ou antes dependendo da SEFAZ-Autorizadora) para homologação e 01/09/2021 para produção Regra YA06-10 que é aplicada tanto para NF-e quanto para NFC-e: Verificar se o Código da bandeira de cartão de crédito e/ou débito (campo: tBand) existe na tabela de códigos das operadoras de cartão de crédito e/ou débito publicada no Portal Nacional da Nota Fiscal Eletrônica Observação 1: Regra válida a partir de 03/05/2021 (ou antes dependendo da SEFAZ-Autorizadora) para homologação e 01/09/2021 para produção Regra B25c-10 que é aplicada tanto para NF-e quanto para NFC-e: Se Informado indicativo de presença, tag: indPres, IGUAL a 2, 3, 4 ou 9 - Obrigatório o preenchimento do campo Indicativo do Intermediador (tag: indIntermed) Observação 1: Regra válida a partir de 03/05/2021 (ou antes dependendo da SEFAZ-Autorizadora) para homologação e 01/09/2021 para produção. Regra YA02a-10 que é aplicada tanto para NF-e quanto para NFC-e: Quando o código do meio de pagamento (tag: tPag) for preenchido com o código 99-outros, obrigatório o preenchimento da descrição do meio de pagamento (tag: xPag) Regra YA02a-20 que é aplicada tanto para NF-e quanto para NFC-e: Quando o código do meio de pagamento for diferente 99-outros (tag: tPag<>99), proibido o preenchimento da descrição do meio de pagamento (tag: xPag) Regra YA02-50 que é aplicada tanto para NF-e quanto para NFC-e: Esse regra foi eliminada das regras de validação da SEFAZ no que se refere as Informações de Pagamento. Inclusão da tag <xPag> (opcional) dentro do grupo <detPag> Grupo de Detalhamento do Pagamento para atender as regras YA02a-10 e YA02a-20. O componente vai ser atualizado assim que foi publicado os novos schemas para atender a nova tag (xPag). Sendo assim fiquem atentos as atualizações dos fontes ACBr. Como vai ter alteração nos schemas se faz necessário atualizar os schemas nas maquinas dos seus clientes assim que eles estiverem disponíveis.

Boa tarde Alexandre, A cidade do Rio de Janeiro se utiliza do provedor RJ que segue a versão 1 do layout da ABRASF. Nessa versão só temos o serviço de envio de lote no modo assíncrono, portanto você deve utilizar o botão [Enviar Lote RPS (Enviar)]

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

Boa tarde Marco, Já enviei para o repositório a unit.

Boa tarde a todos, Enviei para o repositório a contribuição do Deivid no que diz respeito a geração da tag <Aliquota>

Bom dia Marco, Não Schema, comparei o WSDL do ambiente de produção com o de teste e descobri o que foi mudado.

Bom dia a todos, Já inclui na minha lista de tarefas, muito obrigado a colaboração de todos.

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

Bom dia a todos, O componente ACBrReinf foi alterado para enviar os eventos na versão 1.5.1 e também foi incluído o evento R-2055. Peço a todos que atualizem todos os fontes de todas as pastas, reinstale a suíte ACBr usando o ACBrInstall_Trunk2 e por fim façam os testes.

Boa tarde Daniel, Concordo com você, inclusive o Gustavo teve o cuidado de incluir o novo enumerador por ultimo. Por outro lado essa informação errada que fica nesses dois campos pode ser tratada do lado da aplicação do desenvolvedor, conforme a minha postagem acima.

Boa tarde Joas, Você esta equivocado, a SEFAZ vai passar aceitar o XML com essa tag em ambiente de produção em 05/04/2021, mas só vai ativar a regra de validação em 01/09/2021.

Igor, Isso é estranho, pois se funciona com um era para funcionar com todos. Verifique se os que estão funcionando realmente esta pegando o arquivo que contem o URI=0

Boa tarde Gustavo, O problema é o seguinte: o componente ACBrNFe não possui uma classe para cada CST e CSOSN , possui somente a classe ICMS. E dentro dessa classe temos todos os campos que contempla todos os CST e CSOSN. Os campos modBCST e motDesICMS não são do tipo string ou integer e sim um tipo que possui enumeradores como você notou ao editar a unit pcnConversao. Sendo assim ao ler um XML se a rotina não encontra esses campos é atribuído o primeiro valor da lista de enumeradores. A classe da NF-e no componente ACBrNFe que eu me recordo já faz uns bons anos que é assim. No meu entendimento você pode contornar essa situação lendo somente os campos que pertence a um CST ou CSOSN para popular o banco de dados.

Boa tarde Igor, Acontece que esse arquivo INI esta desatualizado. Todas as filiais são da mesma cidade?

Boa tarde Edu, O componente esta configurado para o modelo: moCTeOS e versão: ve300? A rede tem firewall, antivírus?

Boa tarde Marco, Faça um teste com essa Unit em anexo. ACBrReinfWebServices.pas

Marco, Por favor, anexe os XMLs gerados ao realizar a consulta. O erro 500 normalmente ocorre quando o XML contem ou esta faltando algo e em vez do webservice retornar uma rejeição simplesmente gera o erro 500. Quero verificar o XML do pedido de consulta com os schemas.

Marco, O programa exemplo esta configurado para a versão 1.5.1, correto? Essa consulta esta sendo realizada no ambiente de teste ou de produção? Não acompanho o Reinf, mas até onde sei somente o ambiente de teste dessa versão que esta liberado.

Bom dia a todos, A imagem do programa exemplo é da versão para o Delphi? Se sim, então os fontes devem estarem desatualizados, pois foi incluído o evento R-2055.

Bom dia Igor, Por favor, abra o arquivo Natal.ini e verifique se o valor do campo URI é 0. Se sim, isso significa que os seus fontes estão desatualizados.

Bom dia Deivid, Nos meus testes não tive erro de validação no que se refere a alíquota. Você esta usando os schemas da pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\Schemas\Abacov2 ? Não tive erro de mensagem vazia ao tentar enviar o Rps. Favor utilizar o programa exemplo do componente e configurar ele para salvar os arquivos Soap.

Bom dia Igor, Esse é o grande problema, por conta da falta de padronização da NFS-e as rotinas que fazem a leitura do XML ainda não atende toda lambança feita pelos provedores. É por isso que sempre peço para não gerar o XML do RPS, depois carrega-lo e por fim enviar. Mas muito obrigado pela colaboração, já inclui na minha lista de tarefas.

Bom dia Fabio, Uma pequena correção. Se tratando do CT-e não se faz necessário enviar nenhum evento de Manifestação do Destinatário, pois estes eventos se referem a NF-e. Uma coisa importante é que o serviço de Distribuição de DF-e disponibilizado pelo Ambiente Nacional que nos permite baixar o XML da NF-e, CT-e e MDF-e não funciona para o emitente do documento. Exemplificando, a transportadora que é a que emite o CT-e não consegue baixar o XML do CT-e emitido por ela, pelo simples fato de que ela tem a obrigação legal de ter e guardar esse XML pelo prazo estipulado pelo Fisco. Já o remetente e o destinatário da carga podem usar o DistribuicaoDFe que se encontra no componente ACBrCTe para baixar o XML do CT-e.

Boa tarde Igor, Verifique se o CPF informado realmente é valido, as vezes o numero esta errado e o webservice retorna uma rejeição que não tem nada haver.