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 emdri, Você poderia anexar o XML da NF-e que foi rejeitada?

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>

Se tem um componente para imprimir o DANFE NFCe em tamanho A4 e só sai retrato é porque não foi feito ainda o modo Paisagem. Quando tiver os 2 ai sim os valores tiRetrato e tiPaisagem vão ter utilidade. Já os valores tiNFCe e tiMsgEletronica só faz sentido para a NFC-e, o primeiro indica que o DANFE é da NFC-e que a principio o seu layout é para ser impresso em bobina, já o segundo não deveria imprimir nada, pois indica que vai ser enviada uma mensagem eletrônica com o link para poder ter acesso ao DANFE

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

O componente feito em Fortes para emissão do DANFE NFC-e se eu não estiver enganado não verifica o valor da propriedade de configuração, pois ele foi feito para ser impresso em bobina. Idem o DANFE NFC-e feito em EscPos. Não sei se temos algo para emitir o DANFE NFC-e em folha A4.

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.

Bom dia, Não entendi "não tem efeito prático na impressão"? Algumas dessas opção tem efeito prático sim na impressão do DANFE da NF-e e outras na impressão do DANFE da NFC-e. Não teria efeito caso o formato da impressão estivesse condicionado ao valor do campo tpImp que se encontra no XML, conforme a sugestão do BigWing, ai sim poderíamos remover essa propriedade do componente.

Bom dia Udenilson, Por favor abra o arquivo ISSNet.ini e verifique o conteúdo da sessão URL_P. Tem que estar da seguinte forma: [URL_P] RecepcaoLoteRPS=http://www.issnetonline.com.br/webserviceabrasf/%NomeURL_P%/servicos.asmx ;Cuiaba/MT RecepcaoLoteRPS_5103403=https://ws%NomeURL_P%.issnetonline.com.br/webserviceabrasf/%NomeURL_P%/servicos.asmx Se não estiver, isso significa que os seus fontes estão desatualizados.

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

Sim, Me parece correto com relação a tag <indIntermed>

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, Nesse XML consta a tag <indIntermed> para não gerar a tag é preciso atribuir o valor iiSemOperacao ao campo indIntermed. E para quem utiliza o ACBrMonitor deve deixar o campo sem nenhum valor: indIntermed=

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.