Italo Giurizzato Junior

Boa tarde a todos, Favor atualizar os fontes, reinstalar os componentes e façam novos testes.

Boa tarde a todos, O componente ACBrCTe tem uma propriedade de configuração chamada: GerarInfCTeSupl que pode receber os seguintes valores: fgtNunca = não vai gerar no XML o grupo InfCTeSupl que contem a string do QR-Code; fgtSomenteProducao = só gera se o componente estiver configurado para o ambiente de Produção; fgtSomenteHomologacao = só gera se estiver configurado para o ambiente de Homologação fgtSempre = vai gerar no XML o grupo InfCTeSupl. O valor padrão é fgtNunca, mas a partir do dia 22/07/2019 para realizar testes no ambiente de homologação essa propriedade deve estar com o valor fgtSomenteHomologacao. E a partir do dia 26/08/2019 para o envio em ambiente de produção a propriedade devera esta com o valor fgtSomenteProducao ou fgtSempre. Quando se tornar obrigatório em ambos ambientes iremos remover essa propriedade de configuração do componente.

Boa tarde a todos, O componente ACBrMDFe tem uma propriedade de configuração chamada: GerarInfMDFeSupl que pode receber os seguintes valores: fgtNunca = não vai gerar no XML o grupo InfMDFeSupl que contem a string do QR-Code; fgtSomenteProducao = só gera se o componente estiver configurado para o ambiente de Produção; fgtSomenteHomologacao = só gera se estiver configurado para o ambiente de Homologação fgtSempre = vai gerar no XML o grupo InfMDFeSupl. Essa propriedade em breve vai deixar de existir, uma vez que a exigência em ambos os ambientes já foi ativada pela SEFAZ.

Boa tarde, O problema é que a partir de hoje a SEFAZ passou a exigir a string do QR-Code no XML do MDF-e em ambiente de produção. Logo estaremos disponibilizando uma nova versão do Monitor que gera essa string.

Bom dia João, Para um melhor entendimento sobre esse assunto assista o vídeo.

Bom dia Paulo, Se você abrir os XMLs vai notar que o problema não é o cancelamento e sim na consulta. Vou fazer os ajustes e enviar para o repositório ainda hoje.

Felipe, No retorno do DistribuicaoDFe não temos um campo para informar qual foi o tipo de Manifestação realizado. Se o DistribuicaoDFe retornar um resumo da nota, sabemos que a mesma não foi Manifestada, por outro lado se retornar o XML completo da Nota, sabemos que a mesma foi Manifestada. É preciso fazer um trabalho bem feito de conscientização na empresa, pois como lhe disse o processo esta errado. O programa disponibilizado pela Receita se utiliza de uma outra versão do WebService do DistribuicaoDFe não documentado e que não possui todos os recursos do WebService utilizado pelo componente. Acredito que futuramente teremos uma nova versão desse WebService com todos os recursos, ou seja, vamos saber se a nota foi manifestada ou não e qual foi o evento.

Felipe, Primeiramente isso esta totalmente errado. Como a Contabilidade sabe que a empresa comprou ou deixou de comprar de uma determinada empresa? E pior, ela envia um evento de manifestação do destinatário só para ter o XML da nota. Se a empresa não possui um departamento de Compras certamente que faz as compras é o Almoxarifado, sendo assim este é quem deve monitorar as notas e enviar o evento de manifestação mais adequado a cada uma delas. Caso a empresa possua um departamento de Compras, este deve comunicar ao Almoxarifado que foi realizado uma compra, de quem comprou e o que comprou, ou seja, enviar para o Almoxarifado uma cópia do Pedido de Compra e este fazer o monitoramento das notas. A Contabilidade é o departamento fim.

Bom dia Felipe, Primeiramente, lembre-se que o DistribuicaoDFe pode retornar Resumos de notas, Notas completas, Resumos de Eventos e Eventos Completos. (...).docZip.Items[ i ].resEvento.tpEvento <== aqui temos o tipo de evento retornado no XML de resumo de evento (...).docZip.Items[ i ].procEvento.tpEvento <== aqui temos o tipo de evento retornado no XML de evento completo (...).docZip.Items[ i ].procEvento.RetinfEvento.tpEvento <== aqui temos o tipo de evento retornado no XML de evento completo e se o grupo <retEvento> estiver presente no XML.

Muito estranho, você teria o XML de envio da nota e o de retorno para que possamos analisar? Se sim, favor anexar.

