Italo Giurizzato Junior

Bom dia a todos, Para realizar testes de envio usando o webservice antigo, lembre-se que só esta disponível o método Gerar e o arquivo Cidades.ini tem que esta da seguinte forma: [4202404] Nome=Blumenau UF=SC Provedor=NotaBlu ;Provedor=SimplISSv2 ;NomeURL_H=homologacaoabrasf ;NomeURL_P=blumenau Para realizar testes de envio usando o novo webservice, temos disponível os serviços: Enviar e Gerar, o arquivo Cidades.ini tem que esta da seguinte forma: [4202404] Nome=Blumenau UF=SC ;Provedor=NotaBlu Provedor=SimplISSv2 NomeURL_H=homologacaoabrasf NomeURL_P=blumenau Fico no aguardo de um retorno de vocês quanto aos testes de ambos os webservices. Lembre-se que o objetivo é fazer o componente funcionar 100% com o novo webservice.

Bom dia, Favor anexar o XML gerado, bem como o arquivo ACBrCTeServicos que a sua aplicação esta utilizando.

Olá pessoal, Segue abaixo um resumo mais detalhado da NT 2019/001 abrangendo todas as versões dessa NT. Resumo das versões v1.00/v1.10/v1.20 (entrada em produção 02/09/2019) Dificultar utilização de código de segurança fraco: • Regra de validação B03-10: Verificar formatação do cNF • Rejeição 897: Código numérico em formato inválido. Melhorar o controle de documentos referenciados e da identificação do destinatário: • Alterada a Regra de Validação BA10-40 (55), possibilitando a utilização do CNPJ 8 (será levado em consideração os 8 primeiros dígitos do CNPJ ou CNPJ Base), com o objetivo de identificar que a nota foi emitida pelo mesmo contribuinte, a critério da unidade federada. Rejeição 320: Contranota de Produtor referência somente NF de outro emitente. • Criada a Regra de Validação BA10-50 (55), exigindo que uma contranota de produtor rural somente possa referenciar uma nota emitida por outro produtor rural, a critério da unidade federada. Rejeição 922: Contranota de Produtor só pode referenciar NF-e ou NF de Produtor Modelo 4. • Criada a Regra de Validação BA20-20 (55), impedindo que seja referenciado um documento fiscal de uso exclusivo para operações internas em uma operação destinada a outra unidade federada ou para o exterior. Rejeição 923: Referenciado documento de operação interna em operação interestadual ou com o exterior. • Criada a Regra de Validação BA20-30 (55), impedindo referência a um Cupom Fiscal, a critério da unidade federada. Rejeição 924: Informado Cupom Fiscal referenciado. • Criada a Regra de Validação E03a-30, impedindo o uso simultâneo de IE e de identificação de estrangeiro para o destinatário. Rejeição 925: NF-e com identificação de estrangeiro e IE informada para destinatário. • Criada a Regra de Validação E14-30, impedindo informação de país de destino “Brasil” em operações destinadas ao estrangeiro. Rejeição 926: Operação com Exterior e país de destino igual a Brasil. • Criada a Regra de Validação E16a-40 (55), exigindo a indicação de “operação com consumidor final” quando se indica que a operação é destinada a não contribuinte. Rejeição 696: Operação com não contribuinte deve indicar operação com consumidor final. Descrever benefícios fiscais e informações da tributação do ICMS com mais precisão: • Criada a Regra de Validação N12-85, exigindo o código de benefício fiscal quando se utiliza um CST de benefício fiscal, a critério da unidade federada. Rejeição 930: CST com benefício fiscal e não informado o código de benefício fiscal. • Criada a Regra de Validação N12-86, impedindo que se informe o código de benefício fiscal para CST de benefício fiscal, a critério da unidade federada. Rejeição 928: Informado o código de benefício fiscal para CST sem benefício fiscal. • Criada a Regra de Validação N12-90, exigindo valor do ICMS desonerado e o motivo da desoneração, a critério da unidade federada. Rejeição 934: Não informado valor do ICMS desonerado ou o Motivo de desoneração. • Criada a Regra de Validação N12-94, exigindo que o CST corresponda ao tipo de código de benefício fiscal informado, a critério da unidade federada. Rejeição 931: Informado código de benefício fiscal incompatível com CST e UF. • Criada a Regra de Validação N12-97 (55), exigindo informações sobre o diferimento quando se utiliza um CST de diferimento, a critério da unidade federada. Rejeição 929: Informado CST de diferimento sem as informações de diferimento. • Criada a Regra de Validação N18-10 (55), exigindo a informação do percentual da margem de valor adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST seja MVA, a critério da unidade federada. Rejeição 931: Informada modalidade de determinação da BC da ST como MVA e não informado o campo pMVAST. • Criada a Regra de Validação N18-20, não permitindo informação do percentual da margem de valor adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST não for MVA, a critério da unidade federada. Rejeição 933: Informada modalidade de determinação da BC da ST como MVA e informado o campo pMVAST. Criação de valor máximo para a base de cálculo do ICMS, por unidade federada: • Criada a Regra de Validação W03-20, impedindo a informação de um valor de Base de Cálculo superior ao valor máximo estabelecido pela respectiva SEFAZ. Rejeição 935: Valor total da Base de Cálculo superior ao valor limite estabelecido. Melhor gerenciamento de informações sobre o destinatário, tanto no serviço de autorização de NF-e quanto no serviço de registro de EPEC (somente 55): • Criadas as Regras de Validação 5E17-10, 5E17-20, 5E1730, 5E17-40, 5E17-43, 5E17-46, 5E17-50, 5E17-60, 5E17-63, 5E17-70 e 5E17-80, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços. Obs.: todas as regras acima são validas somente para a NF-e (55), leva em consideração as informações: IE, CNPJ, CPF e UF. As regras acessam o Cadastro de Contribuinte da UF. Regra: 5E17-10 - Rejeição 233: IE do destinatário não cadastrada. Regra: 5E17-20 - Rejeição 234: IE do destinatário não vinculada ao CNPJ. Regra: 5E17-30 - Rejeição 624: IE do destinatário não vinculada ao CPF. Regra: 5E17-40 – Rejeição 302: Uso Denegado - Irregularidade fiscal do destinatário. Regra: 5E17-43 – Rejeição 305: Destinatário bloqueado na UF. Regra: 5E17-46 – Rejeição 306: IE do destinatário não está ativa na UF. Regra: 5E17-50 – Rejeição 232: IE do destinatário não informada. Regra: 5E17-60 – Rejeição 303: Uso Denegado - Destinatário não habilitado a operar na UF. Regra: 5E17-63 – Rejeição 305: Destinatário bloqueado na UF. Regra: 5E17-70 – Rejeição 246: CNPJ do Destinatário não cadastrado. Regra: 5E17-80 – Rejeição 623: CPF do Destinatário não cadastrado. • Criadas as Regras de Validação 6P31-10, 6P31-20, 6P31-30, 6P31-40, 6P31-43, 6P31-46, 6P31-50, 6P31-60 e 6P31-63, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NFe como destinatário na operação com mercadoria ou prestação de serviços. Obs.: todas as regras acima são validas somente para o Evento EPEC da NF-e (55), leva em consideração as informações: IE, CNPJ, CPF e UF. As regras acessam o Cadastro de Contribuinte da UF. Regra: 6P31-10 - Rejeição 233: IE do destinatário não cadastrada. Regra: 6P31-20 - Rejeição 234: IE do destinatário não vinculada ao CNPJ. Regra: 6P31-30 - Rejeição 624: IE do destinatário não vinculada ao CPF. Regra: 6P31-40 – Rejeição 302: Uso Denegado - Irregularidade fiscal do destinatário. Regra: 6P31-43 – Rejeição 305: Destinatário bloqueado na UF. Regra: 6P31-46 – Rejeição 306: IE do destinatário não está ativa na UF. Regra: 6P31-50 – Rejeição 232: IE do destinatário não informada. Regra: 6P31-60 – Rejeição 303: Uso Denegado - Destinatário não habilitado a operar na UF. Regra: 6P31-63 – Rejeição 305: Destinatário bloqueado na UF. • Criação de regra de validação H02-10 correspondente rejeição 927, para informar os números dos itens em ordem sequencial. Rejeição 927: Número do item fora da ordem sequencial. • Criado novo Valor para o Campo N18: A tag modBCST passa a aceitar a opção “6=Valor da Operação”. v1.30: Informados os locais de publicação das tabelas de códigos de benefícios fiscais e de regras de validação opcionais por unidade federada. Publicada a tabela cBenef x CST atualizada até 30/08/2019 Novas datas de vigência para algumas regras de validação. Comentários Sobre o Código de Benefício Fiscal: O código de benefício fiscal (tag: cBenef), por tratar de situações particulares de cada unidade federada, tem sua definição também especificada pelas UF que o utilizam. Estas definições constam de tabela publicada no Portal Nacional da NF-e, na área “Diversos” da aba “Documentos”. Esta tabela tem sofrido atualizações com frequência maior do que a desejável, em virtude do fato que o uso dos códigos pelas empresas no ambiente de homologação tem evidenciado a necessidade de ações de correção de natureza emergencial por parte das Administrações Tributárias envolvidas. É esperado que em futuro próximo a tabela tenha a estabilidade necessária. Novas Datas de Vigência para Algumas Regras de Validação: Em função de necessidades ditadas pelas legislações de algumas unidades federadas, e atendendo a pleitos de contribuintes e de entidades associativas, as datas de início de exigência das regras de validação N12-85, N12-86, N12-90, N12-94 e N12-97 obedecerão ao disposto na tabela a seguir: UF N12-85 N12-86 N12-90 N12-94 N12-97 MT 01/01/2020 01/01/2020 01/01/2020 01/01/2020 * E3 E3 E3 E3 PR 02/09/2019 02/09/2019 * 01/10/2019 02/09/2019 E2 E2 E2 E2 RJ 01/10/2019 01/10/2019 01/10/2019 01/10/2019 01/10/2019 E1, E3 E1, E3 E1, E3 E1, E3 E1, E3 RS 01/10/2019 01/10/2019 * 01/10/2019 * E2, E3, E4 E2, E3, E4 E2, E3, E4 Demais UFs * * * * * (*) Regra de validação não será aplicada Regra de validação: N12-85 – Exige o código de benefício fiscal quando se utiliza um CST de benefício fiscal. N12-86 – Impede que se informe o código de benefício fiscal para CST de benefício fiscal. N12-90 – Exige valor do ICMS desonerado e o motivo da desoneração. N12-94 – Exige que o CST corresponda ao tipo de código de benefício fiscal informado. N12-97 – Exige informações sobre o diferimento quando se utiliza um CST de diferimento. Exceções para aplicação das Regras de validação(E): E1 – Exceção 1: a RV não se aplica quando Finalidade de emissão da NFe (tag: finNFe) igual a Devolução de Mercadoria; E2 – Exceção 2: a RV não se aplica quando Finalidade de emissão da NFe (tag: finNFe) igual a Devolução de Mercadoria e Identificador de local de destino da operação (tag: idDest) igual a Operação Interestadual ou com o Exterior; E3 - a RV não se aplica quando Finalidade de emissão da NFe (tag: finNFe) igual a NFe de ajuste; E4 - a RV não se aplica quando Finalidade Tipo de Operação (tag: tpNF) igual a Entrada. As datas aqui definidas, com todas as demais informações a respeito das regras de validação opcionais por UF, podem ser consultadas em tabela publicada no Portal Nacional da NFCe, na área “Regras de Validação” da aba “Desenvolvedor”. Para contribuintes estabelecidos no estado do Rio Grande do Sul, no caso das regras N12-85, N12-86 e N12-94, o ambiente de autorização em produção, até 31/03/2020, e o ambiente de autorização em homologação até 09/02/2020, aceitarão três situações para o campo cBenef: * NULO (sem preenchimento do campo); * com a descrição "SEM CBENEF"; ou * com o código do benefício; Neste último caso, é realizada a devida validação de compatibilidade com o CST informado.

