Italo Giurizzato Junior

Bom dia Thiago, Uma coisa é certa você não esta com os fontes atualizados. Pois essa alteração foi realizada pelo Jairo e disponibilizada por mim em 15/04/2014.

Bom dia Dércio, Na NFC-e não existe o transportador, normalmente é o próprio destinatário que leva a mercadoria, a não ser no caso de Delivery, mas mesmo assim, até onde sei, não podemos informar o transportador.

Bom dia André, Algo de errado você esta fazendo, pois nunca ocorreu comigo. Uma vez que o XML tem que ser assinado para ser enviado. O que pode ocorrer é o XML assinado após o envio ficar sem o protocolo, mas isso é resolvido realizando uma consulta. 1. Carrego o XML assinado; 2. Realizo a Consulta; O XML é atualizado ficando assinado e protocolado. Outra coisa, na minha aplicação o XML é gerado e assinado somente uma unica vez através do comando Enviar. Não fico gerando o XML e salvando, depois carrega para assinar e salva novamente, depois carrega novamente para enviar. Outra coisa importante, o CTe tem uma TAG chamada cCT - código do conhecimento de transporte, esse código deve ser aleatório e faz parte da chave e consequentemente pode alterar a assinatura e o DigestValue. Se toda vez que você gerar o mesmo XML gerar um novo cCT e depois realizar a sua assinatura vai ocorrer o problema que você descreveu.

Bom dia Graça, Vamos ver se eu entendi: "§ 7º Na hipótese estabelecida no inciso II desta Cláusula, a obrigatoriedade de emissão do MDF-e é do destinatário quando ele é o responsável pelo transporte e está credenciado a emitir NF-e.". Se o Destinatário da carga é que vai realizar o transporte da mesma e este esta credenciado a emitir NF-e, fica obrigado a emitir o MDF-e, correto? Se sim, neste caso só se a carga contida no caminhão for fracionada e interestadual caso contrario não há necessidade. Esse é o meu entendimento.

Bom dia Caetano, Resposta da SEFAZ: "A respeito do tema de eliminação do web service da consulta status serviço, informo que o assunto foi tratado na reunião do Grupo XML de Documentos Fiscais Eletrônicos realizada em Porto Alegre de 29 a 31/01. A maioria dos técnicos do Fisco presentes se manifestou favorável a retirada do ar deste serviço não apenas para NFC-e mas também para a NF-e modelo 55. Todavia, o assunto será primeiramente discutido pela Coordenação Técnica do ENCAT na próxima reunião do Grupo Técnico dos Players de NF-e que corresponde a um grupo de representantes de empresas de provimento de soluções de NF-e. Este GT é coordenado pela GS1. Desta forma ainda não há definição se este we service será eliminado ou não e qual seria a eventual data prevista para discontinuidade deste serviço. Caso se decida pela retirada do ar deste serviço, o fato será amplamente divulgado com antecedência para que as empresas emissoras de NF-e e NFC-e se adaptem a esta nova realidade. De todo modo, a orientação técnica é que não se utilize, em nenhuma hipótese, este web service para automação de entrada e/ou saída de contingência. Recomenda-se que a empresa que queira automatizar este processo deva utilizar as informações estatísticas obtidas do próprio processo de autorização de NF-e/NFC-e. Lembramos ainda que a informação do tempo médio de autorização de NF-e nos últimos 5 minutos consta de campo tMed (página 26 do Manual de Orientação ao Contribuinte v 5.0)."

Boa noite Rick O problema é dos aproximadamente 30 provedores implementados uns 27 seguem o padrão ABRASF, um que você se basear é o ISSDSF.

Boa noite Dércio, Repense na sua rotina, principalmente nesse quesito de consultar o status antes de gerar a nota. Pelo simples fato que a SEFAZ acena em acabar com o consultar status.

Marcelo, Ao criar um novo Tópico existe um botão para anexar arquivos. Você pode agora editar o seu tópico e ao fazer isso acredito que vai estar disponível também esse botão.

Boa tarde Rick, Esse provedor não segue o padrão ABRASF. Se desejar contribuir com o projeto, implementando esse provedor fique a vontade.

Ailton, Como lhe falei, com esses arquivo podemos ter algumas dicas do que pode estar ocorredo, veja: <enviarReturn xsi:type="xsd:string">ERRO VALIDACAO XSD: (400)error: org.xml.sax.SAXParseException: cvc-type.3.1.3: The value '' of element 'CEPTomador' is not valid. Linha : 1 Coluna: 1421</enviarReturn> Vamos simplificar a mensagem: ERRO VALIDACAO XSD: The value '' of element 'CEPTomador' is not valid. Traduzindo: O elemento CEPTomador possui o valor '' (string vazia) que é inválido. Ou seja, Você não informou o CEP do Tomador.