Marcelo, No meu entendimento é refazer por completo o DAMDFE deixando o mais parecido possível com o que consta no manual. Caso você não tenha os novos manuais, por favor acesse a nossa biblioteca através do link: http://svn.code.sf.net/p/acbr/code/tools/DFe/MDFe/Manuais/ Os mais atuais são os 3 que traz em seu nome a versão 3.00a

Boa tarde, Esta emitindo NF-e ou NFC-e? Qual é a UF do emitente?

Boa tarde Caio, Se há necessidade de emitir uma nota com ISSRetido e o manual não mostra onde devemos informar os valores dos campos em questão, não vejo outra alternativa entrar em contato com a prefeitura ou com o provedor e solicitar um XML de exemplo.

Marcelo, Se eu tiver mais de uma seguradora envolvida? O numero da apólice, é um só por seguradora, mas o numero da averbação podemos ter "N". Veja como vai ser a nova versão do DAMDFE a partir de outubro/2019

Eu tentei com esse também e não vai. Outra coisa, abra o link do WSDL que o Neilton te passou e procure pelo namespace que ele quer que seja informado, só aparece na URL do ambiente de homologação, logo no inicio do WSDL fica claro que o namespace é "http://www.tinus.com.br". 1-env-lot-soap.xml O erro que esta ocorrendo agora é: Como dito antes, em vez de erro 400 agora é 500.

Boa tarde Adilson, A principio pode, desde que outras informações não sejam suprimidas e cujo o conteúdo do código de barras esteja presente no XML da NFS-e. Notei que ele é composto pela concatenação de 3 informações, sendo que a primeira é o numero da NFS-e, a segunda é o código de verificação e depois temos o que parece ser o CNPJ do emitente (segundo a imagem). A principio a maioria dos provedores se utilizam apenas o código de verificação para que o tomador possa checar se realmente a nota foi emitida. Vejo que esse código de barras é algo especifico de Catanduva/SP.

Boa tarde Gumercino, Essa sua alteração pode gerar efeito colateral em outros provedores. Favor atualizar os fontes e faça novos testes.

Boa tarde Marcelo, Você tem algum PDF de como estava antes e de como ficou agora? Se sim, poderia anexar os dois PDF?

Boa tarde, Esse pessoal da Tinus é uma piada. Se você comparar esse XML (de exemplo) com o WSDL (já que eles não disponibilizam os arquivos XSD - Schemas) vai notar logo de inicio duas contradições: No XML exemplo temos a tag <EnviarLoteRpsEnvio> com o namespace, mas essa tag não existe no WSDL, o que existe no lugar dela é a tag <Arg>. No XML o atributo da tag <LoteRps> é "Id", mas no WSDL esse atributo é "id", ou seja tudo minúsculo. No XML a tag <CodigoTributacaoMunicipio> esta antes da tag <CodigoCnae>, mas no WSDL esta o contrario. Resumindo, se seguir esse XML de exemplo com certeza o RPS será rejeitado, por conta dessas diferenças. A evolução que tive foi de que agora não ocorre mais o erro 400 e sim 500. Em anexo o XML que o componente esta gerando para o envio do lote completo com a tag <Envelope> Favor enviar esse XML a eles, quem sabe alguém mais capacitado dessa empresa possa indicar o que esta errado ou o que esteja faltado ou o que esteja a mais. 1-env-lot-soap.xml

Boa tarde João, Já passei para o pessoal analisar a sua alteração no que diz respeito a unit. Deste já muito obrigado pela colaboração. Uma pergunta: porque você ainda usa o XsXmlSeg em vez de XsLibXml2?

Bom dia, Tente este outro: https://dfe-portal.svrs.rs.gov.br/Mdfe

Bom dia Eliezer, Muito obrigado pela colaboração, já enviei para o repositório. Detalhe, os seus fontes estão desatualizados.

Bom dia, A única diferença que notei entre o XML de pedido de cancelamento gerado pelo componente e o de exemplo é que a tag <CodigoMunicipio> esta diferente. Gerada pelo componente o conteúdo é: 2611606 já o do exemplo o conteúdo é: 261160. Ou seja, o XML gerado pelo componente esta sendo informado o código IBGE completo do código do município, já no XML de exemplo esta faltando o ultimo digito que se não me falha a memória é um digito verificador. Como os webservices dos provedores costumam retornar mensagens de rejeição que não condiz com o problema, experimente informar o código do município se o ultimo digito.

Bom dia Guto, Muito obrigado pela colaboração, já enviei para o repositório. Um detalhe importante, os seus fontes estão desatualizados.

Bom dia Gumercino, Favor anexar a unit alterada para que possamos analisar.