Italo Giurizzato Junior

Bom dia a todos, Não concordo com essa alteração, pois essa rotina é utilizada para ler o XML de todos os DF-e: NF-e, CT-e, MDF-e, BP-e, NFS-e, e-Social e Reinf. E cada DF-e possui um namespace diferente. O correto é entrar em contato com a SEFAZ e apontar o problema.

Olá pessoal, Vou prorrogar para o dia 07/10/2019 a remoção da propriedade de configuração: GerarInfMDFeSupl. Vou remover essa propriedade no final de semana, portanto que atualizar os fontes a partir do dia 07/10/2019 (Segunda-Feira) poderá ocorrer erros de compilação e ou execução. Para resolver esses problemas, releia a primeira postagem desse tópico.

Boa noite Paulo, Mas essa alteração na URL de homologação é valida para as demais cidades?

Boa tarde Daniele, No seu XML você não informou a justificada da entrada em contingencia. o campo xJust esta vazio. Outra coisa se a SEFAZ estiver parada, você gera o XML com o tpEmis=9, informa a data/hora de entrada de contingência e a justificativa. Por fim imprime o DANFE em dias vias, uma para o cliente e outra para o estabelecimento comercial. Quando os problemas forem sanados o XML deve ser enviado para a SEFAZ. Para mais informações vide o manual em anexo. Especificações Técnicas 2016_12_16 da Contingencia Offline versao 2.0.pdf

Boa tarde Maikon, Já enviei para o repositório. Revision: 17734

Boa tarde, As alterações feitas por tdpsistemas foram enviadas para o repositório. Revision: 17733

Boa tarde Ernesto, O correto é usar a rotina do componente para realizar a assinatura.

Bom dia Paulo, Com o método ConsultarNFSe você consulta a NFS-e passado o numero dela e temos como retorno o XML da respectiva nota. Se ela foi cancelada temos: (...).NFSe.NFSeCancelamento.DataHora; // data e hora do cancelamento (...).NFSe.Cancelada; // snSim ou snNao Se ela foi substituída temos: (...).NFSe.RpsSubstituido.Numero; (...).NFSe.RpsSubstituido.Serie; (...).NFSe.RpsSubstituido.Tipo;

Laudelino, Fique a vontade em perguntar. Só lembre de uma coisa: crie uma postagem nova para um questão diferente. Antes faça uma pesquisa no fórum, pois a sua duvida pode já ter sido respondida anteriormente.

Bom dia Mozart, Muito obrigado pelo retorno, vou analisar melhor a sua contribuição e espero que ainda hoje envio para o repositório.

Bom dia Fabricio, Muito obrigado pelas informações. O que achei estranho é que, os schemas se referem a versão 1 do layout da ABRASF, mas o webservice possui métodos que só existem na versão 2 do layout da ABRASF. Note que nos schemas temos a estrutura da consulta a situação do lote, mas no WSDL não temos esse serviço. No WSDL temos os serviços: GerarNFSe, RecepcionarLoteRpsSincrono e SubstituiNFSe e nos Schemas não temos a definição das estruturas para a montagem dos XMLs a serem enviados para esses serviços. O layout do RPS que o Webservice espera receber é da versão 1 ou 2? Se for 2, com base nos serviços listados no WSDL, então os schemas estão errados, pois não vai dar para gerar o XML do RPS e validar antes do seu envio. Esse pessoal é muito topeira, criaram um Schema para cada ambiente, o que muda é o namespace, em vez de criar um só com um namespace único.

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.

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

Bom dia Laudelino, Segundo o seu arquivo de configuração a versão do MDF-e esta errada, tem que ser 3.00 Ao atualizar o Monitor você realizou a instalação completa?

Boa tarde Narlem, Você esta enviando uma NFC-e para a SEFAZ-MG correto? Pois bem a SEFAZ-MG esta em contingencia se tratando de NFC-e. Isso explica o seu problema.

Daniele, Vamos as correções: 1. a versão do evento EPEC não é 4.00 e sim 1.00 2. o ID esta errado, ele é formado pelo literal ID + código do evento + chave da NF-e + o numero sequencial com 2 dígitos (no seu esta com 3 dígitos). 3. o CNPJ esta com 15 dígitos, notei que tem um 4 a mais. 4. as tags: vNF, vICMS e vST no caso do EPEC da NFC-e devem ficarem fora do grupo <dest>, elas são geradas após o fechamento do grupo ( </dest> ) e só tem as tags vNF e vICMS. Veja o Schema em anexo do detalhamento do evento EPEC para NFC-e. e110140NFCe_v1.00.xsd

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.

Daniele, Neste caso você pode estar montando o XML de forma errada, dai o erro de validação.

Boa tarde Daniele, Na pasta que contem os schemas eles estão separados, ou seja, uma pasta com os schemas da NF-e e outra pasta com os schemas do CT-e?

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.