Italo Giurizzato Junior

José, Como você utiliza o ACBrNFeMonitor acredito que não tem como. Para quem desenvolve em Delphi temos o componente ACBrMail, com ele podemos anexar quantos XML desejarmos e enviar.

Boa tarde José, Eu não utilizo o ACBrNFeMonitor e nem participei do seu desenvolvimento, essas respostas vou lhe ficar devendo.

Boa tarde Allan, Como dito no que se refere a evento no ACBrNFe tudo é feito pela mesma rotina. Se o cancelamento foi protocolado pela SEFAZ, o que pode ser: 1. Quando você emitiu a CC-e a SEFAZ estava com algum problema e retornou aquela rejeição e agora esse problema foi sanado. 2. ou na verdade o erro é outro, mas a SEFAZ retornou que o erro era na assinatura. 3. ou a SEFAZ esta com algum erro ao tratar o evento CC-e.

Boa tarde Henrique, A carta de correção é um evento, e o envio de evento por e-mail já foi implementado.

Verifique se no Library Path do Delphi a pasta ...\Fontes\ACBrCapicom vem antes de ...\Fontes\ACBrDFe.

Boa tarde, O programa exemplo do ACBrCTe ainda esta com o DACTE feito em Quick Report, dai o erro.

Bom dia Rodrigo, A function SituacaoNFeToStr mudou de nome, agora ela se chama: SituacaoDFeToStr.

Bom dia Jairo, A SEFAZ criou um Web Services chamando DistribuicaoDFe para que possamos obter em um primeiro momento um resumo da NF-e e se efetuarmos a manifestação do destinatário teremos em uma nova consulta o XML completo da NF-e. Algo semelhante a SEFAZ criou um Web Services também chamado DistribuicaoDFe mas para o MDF-e - Manifesto Eletrônico de Documentos Fiscais que estará se não me falha a memória em outubro deste ano. Acredito que a SEFAZ irá criar também um DistribuicaoDFe para o CT-e, vamos aguardar. Desconfio que a Nota Técnica sobre esse Web Services seja a de numero 2, note que no Portal Nacional do CT-e temos a Nota Técnica 2015/001 e a 2015/003 esta faltando a de numero 002, estranho você não acha? Agora me diz, você quer baixar o XML para resolver o problema de quem, do emitente do CT-e ou do tomador do serviço? Se for do emitente, lembre-se que você pode gerar e assinar novamente o CT-e tomando o cuidado de gerar com a mesma chave e depois com o componente carregado com o respectivo XML, basta executar o método Consultar, este vai buscar a situação atual do CT-e e vai atualizar o XML acrescentando ao mesmo o protocolo de autorização. Espero ter ajudado.

Bom dia Rodrigo, Analisando o seu XML de CC-e notei erro de conceito e de preenchimento. Conceito: o campo nroItemAlterado só deve ser informado quando a informação ser alterada pertence a uma lista e neste caso você informa a posição dentro dessa lista. Exemplo: Motorista, podemos informar o nome e o CPF de um ou mais motoristas, suponha que foi informado 3 motoristas e o nome do segundo esta errado e você deseja efetuar a correção através da CC-e. Como alimentar os campos da CC-e: grupoAlterado = moto campoAlterado = xNome valorAlterado = <informar aqui o nome correto do motorista> nroItemAlterado = 2 Como é o segundo nome da lista que esta errado foi informado a posição 2 ao campo nroItemAlterado. Preenchimento: se você abrir através de um navegar o arquivo 0-ped-eve-soap.xml vai notar que o campo: valorAlterado esta vazio, ou seja você não esta informando o novo valor do campo alterado. Outra coisa o nome do grupo e do campo tem que seguir a nomenclatura do XML, sendo assim esta errado informar: Ide o correto é ide (tudo em minusculo). Faça as devidas correções e tente novamente.

Bom dia, Qual ambiente, homologação ou produção? Você esta usando os fontes do Trunk ou Trunk2? Checou a validade do certificado?

Bom dia José, Maravilha, estamos aqui para ajudar.