Boa tarde SHDW, Se esta com erro de estrutura isso significa que esta faltando alguma tag no XML. Pessoal, favor atualizar os fontes e façam novos testes, notem que fiz alteração no arquivo: SimplISSv2.ini

Boa tarde Fabricio, Solicite ao provedor um XML de exemplo de envio, de preferencia envelopado. Para que eu possa comparar com o que o componente esta gerando.

Boa tarde Souza, Como esses XMLs não se utilizam do mesmo namespace da NF-e e sim um especifico da SEFAZ-AM, acredito que deveria ser criado um componente para esse fim. Caso queira contribuir com a comunidade desenvolvendo esse componente e disponibilizando o seus fontes, ficaremos gratos.

Boa tarde Mozart, A alteração que você na unit referente a impressão do DANFSE, não vai gerar nenhum efeito colateral para os demais provedores?

Boa tarde Marco, Você poderia anexar o schema novo, pois o que tenho possui essa tag.

Boa tarde André, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde a todos, Favor atualizarem todos os fontes de todas as pastas. Notem que fiz alterações nos arquivos: Cidades.ini e SimplISSv2.ini Quero agradecer as alterações/correções realizadas nos fontes, elas já estão no repositório. Por favor façam testes enviando os RPS para o novo webservice. Usem o método Enviar para o envio de um lote com até 50 RPS e o Gerar para o envio de apenas 1 RPS.

