Italo Giurizzato Junior

Boa tarde ALA, Peça ao seu cliente um documento publicado pela SEFAZ que trata sobre esse assunto. Se ele disse que o vizinho dele que emite NF-e faz o cancelamento extemporâneo, ai você diz: NF-e é uma coisa, CT-e é outra. Se não me falha a memória o cancelamento extemporâneo pode ser adotado ou não pela SEFAZ-Autorizadora, sendo assim pode ser possível em um Estado e não em outro.

Boa tarde Thiago, Nesse Refactoring um dos objetivos é a diminuição de linhas código. No caso do ACBrNFSe existem uma meia duzia de métodos que nos retorna o XML da NFS-e, a minha ideia é termos apenas uma fuction ou procedure com o código e os métodos chamariam essa function ou procedure, mas ainda não cheguei em uma solução elegante para esse problema.

Boa tarde Emerson, Acredito que não, mas se desejar pode contribuir desenvolvendo.

Boa tarde Fabio, Acredito que sim, na minha aplicação alem de colocar em um Data Module, não permite que dois ou mais form sejam abertos ao mesmo tempo da mesma aplicação.

Boa tarde a todos, A noite vou dar uma olhada no tipo TpcnTipoCTe, mas acredito que ele não é utilizado na geração do XML do CT-e.

Boa tarde, Algumas coisas ainda precisam ser corrigidas, estamos trabalhando nessas correções.

Boa tarde, Se você abrir o ACBrMDFe-change-log.txt você vai encontrar: 01/05/2015 [*] Atualização das URLs de produção e homologação do MDF-e publicadas pela SEFAZ-RS. por: Italo Jurisato Junior Acredito que isso responde a sua pergunta.

Boa tarde Marcelo, Esse questionamento já respondi hoje de manhã e a resposta é não.

Fabio, Se você recebe XML de NF-e com o protocolo de cancelamento em vez de Autorizado esta errado. Pois em nenhum manual ou nota técnica diz que o XML da NF-e tem que ser alterado, ou seja, remover o protocolo de autorização e colocar o de cancelamento quando a NF-e for cancelada. O que existe é que devemos disponibilizar ao cliente o arquivo *-procEventoNFe.xml, pois este arquivo contem a solicitação de cancelamento e o protocolo do mesmo retornado pela SEFAZ.

Bom dia, Você esta anexando o mesmo? Note que o método EnviarEmailEvento possui um parâmetro para que possamos anexar o XML.

O que esta no repositório Trunk.

Bom dia Fabio, Porque você não coloca os componentes ACBrCTe e ACBrDACTeFR em um Data Module?

Bom dia Cristian, Pela sua postagem creio que você se refere ao componente ACBrNFSe que esta no Trunk2. Sim, os provedores terão um arquivo INI para cada um. Mas o componente não esta funcionando, quando terminarmos todos serão avisados.

Bom dia Wilson, Exatamente, essa é a alteração que estou sugerindo que seja feita, no IF em vez de checar o valor de Arquivos.Salvar, checar o valor de Geral.Salvar. Essa procedure SalvarEnvio, é responsável por salvar os XML de envio para a SEFAZ, que pode ser um evento, uma consulta entre outros. Fazendo essa alteração podemos determinar se desejamos ou não se esses tipos de arquivos sejam salvos ou não em disco. Por outro lado os arquivos de validade jurídica, como o XML da NF-e assinado e protocolado, mais os XMLs de *-procEventoNFe.xml e *-procInutNFe.xml seriam salvos em disco ou não mediante o valor da propriedade Arquivos.Salvar. No meu entendimento devemos conceituar: Geral.Salvar -> salva ou não arquivos gerais, ou seja, arquivos de envio e de retorno da SEFAZ. Arquivos.Salvar -> salva ou não arquivos com validade jurídica. WebServices.Salvar -> salva ou não arquivos gerais mas de forma completa ou seja com as TAGs de envelopamento.

Bom dia, Sim, existi o componente chamado: ACBrNFeDANFeESCPOS ele tem essa finalidade.

Bom dia Graça, Já respondido no outro tópico.

Bom dia Graça, Ao configurar o componente atribua o valor tiNFCe a propriedade TipoDANFE do componente ACBrNFeDANFeQR. Desta forma ele entende que o DANFE tem que ser impresso conforme o layout do DANFE NFC-e e pressupõe que a impressora seja uma de bobina. Ou atribua o valor tiNFCeA4 para configurar o mesmo para imprimir em uma impressora laser usando papel A4.

Não existe mais o tipo de emissão Contingência para a NFC-e. Por favor leia a Nota Técnica 2015/002 -página 3 deixa claro isso. Observação: Para a NFC-e somente é válida a opção de contingência: 9-Contingência Off-Line e, a critério da UF, opção 4-Contingência EPEC.

Boa tarde Reinaldo, Muito obrigado, realmente tinha esquecido, correção feita e já esta disponível.

Boa tarde Douglas, Você esta usando os fontes do Trunk2? Se sim, todos eles estão atualizados?

Boa tarde Fabio, O CT-e realmente esta sendo autorizado? Será que ele não foi rejeitado? Post como anexo o arquivo *-pro-rec.xml

Boa tarde, Se a nota for rejeitada, isso significa que a mesma contem dados errados, portanto deve-se fazer a correção e enviar novamente, neste caso não se altera nada no que diz respeito a FormaEmissao ou tpEmis. Por outro lado se ocorrer problema com a Internet você deve atribuir o valor teOffLine para ambos (FormaEmissao e tpEmis) gerar novamente o XML, assina, valida e imprimir o DANFE em duas vias, sendo uma para o consumidor e outra fica no estabelecimento comercial. Quando os problemas forem sanados altere apenas a FormaEmissao para teNormal e envie todas as notas emitidas em OffLine. As novas notas tem que estar com o tpEmis com o valor teNormal.

Boa tarde Fabio, O componente ACBrCTe tem o mesmo comportamento que o ACBrNFe, como o Juliomar disse o cancelamento é um evento vinculado ao documento fiscal, logo não se deve altera-lo, por conta do cancelamento.

Bom dia Cristiano, Favor configurar o componente para salvar os arquivos soap. Configuracoes.WebServices.Salvar := True; Repita os testes. Post como anexo os arquivos de envio e de retorno que contem a palavra soap no nome dos mesmos.

Bom dia Reinaldo, Se você não utiliza o ACBrNFSe e ACBrGNRE, sugiro que migre o mais rápido possível para o Trunk2. Respondendo a sua pergunta, sim, estamos aposentando o Trunk.