Painel de líderes

Paraná não vai validar o ICMS Desonerado. vide link : http://www.fazenda.pr.gov.br/modules/noticias/article.php?storyid=987&tit=NF-e-e-NFC-e-Codigo-de-Beneficio-Fiscal

Boa tarde. Segue definição do estado de Minas Gerais quanto as regras a critério da UF. http://www.sped.fazenda.mg.gov.br/spedmg/noticias/Disponibilizado-consulta-regras-2019.001/

Boa tarde Amigo, Sem problemas, vai conseguir emitir em MG sem problemas, a NFE é padrão no brasil inteiro. Depedendo do estado pode ser que precise de algum ajuste, tenho cliente em MG e não tive de mudar nada, acho que por enquanto foi só no BA que tive de ver uma questa no CNPJ do contador no xml.

Boa tarde, Everton Alves Totta. Basta você seguir o layout do banco, porém segue o arquivo para que você possa estudar. Lembrando que é só um exemplo, o mesmo não está completo. Você pode utilizar o demo na pasta exemplos para auxiliar na implementação. CB180702.REM

Boa tarde, conforme o colega comentou acima, os CTe OS são retornados em conjunto com os CTe. Após os meus testes (e após a atualização do meu ACBr) consegui recuperar os CTe OS também. Obrigado, problema resolvido.

maravilha!!! deu certo, obrigado pela ajuda de sempre

Bom dia Paulo, Certificado A3 (Cartão ou Token) é problemático, na medida do possível procure sempre orientar os seus clientes a comprarem o certificado A1. Apesar do prazo de validade ser apenas de 1 ano, mas as vantagens são maiores e não costumam dar dor de cabeça.

Obrigado a todos pela ajuda. Resolvi utilizando dados de um cliente para testes. Realmente no RJ não aceitam mais emissão de NFC-e / NF-e sem uma IE ativa. A título de informação as NFC-es são geradas como "Inválidas". As NF-es saem como "Denegadas", porém é aceito o cancelamento da mesma em homologação. Provavelmente também impedirão o cancelamento destas em breve. A explicação "deles" é que este procedimento foi adotado para não sobrecarregar os servidores, uma vez que a IE está inativa e as transações das mesmas não serão aceitas, então bloqueiam antes que o documento seja processado. Só não entendi o porque do precedimento em homologação. Como sempre o governo faz as coisas sem pensar em quem está do outro lado, quem consume os seus serviços, NÓS.

Bom dia Juliana! Na verdade foi que eu estava enviando a mesma numeração de CT-e(foi um erro meu de backup) e por isto estava ocorrendo este problema. Não tinha nada a ver com os schemas e o ACBr. Rafael

Bom dia a todos, 26/08/2019 Implanta a versão 3.00a do CT-e em Produção A Versão 3.00a do CT-e foi implantada em produção na SVRS, inclusive com os novos eventos de Comprovante de Entrega e Cancelamento do Comprovante de Entrega. Agora no que diz respeito as demais SEFAZ-Autorizadoras de CT-e a historia é outra. A principio a partir da data de hoje (26/08/2019) todas as SEFAZ-Autorizadoras deveriam a passar a autorizar os CT-e na versão 3.00a. Se não esta autorizando, ou seja, esta retornando rejeição isso significa que a SEFAZ não fez o dever de casa. Neste caso a minha sugestão é que entre em contato com a SEFAZ e peça uma posição da mesma.

Obrigado Felipe! Vou atualizar aqui.

Boa tarde, Everton! Sim, os CT-es OS são retornados juntamente com os CT-es no método DistribuicaoDFePorUltNSU. Você deve verificar se o schema do documento retornado é igual a schprocCTeOS. Atenciosamente, Allan

da uma olhada nesses links: https://youtu.be/nsYvgmQlT58 https://github.com/tdevrocks/qrcode https://blog.andreamagni.eu/2017/06/scannermapp-a-qrbarcode-scanner-app-with-delphi-zxing-and-tframestand/

Seguem... ACBrBoletoFCFortesFr.pas ACBrBoletoFCFortesFr.dfm ACBrBoleto.pas

Boa tarde. Realmente, oque vai importar na hora do pagamento é o código de barras ou linha digitável, se os apps conseguem ler já resolve o problema do cliente. Estou incluindo para validação. Att.

Obrigado pela resposta... Vou fazer alguns testes em homologação.

Boa tarde Pedro, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Douglas, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde José, Que eu saiba o provedor Ginfes não tem o serviço de substituição, pelo fato do provedor seguir a versão 1 da ABRASF.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Se quer baixar as tabelas, veja o componente ACBrSpedTabelas.

Bom dia, Todo MDF-e precisa ser cancelado ou encerrado. Só podemos cancelar um MDF-e caso o transporte não tenha sido realizado. Logo não é o caso, uma vez que o transporte da carga teve inicio, mas infelizmente não chegou ao seu destino. Já o Encerramento de um MDF-e não significa que a carga foi entregue. Pois devemos encerrar um MDF-e quando ocorre mudanças, como por exemplo, acréscimos ou retirada de mercadorias da carga original, mudança de caminhão, ou mudança de motorista. Que eu saiba não existe um evento emitido pela transportadora que diz que ocorreu um sinistro e que a carga não chegou ao seu destino.