Henrique, Muito obrigado.

Bom dia Henrique, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório. Favor anexar o arquivo INI do provedor para que eu possa fazer uma comparação com o que eu tenho.

Bom dia Tiago, Qual é o valor da propriedade de configuração SSLLib?

Bom dia, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Fabricio, Você esta usando o componente ACBrNFSe? Se sim, favor realizar testes usando o programa exemplo do componente.

Bom dia Fabricio, Vou fechar este tópico, pois já temos outro tratando do mesmo assunto.

Bom dia Moacir, Chegou a fazer testes com o programa exemplo do componente?

Bom dia, Me responda uma pergunta. Porque os demais colegas do fórum estão conseguindo emitir o CT-e com o QR-Code?

Bom dia Reij, Quando foi a ultima vez que você atualizou? Favor atualizar todos os fontes de todas as pastas. Reinstale a suíte ACBr. Como você esta fazendo os testes com a sua aplicação, acredito que você tenha criado uma pasta para colocar os schemas, correto? Pois bem essa pasta esta com os schemas atualizados? Se não estiver vai ocorrer erro de validação quando gerar o XML com o grupo infCTeSupl. Se não gerar esse grupo o CT-e vai ser rejeitado pela SEFAZ.

Não tem nenhum fonte cujo ícone esteja com uma bolinha vermelha? Se você altera um fonte, o Tortoise as vezes não consegue realizar o merge, neste caso o fonte fica desatualizado.