Boa tarde, Por favor não post rotinas completas, anexe as mesmas, deixa o post mais curto. Content for element '{http://www.portalfiscal.inf.br/mdfe}veicTracao' is incomplete according to the DTD/Schema. Alguém já teve esse problema? Sim, vários colegas tiveram esse problema e a solução foi configurar o componente com a versão 1.00a, utilizar os schemas disponibilizados junto com o programa exemplo. Outra coisa note que a mensagem diz que o elemento veicTracao esta incompleto. Você comparou a sua rotina com a estrutura do XML que consta na Nota Técnica 2013/004 versão 1.00a de Outubro/2013 ?

Boa tarde Carlos, Não existe a possibilidade de consultar um evento, no seu caso o de cancelamento para obter o *-procEventoNFe.xml que seria o arquivo que contem a solicitação de cancelamento e o respectivo retorno da SEFAZ acusando que o mesmo foi registrado e vinculado a NFe. O componente não possui essa funcionalidade uma vez que não existe um Web Services para tal consulta. O que temos é a possibilidade de consultar a situação de uma NF-e, é através desta consulta que teremos o retorno acusando que a mesma esta cancelada.

Boa tarde Jorge, Obrigado pelas informações. Como não utilizo e nem faço parte do desenvolvimento do ACBrNFeMonitor, não sei se o mesmo trata de forma amigável os retornos, mais precisamente quando ocorre Rejeição.

Boa tarde Luis, Com certeza deve ser alguma falha no Web Services da SEFAZ-SP.

Boa tarde Ailton, Atribua o valor True a propriedade ACBrNFSe.Configuracoes.WebServices.Salvar. Realize os testes novamente. Com a propriedade acima setada com o valor true será gerado vários arquivos *-soap.xml eles possui a estrutura completa dos XMLs de envio e de retorno do Web Services. Os de retorno podem lhe dar alguma dica do problema que esta ocorrendo.

Bom dia Carlos, Se você atribuir o valor True a propriedade: ACBrNFe.Configuracoes.Arquivos.Salvar o retorno da consulta será salvo automaticamente pelo componente.

Bom dia Marcelo, Por favor, procure sempre postar alterações/correções e sugestões em fontes, postando como anexo o fonte alterado. Fica mais fácil realizarmos um merge.

Bom dia Renato, Podemos concluir que emitir a NFS-e via Site é uma coisa, pelo Web Service é outra. Rotinas diferentes, requisitos diferentes, portanto sem nenhuma padronização, depois vem o cliente e diz pelo site da para fazer pelo seu programa não.

Bom dia, Sem os schemas, Name Space, URLs dos ambientes de Homologação e Produção utilizados pelo provedor, não tem como implementar.

Bom dia Ailton, Tente desta forma: sProt := ACBrNFSe1.WebServices.Enviar.Protocolo;

Bom dia Jorge, Esse aplicativo X, você sabe me dizer se ele utiliza o componente ACBrNFe para emitir NF-e?

Bom dia, Realmente a mensagem "Homologação - Sem Valor Fiscal", estava sendo impresso na área errada. Fiz a correção. Se o tipo de emissão for offline será impresso na área VI o titulo Emissão em Contingência. Quanto ao QR-Code nos meus testes ele esta sendo impresso com o tamanho de 3,2 x 3,2 portanto maior que o mínimo estabelecido que é 2,5 x 2,5. Entre a área que é impresso o valor aproximado dos tributos e a área de mensagem fiscal foi incluída a área de mensagem de interesse do contribuinte (campo Va) conforme consta em: Especificações Técnicas do DANFE NFC-e QR-Code Versão 3.2 01/04/2014 (página 5). Lembrando que o conteúdo a ser impresso nessa área tem que constar no XML na TAG: infCpl. Esta faltando incluir mais uma área após o QR-Code, que é destinada a mensagens para o consumidor e que não consta no XML (página 8). "Importante - Caso o contribuinte queira imprimir, no mesmo papel do DANFE NFCe, mensagens institucionais ou outras informações que não estejam no arquivo XML da NFCe, as mesmas deverão ser apresentadas após o final do DANFE NFCe (imediatamente após protocolo de autorização da NFCe – divisão VIII)." Favor atualizar os fontes e testar.

Bom dia, Muito estranho, a principio com exceção da linha a mais na assinatura do resto não vejo algo que poderia estar provocando esse erro.

Bom dia Caejr, Você utiliza o componente ou o Monitor? Se é o componente, qual é o Report utilizado para imprimir o DANFE?

Bom dia a todos, Evitem ao máximo o uso do Consultar Status para uma tomada de decisão automática. A SEFAZ cogita em acabar com esse Web Services. Segundo a SEFAZ o caminho é: 1. Tentar enviar para o Web Service que recepciona a NF-e/NFC-e 2. Se falhar o envio, consultar o status do SVC 3. Se ativo, enviar a NF-e/NFC-e para o SVC. A volta: 1. Tentar enviar para o SVC. 2. Se falhar o envio, enviar para o Web Service que recepciona a NF-e/NFC-e