Bom dia Maikon, Se for gerado o grupo <infResp> devemos informar o respSeg e o CNPJ ou CPF do responsável. Outra coisa. Pela imagem de erro, ocorreu um erro de validação e não uma rejeição por parte da SEFAZ. O seu MDF-e nem sequer foi enviado, pois o componente detectou erro na geração do XML.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia, Veja a segunda postagem desse artigo: Evento de comprovante de entrega.

Bom dia. Este layout foi homologado pelo banco? Pode anexar um exemplo? Att.

Bom dia. Seria interessante informar também como foi feita a correção, para que outros usuários com uma situação semelhante possam resolver da mesma forma. Att.

Bom dia. O ideal seria falar com o escritório contábil de seu cliente. Att.

Bom dia Tiago, Então quer dizer que o envio esta normal, o problema esta na consulta. A cidade em questão se utiliza do provedor WebIss ou WebIssv2?

Bom dia. Seu problema não tem relação com este tópico? Att.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia, Artulanez Souza. Somente pela chave da NF-e ou pelo NSU.

Bom dia Michel, A principio o XML do MDF-e não pode ter o seu protocolo de autorização alterado pelo de cancelado ou encerrado. Se ele esta trocando o protocolo de autorizado pelo de encerrado e ou cancelado esta errado. Favor anexar o XML de um MDF-e com o protocolo de autorizado e o XML do mesmo MDF-e após ter sido cancelado ou encerrado. Quero analisar o problema e fazer os ajustes necessário.

vou verificar um meio de colocar um log e retorno aqui, por enquanto obrigado.

Eles estão usando pipe para separar a quebra de linha da descrição do serviço , basta arrumar no componente esse configuração no arquivo ini

Se o Hub não tiver alimentação na tomada ele roubara ainda mais amperagem...

Obrigado pela ajuda.

Você tem muitos dispositivos conectados nas portas USB ? Se SIM, isso pode estar dividindo a amperagem total da porta USB, o que pode causar problemas de mal funcionamento do SAT

3.1 - Não faça flooding - Inundar o fórum com posts repetidos, com a mesma dúvida ou as mesmas palavras é chamado de flooding. Isso é proibido. Apenas um post feito no lugar certo é suficiente. Pesquise antes de postar, talvez sua dúvida já está respondida em outro post. Favor leia as regras do fórum.

ok, Obrigado

Bom dia, Confesso que não me sinto qualificado pra gerar fontes tão bem feitos e bem trabalhados quanto os que vejo aqui, de qualquer forma fica a sugestão. E aproveito para deixar meus sinceros agradecimentos à esta atualização que deixou o relatório muito funcional parabéns. Eu resolvi meu problema gerando um relatório à parte contendo a continuação do estrato.

Nesse caso você precisa entrar em contato com o banco para saber a situação das remessas enviadas, ou orientação de como obter o retorno delas. Muito estranho... cada banco tem suas regras, o SICOOB não deveria validar um arquivo de remessa do Banco do Brasil.

Não precisa se preocupar com o formato de gravação no XML, isso o ACBr faz. Basta informar um valor TDateTime normal. Ex: infEvento.detEvento.dhEntrega := Now; infEvento.detEvento.dhEntrega := MeuDataSet.FieldByName('DATA_HORA_ENTREGA').AsDateTime; InfEvento.detEvento.dhEntrega := EncodeDate(2019, 08, 23) + EncodeTime(17, 45, 00, 000);

Obrigado pela resposta. Estou setando sempre p produção, mas esta ocorrendo erro de schema. Acho que o problema esta pq so vai entrar em produção dia 26/08. Vou aguardar..

Enviei atualização de Schemas para o repositório, favor atualizar os fontes.

Mediante ao que você disse, acredito que o problema está no certificado.

Boa tarde, comigo deu certo, conforme explicações do BigWings. Fiz conforme abaixo, ou seja, adicionei os dois campos dentro da seção Produto001: [Produto001] CFOP=5202 Codigo=31 . . . pDevol=100.00 vIPIDevol=30.00

Boa tarde a todos, Para quem utiliza o componente ACBrCTe e estava com dificuldades de gerar o Hash de Entrega, poderá se utiliza de uma das duas funções que acabam de ser disponibilizadas na unit ACBrDFeUtil. São elas: function CalcularHashDados(const ADados: TStream; AChave: String): string; Devemos utilizar a função acima quando a imagem esta armazenada no banco de dados, neste caso o conteúdo da mesma é passado como Stream no primeiro parâmetro da função, já o segundo é a chave do CT-e. A função retorna uma string com 28 caracteres que devemos atribuir ao campo: infEvento.detEvento.hashEntrega Exemplo: infEvento.detEvento.hashEntrega := CalcularHashDados(xStreamImagem, xChaveCTe); e function CalcularHashArquivo(const APathArquivo: String; AChave: String): string; Devemos utilizar a função acima quando a imagem esta salva em disco, neste caso o primeiro parâmetro da função é o path com o nome do arquivo (imagem) e o segundo é a chave do CT-e. A função retorna a string com 28 caracteres que devemos atribuir ao campo: infEvento.detEvento.hashEntrega Exemplo: infEvento.detEvento.hashEntrega := CalcularHashArquivo(xPathImagem, xChaveCTe);

Funcionou, BigWings. Muito obrigado!