Italo Giurizzato Junior

Boa tarde, Tanto o cancelamento quanto o encerramento são eventos, sendo assim ao executar os comando sitados é para ser salvo em disco um XML com o seguinte nome: *-ped-eve.xml Esse XML contem o pedido de evento, ou seja, é o envio do evento a SEFAZ, como dito antes pode ser de um cancelamento ou encerramento. A SEFAZ por sua vez processa esse pedido e retorna o resultado desse processamento, que é salvo com o seguinte nome: *-eve.xml Por fim é gerado um terceiro arquivo chamado *-procEventoMDFe.xml que nada mais é do que o arquivo de distribuição, ou seja, ele possui tanto a solicitação bem como o resultado do processamento retornado pela SEFAZ, em resumo é a união dos dois primeiros. Após a execução dos comandos de cancelamento ou encerramento, é salvo os XMLs apresentados acima? Se sim, você poderia postar como anexo?

Boa tarde Marcio, Essa alteração foi feita por mim, a pedido de um colega do RS que utiliza uma aplicação desenvolvida por mim. O cliente dele necessita que a descrição seja: Atividades de pós-colheita. Infelizmente eu deveria ter desfeito essa alteração após compilar e enviar o executável a ele. E acabei enviando para o repositório o fonte alterado. Peço desculpas pelo transtorno. Vou corrigir e disponibilizar novamente. Aproveito para informar que o componente ACBrNFSe é capaz de imprimir no DANFSE a descrição do serviço de duas formas: 1. a descrição que consta no fonte do mesmo; 2. a descrição que consta em um arquivo TXT que deve ser copiado para a pasta onde encontra-se o executável. Existe uma propriedade no componente onde definimos se a descrição é de um arquivo externo ou não.

Boa tarde, Você esta incluindo em Uses a unit pcnConversao ?

Boa tarde Chistiano, Te aconselho a procurar um bom contator.

Boa tarde Thiago, Você sabe me dizer quando a versão muda de 3.10 para 2.00? A principio depois de setado a versão, ela não se altera a não ser que seja carregado um XML de uma NF-e que foi emitido na versão 2.00 Por favor verifique se o problema não é exatamente esse.

Boa tarde Leandro, Pelo o XML que você anexou se trata do provedor EL. Esse provedor já esta implementado, sendo assim, precisamos das URLs de homologação e de produção para a cidade Aracruz.

Boa tarde, Esse Pablo deve ser mestre em ábaco e não em computação. O camarada pede para se basear na documentação, como se trata de envio via Web Services, temos que nos basear no Schema_V3 conforme a resposta dele, pois bem veja a definição do tipo complexo chamado tcDadosServico: <xsd:complexType name="tcDadosServico"> <xsd:sequence> <xsd:element name="Valores" type="tcValores"/> <xsd:element name="ItemListaServico" type="tsItemListaServico"/> <xsd:element name="CodigoCnae" type="tsCodigoCnae" minOccurs="0"/> <xsd:element name="CodigoTributacaoMunicipio" type="tsCodigoTributacao" minOccurs="0"/> <xsd:element name="Discriminacao" type="tsDiscriminacao"/> <xsd:element name="CodigoMunicipio" type="tsCodigoMunicipioIbge"/> </xsd:sequence> </xsd:complexType> Bom, se não existe o campo CodigoCnae então o que esta definido acima? A não ser que esse tal de Mestre quer dizer que esse campo por ser opcional não deve ser informado apenas o CodigoTributacaoMunicipio. Outra coisa, se você analisar os exemplos vai notar que com exceção do envio os demais é utilizado antes da TAG os prefixos: ns2, ns4, ... ou seja segundo o que foi adotado pelo provedor Ginfes. No Ginfes o envio também se utiliza dos prefixos, sendo assim ou o exemplo esta errado ou o Ginfes esta aceitando o envio sem prefixo somente para a cidade de Fortaleza.

Boa tarde Pablo, No meu entendimento, você deve entrar em contato com o provedor e expor o problema. Pelo que entendi você só nota o erro se você pegar o XML de retorno e tentar validar o mesmo caso contrario ninguém nota o problema, correto?

Boa tarde Kleberson, Qual é a versão da NF-e que se deseja consultar? Se for versão 2.00 faça o seguinte: 1. Carregue o XML da NF-e 2.00 com o LoadFromFile; 2. Configure o componente para a versão 3.10 3. Execute o método Consultar.

Jakson, Isso significa que a versão do seu Quick Report é diferente da que foi utilizada para fazer o DAMDFe. Na pasta ...\Fontes\ACBrMDFe existe um arquivo TXT com um passo a passo que mostra como resolver esse problema.

Boa tarde Fabio, Faz o seguinte: Carregue o XML da NF-e versão 2.00 usando o LoadFromFile, depois configure o componente para a versão 3.10 e por fim realize a consulta.

Boa tarde Jeferson, Essas outras 3 lojas não são filiais? Não sei bem ao certo se o Token (CSC- Código de Segurança do Contribuinte) é atrelado ao CNPJ ou IE ou ambos. Se for atrelado somente ao CNPJ acredito que você possa usar o mesmo em todas elas.

Boa tarde Mauricio, Monte a sua rotina de CC-e igual a de Cancelamento. Lembre-se que CC-e e Cancelamento são eventos e temos uma rotina genérica para envio de eventos.