Bom dia Allan, E o cancelamento esta funcionando? Lhe pergunto isso, pois tanto a CC-e quanto o cancelamento são eventos e são gerados assinados e enviados pela mesma rotina.

Bom dia Daniel, As imagens com erros nos navegadores ao tentar abrir um XML é clássico, basta procurar cedilha ou vogais acentuadas e fazer a troca. Pronto esse problema desaparece. No meu entendimento devemos ter uma propriedade que substitua esses caracteres, por exemplo cedilha por "C". Para aqueles desenvolvedores cuja aplicação apresenta o conteúdo do XML de retorno para o usuário ver, ativaria essa propriedade, desta forma o componente ao obter o XML de retorno aplicaria esse filtro, inclusive o XML seria salvo com os caracteres trocados. Hoje temos uma propriedade que faz esse serviço quando gera o XML, a ideia e ter uma outra para o retorno, ou utilizar a mesma.

Bom dia Rodrigo, No que diz respeito a CC-e sugiro você utiliza: DM.ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.xmotivo pelo simples fato da CC-e ser um evento. O método SaveToFile agora se chama GravarXML. Você concorda, se esta correto ou não, se você fizer a alteração e testar?

Bom dia José, No seu TXT esta assim: DETEVENTO001] grupoAlterado=ide campoAlterado=CFOP valorAlterado=- CFOP do Conhecimento- 5.353 nroItemAlterado=1 xCondUso=A Carta .... Altere para: [DETEVENTO001] grupoAlterado=ide campoAlterado=CFOP valorAlterado=5353 nroItemAlterado=1 xCondUso=A Carta ... <=== remova essa linha o componente se encarrega de colocar o texto correto.

Bom dia Arnaldo, O MDF-e foi criado para facilitar a fiscalização entre as fronteiras entre um Estado e outro e quando a carga é fracionada. Sendo assim se a carga é fracionada temos vários destinatários logo a quantidade de notas é duas ou mais, pelo menos uma nota para cada destinatário. A emissão de MDF-e quando o transporte for realizado dentro do Estado só é obrigatória quando houver uma legislação complementar. Respondendo as sua perguntas: 1 - A emissão do MDF-e é por conta da empresa que vai transportar a carga, que no seu caso é a industria. 2 - Não faz sentido emitir um MDF-e só por causa de uma nota, lembre-se que ele é obrigatório para carga fracionada, portanto 2 ou mais notas, a ideia é relacionar no MDF-e todas as notas referentes a carga. Como dito o MDF-e é para facilitar a fiscalização, em vez do fiscal ficar checando a validade de dezenas de notas, checa apenas a validade do MDF-e. 3 - Sugiro que leia o Ajuste SINIEF 21 de 10 de dezembro de 2010: http://www1.fazenda.gov.br/confaz/confaz/ajustes/2010/aj_021_10.htm Quanto ao RNTRC e CIOT ambos são opcionais portanto não precisa ser informado, mas se informar que o veículo não é da empresa, ai vai ter que informar quem é o proprietário do mesmo e neste caso temos que informar o RNTRC do proprietário. Atenção o MDF-e possui três campos RNTRC, um se refere a empresa e os outros dois se refere ao proprietário, o que se refere a empresa que é opcional. Para ficar mais claro, leia a Nota Técnica 2014/003 - página 9, o campo 2 é o RNTRC da empresa, o campo 13 é o RNTRC do proprietário do veículo tração e o 33 é o RNTRC do proprietário do veículo Reboque.

Boa tarde, Te aconselho a utilizar as propriedades XMLAssinado ou XMLOriginal. Se XMLAssinado estiver vazio significa que o mesmo ainda não foi assinado. Se XMLOriginal estiver vazio significa que o XML ainda não foi gerado.

