Italo Giurizzato Junior

Bom dia a todos, Devemos deixar claro uma coisa, principalmente no que diz respeito a Data. No manual e Nota Técnica diz que o conteúdo de uma TAG do tipo data a mesma tem que ter o seguinte formato AAAA-MM-DD. Muito bem esse é o formado que a data tem que aparecer no XML. É sabido que no Brasil, escrevemos a data no formato DD/MM/AAAA e configuramos o Windows para esse formato. Sendo assim ao gerar o arquivo texto devemos escrever a data conforme a configuração do Windows, pois o ACBrNFeMonitor ao ler essa informação se utiliza de uma função para converter o texto em data (lembre-se que é gerado um arquivo texto). Por que o monitor faz essa conversão em vez de simplesmente pegar a data colocado no arquivo texto passar para o XML? Simples realizando a conversão é possível detectar datas inválidas como por exemplo: 29 de fevereiro sendo que o ano não é bissexto. Desta forma evitamos o envio de uma nota para SEFAZ e a mesma ser rejeitada por data inválida. No Manual e Nota Técnica consta que uma TAG que recebe data e hora, no XML essa informação tem o seguinte formado: AAAA-MM-DDTHH:MM:SS Muito bem só que no arquivo texto temos uma formatação diferente: DD/MM/AAAA HH:MM:SS Volto a frisar que a data deve ser escrita segundo a configuração do Windows e devemos deixar um espaço em branco entre a data e a hora. Porque? A função utilizada para converter o texto que contem a data e hora assim exige, caso contrario ocorre erro na conversão. Os nomes dos campos do arquivo texto inicialmente não seguia a mesma nomenclatura do XML, os responsáveis pelo ACBrNFeMonitor estão se esforçando para fazer com que o mesmo possa interpretar ambas nomenclaturas, só que isso demanda tempo. Quando é dito seguir a ordem do manual, estamos dizendo que os campos no arquivo texto devem aparecer na mesma sequencia do XML, fazendo desta forma fica muito mais fácil saber se esta faltando algo ou não.

Bom dia Frits, Você leu a minha postagem #36?

Bom dia Wagner, Os produtos que você transporta são próprios? Você vende o produto e realiza o transporte do mesmo? Pela sua postagem a resposta para as duas perguntas acima é: Não. Você presta serviço de transporte para outra empresa, podemos então dizer que você é uma transportadora. Você disse informa no MDF-e as chaves dos CT-e, esses CT-e é você que emite, correto? Se sim, nesses CT-e você já informa a chave da NF-e emitida pelo seu cliente, portanto no MDF-e você só vai informar as chaves dos CT-e. No MDF-e que você emite só pode ser informado documento que você emite. Se você é uma transportadora, ou seja, presta serviço de transporte, você tem que emitir o CT-e para acobertar o transporte da carga, sendo assim ao emitir o MDF-e você só pode informar nele os CT-e que é o tipo de documento que você emite. Por outro lado se você vende os produtos e possui um caminhão para realizar o transporte, logo você realizar o transporte de carga própria, como você vende, logo você emiti NF-e, sendo assim, ao emitir o MDF-e você vai informar nele as NF-e, que é o tipo de documento que você emite. Em resumo, um MDF-e só pode ter uma lista de NF-e OU CT-e.

Bom dia, Vamos as falhas: 1. Ocorreu um erro na compilação do pacote ACBrSerial acusa que não encontrou o identificador WriteLog Me parece que existem postagens no fórum mostrando como resolver esse problema. 2. Ocorreu erro na compilação do pacote ACBr_NFe2 acusa que não encontrou os identificadores TpcnVersaoDF e ve200 Eles estão definidos na unit pcnConversao dentro da pasta ...\Fontes\PCN2 Verifique se esse fonte contem eles se sim, isso significa que o seu Delphi esta se utilizando de uma DCU antiga dessa Unit Você vai ter que vascular o HD em busca dessa DCU. Outra coisa que pode ajudar a resolver esse problema é que excluir todos os arquivo referentes ao ACBr que encontram-se dentro da pasta BPL do Delphi. 3. Ocorreu erro na compilação do pacote ACBr_CTe acusa que não encontrou vários identificadores. Todos eles também estão definidos em pcnConversao e a solução mencionada acima. 4. Ocorreu erro na compilação do pacote ACBr_MDFe acusa que não encontrou vários identificadores. Idem ao 3. 5. Ocorreu erro na compilação do pacote ACBrNFeDanfeQRpkg acusa que não encontrou o requisito QR5RunD7. Você utiliza o Delphi 7 e provavelmente não utiliza a versão 5 do Quick Report. Solução para o problema, abrir o pacote acima e trocar o QR5RunD7 por QRPT70 (caso você utilize o Quick Report que vem o D7). Não esqueça de abrir com o bloco de notas o arquivo ACB.inc que esta dentro da pasta ...\Fontes\ACBrComum para comentar a linha que defini a diretiva de compilação QReport_PDF, se não fizer isso terá mais problemas depois. Os demais erros são idênticos aos já mencionados, portanto a solução é a mesma.