Boa tarde Tallys, O Schema não tem nada haver com a rejeição da SEFAZ. Se o Schema estiver errado o XML não é validado e consequentemente não é enviado para SEFAZ.

Boa tarde, Se o CT-e não tiver nada nesse campo, ele é autorizado?

Como assim duas vezes? Existe uma TAG para informar a chave da NF-e e a segunda chave que só é informada caso a NF-e tenha sido emitida em contingência. Essa TAG que se refere a segunda chave é a chave de contingência, portanto se a nota não foi emitida em contingência essa TAG tem que receber uma string vazia.

Boa tarde, Cuidado, existe o CNAE e o Código de Tributação do Município essas duas informações são especificas do município e da empresa em questão. No meu entendimento se 2304400 que foi informando como sendo o Código de tributação então qual é o correto? O CNAE que eu saiba é informado em outro lugar.

Boa tarde Victor, O componente não vai mais alterar o XML, ou seja, remover o protocolo de autorização pelo de cancelamento. No banco de dados você precisa ter um campo que indica se a nota foi cancelada ou não. Desta forma ao carregar o XML de uma NF-e você precisa consultar o banco de dados para saber se a mesma esta cancelada, veja este exemplo: // Carrega no Componente a NFe salvo em Arquivo XML ACBrNFe.NotasFiscais.Clear; ACBrNFe.NotasFiscais.LoadFromFile(NomeArquivo); // Imprime o DANFE ACBrNFeDANFeQR.NFeCancelada := (DM_VEN.NotasCancelado.AsString = 'S'); ACBrNFe.NotasFiscais.Imprimir; ACBrNFeDANFeQR.NFeCancelada := False; A linha em negrito é que onde eu checo se no registro da respectiva nota (banco de dados) a mesma consta como cancelada. Desta forma o DANFE será impresso com a tarja de cancelada.

Jackson, Se a empresa que vai emitir um MDF-e é uma transportadora, ou seja, emite CT-e devemos fazer desta forma: Ide.tpEmit := teTransportadora; Por outro lado se tratar de uma empresa que emite NF-e e vai realizar o transporte da própria carga, devemos fazer desta outra forma: Ide.tpEmit := teTranspCargaPropria; O tipo de emitente você deve ter atribuído teTransportadora e neste caso o componente não adiciona NF-e somente CT-e.

Boa tarde Isaque, O retorno para versão 2.00 ocorre se você executar um LoadFromFile de uma NF-e emitida na versão 2.00 Qual é a intensão de carregar uma NF-e da versão 2.00 novamente, enviar o XML por e-mail ou imprimir o seu DANFE, por exemplo.

Boa tarde Jakson, Você esta adicionando uma NF-e no MDF-e, mas o emitente deste é uma transportadora ou empresa emitente de NF-e que vai realizar o transporte? Exite uma propriedade onde você informa se o emitente é transportadora ou transportador de carga própria.

Boa tarde José Justino, Pela sua rotina, você esta configurando o componente para gerar NF-e versão 3.10, mas e depois? Depois de executar a procedure que alimenta o componente com os dados da venda, quais são os comando executados? Será que não tem nenhuma linha no meio desse caminho que esta alterado a versão para 2.00?

Boa tarde Michel, A NFC-e nada mais é uma NF-e com uma pequena alteração, em vez do código do modelo ser 55 é 65. Resumindo: NF-e => Modelo = 55 NFC-e => Modelo = 65 Sendo assim o XML são exatamente iguais e em ambos os casos o XML é considerado documento fiscal válido juridicamente se o mesmo for assinado com um certificado digital tipo A1 ou A3 (cartão ou token) mais o protocolo de autorização retornado pela SEFAZ-Autorizadora do Emitente da nota. Atenção o token que eu fiz referencia acima se refere ao certificado digital tipo A3 vendido em formato pen-drive (token). O DANFE da NF-e é impresso em papel A4, por outro lado o DANFE da NFC-e é impresso em bobina - impressora não fiscal. O DANFE da NF-e possui um código de barras que representa a chave de 44 dígitos. Por outro lado o DANFE da NFC-e não possui esse código de barras e sim um outro tipo de imagem chamado QR-Code. O QR-Code impresso no DANFE da NFC-e não representa a chave e sim uma URL (um endereço de internet) que nos retorna na tela do computador ou celular o DANFE completo da NFC-e. A URL do QR-Code é composta por uma dezena de informações, sendo que uma delas é o CSC - Codigo de Segurança do Contribuinte que no componente é chamado de Token. Por que no componente esta Token em vez de CSC, só para confundir os desenvolvedores, não. Nas primeiras documentações referentes ao QR-Code do DANFE da NFC-e o termo usado era Token, mas agora a documentação mais recente já faz referencia a CSC em vez de Token. Inclusive em breve será disponibilizado a todos os usuários do ACBr uma nova versão dos componentes e uma das alterações é justamente a palavra Token que foi substituída por CSC. Portanto se você ler algo sobre Token relacionado a QR-Code não se trata do certificado e sim o CSC que nada mais é do que um código alfa numérico. Espero ter ajudado.

Boa tarde, Já baixei os arquivos e vou verificar.

Boa tarde Antonio Paulo, No caso da NFC-e todos os dados do Destinatário são opcionais. Mas você pode apenas informar o CPF e deixar o nome em branco.