Italo Giurizzato Junior

Boa noite Luiz, Se o usuário deleta o XML precisa ser demitido por justa causa, como ele deleta um documento? Outra coisa, o dono da empresa precisa tirar a capivara do bolso e comprar o HD externo que custa uma fortuna, em media 500 reais. Após carregar o componente com os dados, execute o método Assinar, depois o Validar por fim o Consultar. Vamos ver se dessa forma não ocorre o erro de "UF não pode ser vazia".

Boa noite Everton, Quando ocorre esse erro em "branco", facilita para podermos encontrar o problema, configurar o componente para salvar os arquivos soap da seguinte forma: Configuracoes.WebServices.Salvar := True; E anexar os arquivos gerados para que possamos analisar. Por favor faça isso.

Bom dia Rafael, É qual é o padrão que será adotado por eles?

Bom dia Bruno, Na verdade a tag esta sendo gerada na posição errada, já fiz a correção e ainda hoje vou enviar para o repositório.

Bom dia Cezar, Favor atualizar os fontes, note que fiz uma alteração no arquivo INI do provedor.

Bom dia Walfrido, É bem provável que o usuário digitou o PIN 3 vezes errado, logo o cartão foi bloqueado. Não sei porque tem pessoas que insistem em usar essa porcaria de certificado A3. Corre o risco de ter problemas de conexão do cartão com a leitora, problemas de conexão da leitora com a porta USB da maquina, tem que informar o PIN, tem uma DLL do Windows que possui um bug que faz com que o certificado seja apagado do cartão, não tem como fazer cópia do certificado. Já o A1, não temos nenhum dos problemas citados acima, a única desvantagem do A1 é o seu prazo de validade.

Bom dia a todos, André, na versão 4.00 isso mudou veja:

Bom dia a todos, Paulo, não importa de qual UF pertence o emitente do MDF-e, todos os MDF-e são recepcionados pela SEFAZ-Virtual do Rio Grande do Sul. Se você desenvolve em Delphi/Lazarus terá que desenvolver a sua própria aplicação para emitir o MDF-e, uma vez que o programa gratuito não terá mais suporte. Isso não significa que ele vai parar de funcionar, apenas não terá mais suporte, ou seja, se amanhã surgir uma alteração no layout do XML, não será disponibilizado uma nova versão dele visando o novo layout, ai sim não será mais possível a sua utilização.

Bom dia a todos, Se tratando de NFS-e onde existem provedores que não requer que o RPS seja assinado (35 para ser mais preciso) com certeza ao retornar o XML da NFS-e não vai estar assinado. Quanto a remoção das quebras não me recordo o motivo pelo qual elas foram inseridas.

Bom dia Everton, Favor entrar em contato com a prefeitura ou provedor e solicitar as URLs de produção e homologação, tudo indica que foram mudadas.

Bom dia MSX, O evento de Manifestação do Destinatário, como o próprio nome diz, é um evento enviado pelo Destinatário da mercadoria e não pelo emitente da Nota. Se eu vendo um produto para você e a nota é denegada, qualquer outro que tentar vender as notas serão denegadas, uma vez que você esta impedido pelo fisco de comprar. Como a venda não foi autorizada pela SEFAZ, não faz sentido você se manifestar sobre essa nota. Se eu vendo um produto para você e a nota é autorizada, mas em seguida eu cancelo a nota por desacordo comercial por exemplo, também não faz sentido você se manifestar sobre essa nota. Você deve sim se manifestar sobre todas as notas que foram autorizadas pela SEFAZ emitidas contra o seu CNPJ. O tipo de manifestação vai depender de cada caso. O cOrgao é sempre 91 uma vez que o evento de manifestação é sempre enviado para o Ambiente Nacional e não para a SEFAZ-Autorizadora. Conforme a Nota Técnica 2012/002 versão 1.02 - página 4 campo #HP04, no lote podemos ter até 20 eventos, neste caso teríamos um evento para cada nota, não necessariamente o mesmo tipo de evento de manifestação, ou seja, podemos por exemplo ter: 5 eventos com a manifestação de ciência da operação, 3 de desconhecimento da operação e os outros 12 de confirmação da operação. O numero do Lote não tem nada haver com o NSU que significa Numero Sequencial Único de um documento armazenado no Ambiente Nacional. A minha sugestão é que o numero do Lote seja um numero sequencial. Quanto ao método DistribuicaoDFe a minha sugestão é o usar o DistribuicaoDFePorUltNSU(CodUF, CNPJ, UltNSU), ao executar ele pela primeira vez o valor de UltNSU deve ser zero. Da segunda vez em diante devemos sempre utilizar como UltNSU o valor retornado na propriedade ultNSU e não maxNSU. A minha sugestão é que você leia as Notas Técnicas: 2012/002 versão 1.02 - que trata sobre a Manifestação do Destinatário 2014/002 versão 1.02b - que trata sobre a Distribuição de Documentos Fiscais Eletrônicos. Lembrando sempre que para o destinatário da mercadoria poder obter o XML completo da NF-e através do DistribuicaoDFe é preciso antes enviar o evento de Manifestação do Destinatário. O método DistribuicaoDFePorUltNSU ou DistribuicaoDFePorNSU ou DistribuicaoDFePorChaveNFe só vão retornar o XML completo da NF-e se a mesma foi manifestada, caso contrario será retornado um resumo da mesma. Detalhe importante os dois primeiros além de retornar um resumo ou a nota completa, retorna também resumo ou eventos completos que por ventura estejam vinculados a nota. Na página 6 da NT 2014/002 temos uma tabela do que pode ser retornado para o Destinatário da Mercadoria. Espero ter ajudado.