Bom dia Rafael, Me responda uma coisa, para que você quer realizar o Download do XML sendo que o seu problema (pelo que entendi) é o protocolo de autorização? Se você enviou a NFC-e para SEFAZ isso significa que você tem o XML da NFC-e inclusive assinado, só esta faltando o protocolo de autorização, que não foi retornado por algum problema técnico, correto? Sendo assim basta você carregar o componente com o conteúdo do XML, através do comando LoadFromFile e em seguida executar o comando Consultar. O consultar, como o próprio nome diz realiza uma consulta a SEFAZ para saber a situação atual da NFC-e previamente carregada através do LoadFromFile. Se a mesma foi autorizada, o protocolo será retornado e o XML será atualizado, se tornando um documento válido juridicamente ( XML assinado e protocolado ).

Boa tarde, Pelo log de instalação, você selecionou tudo. Porque você não seleciona só o que realmente vai precisar? Outra coisa, você selecionou todos os tipos de DA - Documentos Auxiliares, você tem instalado no Delphi os Reports: Quick Report, Fast Report, Fortes Report, Rave e etc?

Boa tarde Eduardo, No caso da NFS-e não podemos montar uma rotina semelhante a da NF-e. Você deve alimentar o componente com os dados do RPS e em seguida executar o Enviar. Deixe que o componente se encarregue de fazer o resto. Só para você ter uma ideia, no caso da NF-e efetuamos a validação de cada nota que vai fazer parte do lote, por outro lado na NFS-e, realizamos a validação do lote de RPS e não de cada RPS.

jGuto, O XML que você postou se refere ao provedor Fiorilli, correto? Conferindo o XML com a Unit pnfsNFSeR.pas é para ele ler sim o valor liquido que encontra-se dentro do grupo ValoresNfse. O provedor Fiorilli se utiliza da Function LerNFSe_ABRASF_V2 e esta logo nas sua primeiras linhas lê o grupo ValoresNfse e consequentemente a TAG ValorLiquidoNfse.

jGuto, A alteração que mencionei, verifica se o valor liquido da NFSe é zero, se sim ele calcula.

Darlana, Vamos arriscar, configure o componente para o ambiente de produção e realize a consulta - NFeDistribuicaoDFe.

Desculpa, Juliomar removi o seu anexo e coloquei o meu. Pelo log de erro, notei que os fontes estão desatualizados.

Boa tarde Herbert, Não esqueci, apenas quero fazer mais algumas checagens sobre o assunto do Valor ISS retido e Valor ISS.

Boa tarde Isaac, O que você quer dizer com "Download do XML"? Seria baixar o XML da SEFAZ? Se sim, eu já respondi que o Emitente tem a obrigação legal de ter o XML e guarda-lo pelo período legal. Por outro lado o Destinatário tem a possibilidade de realizar o Download do XML de uma NF-e da SEFAZ desde que realize a manifestação da mesma. Mas esse Download deve ser utilizado em último caso, pois o Emitente tem a obrigação legal de disponibilizar imediatamente ao Destinatário o XML da NF-e assinado e protocolado assim que obter da SEFAZ o protocolo de autorização da mesma. E o Destinatário tem a obrigação legal de ter o XML e guarda-lo pelo período legal. Quando digo que tem a obrigação legal, significa que consta na legislação e ela deve ser comprida. Volto a afirmar, se uma NF-e contem uma CC-e por exemplo o emitente da NF-e tem o XML da NF-e (<chave>-nfe.XML) bem como o XML da CC-e processado pela SEFAZ (<chave><tpEvento><nSeqEvento>-procEventoNFe.XML) Se a Nota e os eventos são emitidos por outra aplicação que não seja a sua, o que você precisa verificar é como age a outra aplicação, ou seja, se ela salva os XML em disco, se sim, onde, por outro lado se armazena no banco de dados, em qual tabela e campo. O que o emitente de uma NF-e pode fazer é consultar a situação atual de uma nota, neste caso a SEFAZ retorna o protocolo de autorização ou de cancelamento, bem como todos os eventos vinculados a mesma.

Boa tarde jGuto, Foi feita algumas alterações na unit que lê o XML recentemente, você esta com os fontes atualizados?

Boa tarde Darlana, Como a consulta foi realizada em ambiente de homologação é de se esperar esse tipo de resultado. Estava previsto a liberação do ambiente de produção para o dia 06/10/2014 que por sinal ainda não ocorreu. Acredito que em virtude também do atraso na liberação do ambiente de homologação. Espero que semana vem já esteja liberado e assim seja possível efetuar essa consulta no ambiente de produção, onde com certeza vai constar NF-e e eventos para serem retornados. Volto a frisar que um dos dois últimos parâmetros tem que ser uma string vazia. ACBrNFe1.DistribuicaoDFe(FrmPrincipal.BuscarCodigoCidadeUF('',lcUFAutor),CNPJ, gcUltimoNSU, gcAtualNSU); gcUltimoNSU diferente de vazio faz a consulta com base no último NSU (algom semelhante a Consulta de NFe Destinadas) gcAtualNSU diferente de vazio consulta se existe nota referente ao NSU informado. Nota Técnica 2014/002 versão 1.01 - página 5 temos: ultNSU - Último NSU recebido pelo ator (destinatário por exemplo). Caso seja informado com zero, ou com um NSU muito antigo, a consulta retornará unicamente as informações resumidas e documentos fiscais eletrônicos que tenham sido recepcionados pelo Ambiente Nacional nos últimos 3 meses. NSU - Número Sequencial Único. Geralmente esta consulta será utilizada quando identificado pelo interessado um NSU faltante. O Web Service retornará o documento ou informará que o NSU não existe no Ambiente Nacional. Assim, esta consulta fechará a lacuna do NSU identificado como faltante.

