Italo Giurizzato Junior

Bom dia Luiz, Que maravilha, avisam nos 47 minutos do segundo tempo.

Bom dia Anadilson, Favor atualizar os fontes, reinstalar o ACBr e faça novos testes.

Bom dia Eduardo, Estudando a implementação do método ImprimirDANFSePDF do Fast Report não encontrei nada que pudesse ele ter esse comportamento, ou seja, gerar o PDF e enviar para impressora. Verifica se na sua aplicação se não esta sendo executado também o método ImprimirDANFSe,

Bom dia Patrick, Qual é a configuração do programa exemplo no que se refere ao Certificado e WebService?

Bom dia a todos, Favor atualizar os fontes, reinstalar o ACBr e realizar testes com a cidade de Sorocaba.

Boa tarde Dercide, O código de verificação esta sendo retornado no campo Protocolo e não em CodVerificacao Não me recordo muito bem o porque dessa mudança.

Eduardo, A não ser que tem alguma implementação diferente para o Fast Report, pois para o Fortes Report ele não imprime somente gera o PDF.

Boa tarde Paulo, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-2328

Boa tarde Gilson, Estou analisando ainda.

Boa tarde Marcelo, Verifica se na cidade que utiliza esse provedor não disponibiliza os schemas, quem sabe tem alguma atualização deles.

Boa tarde Flavio, No arquivo ACBrNFSeXServicos se tratando do provedor Betha, veja esses 2 exemplos: [4202305] Nome=Biguacu UF=SC Provedor=Betha [5103353] Nome=Confresa UF=MT Provedor=Betha Versao=2.02 ProRecepcionar=http://e-gov.betha.com.br/e-nota-contribuinte-ws/nfseWS HomRecepcionar=http://e-gov.betha.com.br/e-nota-contribuinte-test-ws/nfseWS O segundo deixa claro que a versão é 2.02, portanto o primeiro a versão é 1.00 Resumindo, a cidade de Biguaçu/SC se utiliza do provedor Betha (versão 1 do layout da ABRASF), já a cidade Confresa/MT também se utiliza do provedor Betha só que verão 2 do layout da ABRASF. Se a cidade de Lucas do Rio Verde/MT usa a versão 2, tem que ser semelhante ao da cidade Confresa.

Boa tarde Camila, O componente ACBrNFSeX, alias todos os componentes ACBr que geram XML sempre geram se identação e sem quebra de linha. Você concorda que um XML identado e com quebra de linhas tem muito mais caracteres do que o mesmo XML sem identação e sem quebras de linha? Isso interfere sim na assinatura principalmente no DigestValue que é uma espécie de Checksum. O Webservice do provedor pode até remover do XML recebido as quebras de linhas e a identação, mas ao validar a assinatura vai falhar pois o DigestValue vai ser diferente.

Boa tarde Daivid, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-2327

Bom dia Brisola, Ele já esta pronto, mas como só vai ser liberado amanhã estou aguardando para enviar as alterações. Aproveitando, você sabe qual é a URL do ambiente de produção?

Boa tarde Eduardo, Mas o método ImprimirDANFSePDF, apesar do nome ele somente gera o PDF.

Boa tarde, No link abaixo você encontra a cartilha do MDF-e que contem diversas situações, ela bem didática. Portal do Manifesto Eletrônico de Documentos Fiscais - SVRS Vale a pena baixar ela e dar uma lida. Deve estar faltando algo que eu tenha esquecido.

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

Boa tarde Marcos, Analisando as Units que você anexou na mensagem privada que me enviou notei que você tomou como base as units do provedor ISSSJP e como dito acima esse provedor segue a versão 1 do layout da ABRASF. A cidade de Cambé/PR possui um webservice próprio com um layout próprio, logo se faz necessário se basear em um provedor que também tem um layout próprio. Você vai notar e a codificação nas Units *.Provider, *.GravarXml e *.LerXml é diferente, ou melhor tem muito mais coisas.

Acabei de realizar um teste usando o programa exemplo e a tag <ResponsavelRetencao> foi gerada com o valor 1 ao atribuir o valor rtTomador ao campo: Servico.ResponsavelRetencao. Detalhe importante a tag só é gerada se o valor de IssRetido for diferente de stNormal.

Bom dia Daivid, O componente usa os Schemas para validar o XML gerado por ele e não para gerar o XML. Se faz necessário agora alterar a Unit responsável por gerar o XML que no caso é ISSDSF.GravarXml. Não esqueça de alterar a Unit responsável pela leitura do XML: ISSDSF.LerXml

Bom dia Flavio, Você ainda esta usando o componente antigo? Se sim, lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não vai mais ter manutenção. Faça os testes usando o programa exemplo do novo componente. Manual de Migração https://www.projetoacbr.com.br/forum/topic/63017-manual-de-migração-para-o-novo-componente-de-emissão-de-nfs-e/

Bom dia Felipe, Se não me falha a memória na sua maquina de desenvolvimento no programa instalador (ACBrInstall_Trunk2 tem uma opção ativa que copia as DLL para a pasta do Windows. Ao executar uma aplicação que depende de uma DLL, ela primeiro procura pela DLL dentro da pasta onde a aplicação se encontra, se não achar vai procurar dentro da pasta do Windows (System ou SysWOW64).

Brajan, Então é algum problema na SEFAZ-MG. O jeito vai ser entrar em contato com eles e expor o problema. Nestes casos é interessante anexar os XMLs dos CT-e para provar que o que esta sendo referenciado foi enviado e autorizado o segundo que contem a chave do outro e o XML de rejeito com a rejeição.

Bom dia, Pela regra é necessário você ter 1 MDF-e para cada alteração da carga contida no caminhão. Por exemplo, o caminhão parte da cidade A, vai até a cidade B e descarrega uma parte da carga, depois segue até a cidade C onde vai descarregar o restante. Você vai emitir o MDF-e 1 com carregamento em A e descarregamento em B, neste MDF-e você vai informar todos os CT-e, pois o caminhão vai para a cidade B com a carga total. Vai emitir também o MDF-e 2 com o carregamento em A e descarregamento em C, neste MDF-e você vai informar somente os CT-e cuja carga vai ser descarregada em C.

Bom dia, Qual é a cidade?