Boa tarde, Muito obrigado pelo XML de retorno que contem o evento de averbação. Agora é possível implementar a classe para poder ler os dados desse evento. Em breve será disponibilizado a atualização dos fontes com a leitura correta desse evento.

Boa tarde Flavio, Se você baixa o XML da NFS-e diretamente do site da prefeitura as tags vem com o prefixo "tc:"? Se não me falha a memória o componente ACBrNFSe remove os prefixos para facilitar a leitura do XML, visto que tem provedor cujo XML não tem prefixo, e os que tem o prefixo varia, ou seja, é diferente de um provedor para outro. Tudo bem, a aplicação que esse contador esta utilizando para ler o XML da NFS-e pressupõe que o mesmo tenha o prefixo "tc:". E se amanhã ocorrer uma licitação e quem ganhar é outro provedor, por exemplo o Ginfes cujo prefixo é "ns4:" ou Fiorilli cujas tags não tem prefixo, o desenvolvedor dessa aplicação vai ter que fazer os devidos ajustes para conseguir ler o XML. Não seria mais simples se essa aplicação removesse os prefixos, deixando assim os XML padronizados?

Boa tarde, Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr?

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

Boa tarde Paulo, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório. Da próxima vez procure utilizar o tópico criado exclusivamente para esse fim.