Boa tarde, Você esta compilando o componente para ser usado com o OpenSSL ou Capicom. A propriedade NumeroSerie só esta disponível para a compilação - Capicom.

Bom dia Isaac, Desculpe, não entendi, "caso aconteça algum ???? de retorno e precise fazer o download do XML" O emitente não precisa fazer download do XML ele tem que possui o XML e guarda-lo pelo tempo legal. É o emitente que gera, assina e envia o XML para SEFAZ, portanto ele tem que ter o XML da NF-e. Se o XML vai ser salvo em disco ou será armazenado no banco de dados, não importa ele tem que ter o XML da NF-e, bem como de todos os eventos que ele envia para SEFAZ referente a NF-e previamente enviada e autorizada.

Bom dia, Ocorre algum erro ou simplesmente a propriedade fica vazia?

Bom dia Edilson, Duas considerações: 1. O seu fonte no que diz respeito ao DANFE esta desatualizado, um outro colega do fórum alterou os campos que mostravam do consumidor, foi alterado de QRLabel para QRMemo. 2. O parâmetro "Via" você definiu como sendo string, o que você acha de definir como Boolean com valor padrão True, neste caso será impresso o texto "Via Consumidor", se False, imprime "Via Estabelecimento"?

Bom dia, Primeiramente, por favor evite ao máximo em postar o conteúdo de um arquivo, procure sempre anexar o mesmo. Fiz algumas correções no fragmento que você posto. Ele esta em anexo. Correcao.txt

Bom dia Paulo, Primeiramente, o minha postagem se refere a impressão bem como a geração do PDF no que diz respeito a Inutilização de numeração de CT-e. A implementação foi realizada no componente ACBrCTe, apesar do ACBrNFeMonitor se utilizar do componente, isso não significa que é possível imprimir ou gerar o PDF usando o monitor. É necessário que seja implementado um comando no monitor para usufruir das funcionalidades do componente. A sua pergunta se refere ao monitor e mais precisamente a NF-e, pois bem, foi implementado também no componente ACBrNFe (utilizado pelo monitor) as funcionalidades de impressão e geração do PDF referente a inutilização de numeração. Da mesma forma, enquanto não for implementado um comando no monitor não será possível utilizar essas funcionalidades.

Bom dia, O campo placa faz parte do grupo veicTransp, faz parte deste grupo também os campos UF e RNTC sendo que UF também é obrigatório se você estiver informado a UF e ou o RNTC o grupo veicTransp vai ser gerado e consequentemente será necessário a placa, uma vez que esta é obrigatória. Portanto reveja o seu arquivo, para que o mesmo não tenha os campos placa, UF e RNTC do veicTransp.

Bom dia Ricardo, Primeiramente, você utiliza o componente ACBrNFe? Se sim, por favor leia a Nota Técnica 2012/002 versão 1.02 que trata sobre o assunto Manifestação do Destinatário, nessa NT você vai encontrar tudo sobre o Download. Se não utiliza e a sua intenção é apenas realizar o Download para agilizar o processo de entrada da nota, você pode utilizar o componente ACBrNFe para resolver esse problema, mas por favor leia a Nota Técnica.

Bom dia Herivelton, Desculpe, fiz confusão, os grupos infCTeNorm, infCteComp e infCteAnu estão no mesmo nível e são CG, ou seja, devemos escolher somente um deles para aparecer no XML. Por outro lado o infDoc que antes ficava dentro do grupo rem agora esta dentro do grupo infCTeNorm. Sendo assim, se você vai emitir um CT-e de Complementação não será possível informar o documento que originou o primeiro CT-e a ser complementado. Confundi com o infCTeSub que também esta no mesmo nível do infDoc e ambos dentro do grupo infCTeNorm. Resumindo: O grupo infDoc só poderá ser informado quando o CT-e for Normal ou de Substituição e não será informado quando for de Complementação ou de Anulação.

Boa tarde Diogo, Pergunta para o pessoal do provedor se o Web Services deles é possível ser consumido utilizando um certificado vencido? Até onde sei, não é possível consumir um Web Services com certificado vencido. Se a resposta for não, ou seja, não é possível consumir, então como o lote foi enviado e o Web Service foi consumido a ponto de processar a mensagem e retornar a rejeição?