Bom dia Ignacio, A opção 14 - Duplicata Mercantil não existe mais, favor alterar para 15. Com relação a rejeição o problema esta no valor do desconto. [Fatura] nFat=001 vOrig=22.41 vDesc=0.00 vLiq=22.41 Realmente o desconto é zero, mas ao informar esse valor para o desconto, a tag <vDesc> não é gerada no XML, pelo simples fato que tanto na Nota Técnica quanto no Schema consta que a referida tag é opcional, sendo assim se o seu valor é zero não deve ser incluída no XML. Mas não sabemos se é um Bug na SEFAZ ou a Nota Técnica / Schema estão errados, pois se a tag <cDesc> estiver presente no XML a rejeição não ocorre. Por favor faça o seguinte testes, se o desconto for zero atribua ao campo vDesc o valor 0,01 conforme exemplo abaixo. [Fatura] nFat=001 vOrig=22.41 vDesc=0.01 vLiq=22.41 Com isso a tag <vDesc> será gerada no XML e acredito que a SEFAZ vai autorizar a nota pois erros de diferença de 1 centavo é tolerado pela SEFAZ. Fico no aguardo de um retorno.

Bom dia Luiz, Se o MDF-e foi enviado, autorizado pela SEFAZ e o XML do MDF-e consta o protocolo de autorização, me explica qual é motivo de executar o método Consultar antes do método Imprimir? O método Consultar devemos usar quando enviamos o MDF-e para SEFAZ e ocorre algum erro de comunicação. Ai sim executamos o método Consultar, pois se o erro ocorreu no retorno, teremos como resposta o protocolo de autorização ou a rejeição. Por outro lado se o erro de comunicação ocorreu no envio, teremos como resposta a informação que o MDF-e não consta na base de dados, ai devemos enviar novamente o MDF-e para SEFAZ. Outra coisa, como assim "Mas não gera o XML"? Para imprimir o DAMDFE é preciso ter o XML salvo em disco ou no banco de dados. Antes de executar o método Imprimir devemos carregar o XML usando o LoadFromFile (salvo em disco) ou LoadFromString (salvo no banco de dados).

Bom dia Carlos, Para o emitente da nota a única forma de obter o XML de uma nota emitida é através do site da SEFAZ da UF Autorizadora ou através do site do Portal Nacional da NF-e.

Bom dia fnd, Em qual unit esse fragmento de código se encontra? Que tipo de rejeição que esta ocorrendo ao enviar o evento, por favor seja mais especifico.

Bom dia Eptus, Pelo que pude notar analisando o código do componente, não existe uma variável que você possa acessar o XML de um evento que foi gerado para ser enviando para SEFAZ.

Bom dia Elvis, O pessoal vai acrescentar a sua proposta de correção juntamente com outras correções e melhorias. Sendo assim peço que tenha um pouco mais de paciência, pois eles estão finalizando os testes.

Bom dia Elvis, Desculpe mas "erros de ssl" , é muito genérico, favor informar quais erros estão ocorrendo.

Bom dia, No Manual do CT-e versão 3.00 que esta disponível no Portal Nacional do CT-e, contem tanto a estrutura do CT-e quanto do CT-e OS. O layout do CT-e OS é mais simples uma vez que não existe o Remetente, Destinatário, Expedidor e Recebedor, apenas o Tomador. Cuidado existe um grupo novo chamado <toma> para informar os dados do tomador. Com o manual em mãos se torna mais simples de saber o que deve ser informado. Outra coisa importante, o layout o modal rodoviário do CT-e também é diferente do CT-e OS e ambos estão presentes no manual.

Bom dia Luiz, Esse erro esta ocorrendo quando você tenta enviar o MDF-e ou algum evento do MDF-e. Favor anexar os XML gerados.

Boa tarde Fábio, Pelo seu relato inicial a sua aplicação esta funcionando sem nenhum problema em vários clientes, somente em dois que ocorre o travamento após o envio da primeira nota. Você disse que a versão do Windows é a mesma dos que esta funcionando, mas e as atualizações do mesmo? Antivírus, também é o mesmo? Se o problema é pontual, talvez a solução seja formatar a maquina do cliente.

Boa tarde Fernando, Uma coisa é o lote ter sido enviado e processado. Outra coisa é as notas contidas no lote terem sidas autorizadas ou rejeitadas.

Bom dia ALA, Esta com todos os fontes atualizados? Enviei uma alteração hoje, favor atualizar e fazer novos testes.

Novo tópico criado na área do SAC, para que o SLA de respostas seja considerado

Bom dia, Realmente esta faltando um Result := True dentro do IF que faz a leitura do XML do envio do evento. Já fiz a correção e vou enviar para o repositório. Por favor aguarde a nova compilação do Monitor. Ficamos no aguardo de um retorno.