Boa tarde a todos, Roberto, você só esqueceu que segundo a legislação o emitente de uma NF-e assim que obtêm o protocolo de autorização tem por obrigação disponibilizar o arquivo XML assinado e protocolado para o destinatário da mercadoria e se a mesma for transportada por uma transportadora esta também tem o direito de receber uma cópia do XML. A forma mais simples de disponibilizar um arquivo é o envio do mesmo por e-mail. Se todos os emitentes utilizassem ou desenvolvessem sistemas em conformidade com a legislação, o destinatário da mercadoria ou a transportadora não precisariam buscar uma solução seja legal como o Download através do web services disponibilizado pela SEFAZ ou outra que é bem melhor não relatar, para conseguir o XML da NF-e, mesmo que seja simplesmente para dar entrada no estoque. Eu atribuo todo esse mau estar aos desenvolvedores de sistemas que fazem as coisas pela metade. Me desculpa, mas um sistema de emissão de NF-e que não lhe permite o envio automático por e-mail do XML assinado e protocolado as pessoas interessadas, não é um sistema digno e não merece crédito.

Bom dia Evandro, As alterações no ACBrNFe que andei realizando é somente no Trunk2.

Rodrigo, Não tenho conhecimento sobre o Fortes e Fast Report somente em Quick Report, portanto vou ficar lhe devendo uma resposta.

Fabio, Alterei o tipo do campo nItemPed de Integer para String. Fiz isso não por causa de algumas empresas quererem colocar zeros a esquerda, mas sim pelo fato desse campo ser numérico e ter tamanho fixo igual a 6, conforme consta na Nota Técnica 2013/005 versão 1.22 página 57.

Bom dia Rômulo, Segundo a NT o destinatário deve realizar a manifestação para poder depois receber o XML completo da Nota caso contrario terá que se contentar com o resumo da mesma. Acredito eu que o resumo ou o evento de cancelamento/CC-e não deveria estar vinculado a manifestação do destinatário, este deveria receber caso o emitente viesse a cancelar a nota ou realizar alguma alteração (CC-e). Concluo que a SEFAZ não esteja fazendo tudo o que prometeu, sendo assim cabe entrar em contato e pedir explicação e uma solução para o problema. No que diz respeito ao resumo da NF-e, no meu entendimento esta correto constar que a mesma foi autorizada. Mas não esta correto deixar de gerar um resumo pelo menos do evento de cancelamento da mesma.

Dércio, Também concordo, mas o espaço é pouco para mais duas colunas, o tamanho da fonte é definida pela SEFAZ e se diminuir vai ficar fora no estabelecido e vai ter aquele cliente que vai pedir para aumentar o tamanho da fonte pois não da para ler.

Bom dia Felipe, Não é assim que uma aplicação deve funcionar. Quando você envia uma Nota a SEFAZ esta retorna a data e hora que a mesma foi autorizada, essa informação esta junto com o numero do protocolo. Você tem que pegar essa informação e salvar no banco de dados juntamente com o numero de protocolo de autorização. O form de cancelamento tem que apresentar uma lista de notas possíveis de serem canceladas, ou seja, nessa lista só devem aparecer as notas cujo tempo decorrido entre a data/hora de autorização e data/hora do relógio da maquina seja inferior a 24 horas. Vamos a um exemplo, agora é 15/09/2015 09:51 as notas emitidas depois de 14/09/2015 09:51 são passiveis de serem canceladas, portanto devem aparecer na lista por outro lado as notas emitidas antes de 14/09/2015 09:51 não devem aparecer, pelo simples fato de o tempo decorrido ser maior que 24 horas. Desta forma toda nota cancelada vai estar dentro do prazo e se a nota não for cancelada significa que: 1. A transportadora emitiu um CT-e e relacionou essa nota; =====> Neste caso a transportadora deverá cancelar o CT-e para que você possa cancelar a NF-e. 2. O destinatário emitiu um evento de Manifestação do tipo: Ciência da Operação. =====> Neste caso o destinatário deverá emitir um novo evento do tipo: Desconhecimento da Operação para que você possa cancelar a NF-e.

Bom dia Paulo, Sendo assim, teremos que mudar o tipo de Integer para String. Muito obrigado pela informação, já fiz a alteração e já encontra-se disponível no svn. Para quem utiliza o Monitor deverá aguardar a próxima compilação.