Painel de líderes

Criado no ACBrMonitorPLUS um relatório para verificação do retorno dos bancos. Isso visa facilitar a leitura e conferência dos títulos recebidos no arquivo de remessa. O relatório, utiliza o arquivo de retorno do banco, carrega os dados do cedente e a lista de títulos do arquivo. A emissão pode ser feita pela interface do programa, como abaixo. É possível nesta tela também configurar um logotipo para o relatório. Ou ainda via comando, ao ler o retorno. BOLETO.LerRetorno(cDirArqRetorno,cNomeArqRetorno,bImprimeRelatorio)

Se tem internet emite normal. A ideia é não deixar cliente nem transporte esperando na porta da empresa. Dai vc usa contingencia

No geral são os CFOPS de COMPRA e de VENDA, de DEV.COMPRA e DEV.VENDA. Isto não é tão fácil assim. Tem exceções do mesmo CFOP ter ou não financeiro. As vezes a própria estrutura da empresa ou contabilidade. Tem que estudar cada "CFOP" e não "NFE".

Melhor explicação, só se você fizesse! Muito obrigado e parabéns

Honorável BigWings você estava com a razão. eu sem observar dei 2 Add no meio do código de programação enumerando assim que passasse por ele uma nota a mais o que estava provocando estes erros. Obrigado. Caso Resolvido.

Caros, o método GetNumCOOInicial não estava implementado na classe TACBrECFVirtual fazendo o valor do CooInicial retornar vazio. Anexo correção para avaliação. ACBrECFVirtual.pas

Muito obrigado, já está no SVN...

Olá Ricardo Miquinioty, É que a leitura que faço desse quadro é que ele está dizendo: 1 - Se no ECF você usaria o Totalizador "T" (CST´s 00 e 20), no SAT usa-se CSOSN 102. 2 - Se no ECF Você usaria o totalizador "I" ou "N" (CST´s 40, 41 e 50), no SAT usa-se CSOSN 300. 3 - Se no ECF você usaria o totalizador "F" (CST´s de Substituição Tributária), no SAT usa-se CSOSN 500. Quanto ao 900, veja o que diz o item 7: 7. Como o optante do Simples Nacional preenche a alíquota no CF-e-SAT? No CF-e-SAT, os contribuintes optantes do Simples Nacional, devem utilizar o CSOSN conforme o tipo de produto e operação. Não é necessário preencher alíquota nos seguintes CSOSN: 102- Tributada pelo Simples Nacional sem permissão de crédito. 300 – Imune 500 – ICMS cobrado anteriormente por substituição tributária (substituído) ou por antecipação 400 - Não tributado (a partir de 01.01.2016) No caso do CSOSN 900 (Outros) é necessário preencher a alíquota e deve ser preenchida de acordo com o produto e operação. Na minha humilde opinião, isso reforça a ideia que para produtos ISENTOS usa-se o CSOSN 300. Mas como já ficou claro no tópico, realmente ainda sobra dúvidas sim, e até que algum contribuinte ou contador oficialize uma consulta na SEFAZ, a fim de termos opinião oficial ainda acho que deve se usar o CSOSN 300. Vamos aguardar...

Bom dia! Lembrando que não se deve mudar o layout. Este deve estar de acordo com o manual. Porém o valor da taxa de entrega pode ser informado nos dados adicionais.

Bom o erro já deu pra ver que é lá ! precisaria questionar o sefaz do problema.

Nosso ambiente é 64bits, utilizamos o OpenSuse. Tudo funciona perfeitamente com a criação dos links simbólicos. É uma distro bem interessante, recomendo!

Estava pesquisando na internet esse problema e vi que voce postou em 03/2016 que existe um arquivo cidades.ini que deve ser lido para pegar o provedor. Então essa é a nova forma que subsitui a função CodCidadeToProvedor de pnfsConversão. Obrigada pela atenção!

Boa Noite... Interessante a questão... Sou proprietário de uma pequena software house... atendo aproximadamente 100 clientes, dentre os quais apenas 5 ou 6 emitem mais de 3000 a 4000 NFC-e´s mensalmente... Utilizo o componente ACBr desde o inicio da empresa (2008) e, com o advento em principio da NF'e, aqui no estado do Pará, (09/2009), levando em consideração que é de obrigatoriedade da empresa o armazenamento e guarda dos arquivos XML's pelo período mínimo de 5 anos, desde o início, principalmente a pedido dos contadores de meus clientes, meu software de Gestão Comercial, armazena no servidor, os XMLs das NF-e's de emitidas, desde 01/2016, das NFC-e's emitidas, e desde 2015, valendo-se dos DFe do ACBr, das NF-e's de compra... Todas as transações que envolvam emissão de NF-e ou NFC-e, armazenam no banco de dados o registro das mesmas, utilizando a Chave de Acesso como base para acesso ao XML do respectivo documento armazenado no servidor, seja autorizada, cancelada, denegada...Bom como os registros de compra e seus respectivos XMLs adquiridos a partir do DF-e do ACBr (vale salientar que diversos clientes, principalmente mercados e mercearias, detectaram empresas utilizado-se de seus CNPJ para emissão de NF-e's dentro do estado do Pará, fatos que não chegavam ao conhecimento dos contadores por estas transações não constarem dos relatórios de fronteira do orgão de fiscalização estadual - SEFA do estado do Pará)... Partindo deste ponto, com todas as informações gravadas no banco de dados, e dos XML's nas suas devidas pastas, os usuários do meu sistema simplesmente, no inicio do mês seguinte, clicam no Menu XML's NF-e's / NFC-e's para Contabilidade, informam o mês para envio, e o sistema varre o banco de dados, buscando primeiramente identificar lacunas entre a numeração das NF-e's e NFC-e's emitidas e, caso encontre, solicita ao usuário a inutilização dos números não utilizados... Caso encontre NFC-e's em contingência, obriga a retransmissão das mesmas... Depois, transfere todos os XML's de Compra, XML's das NF-e's emitidas, canceladas, denegadas, inclusive XMLs das Inutilizações, NFC-e's emitidas, canceladas...., inclusive XMLs das Inutilizações, para uma pasta temporária, separando em pastas tipo "Autorizadas", "Canceladas", "Denegadas", "Inutilizadas", por modelo de documento, gera um relatório em PDF de todas as ocorrências, o qual passa a valer como recibo de entrega ao contador, compacta tudo, inclusive o PDF, e, envia o arquivo compactado por email ou grava em mídia para entrega física... Desta forma, todos os arquivos XML necessários ao escritório de contabilidade, são entregues já no primeiro ou segundo dia do mês, incluindo o resumo em PDF de tudo... sem falhas, sem arquivos faltantes, sem problemas, o que tem rendido inclusive indicação por parte dos Escritórios de Contabilidades de novos clientes, fechando-se assim um ciclo, em que a empresa fornece as informações necessárias e, o contador simplesmente as registra... Por tudo isso, eu, como programador, e também em nome de todos de todos os demais colegas de profissão, quero agradecer a toda a equipe ACBr, pelo incrível e vasto leque de componentes que oferece a comunidade da Automação Comercial do Brasil... Componentes sem os quais, provavelmente minha empresa já teria fechado as portas.... Peço desculpas caso tenha postado em local incorreto, mas achei conveniente a publicação neste post....

Depois de muita conversa interna e requisição de uma parte dos usuários ACBr, resolvemos estender o suporte ao Delphi 7 até Janeiro de 2017. Por que? Nossa principal motivação foi porque muita gente está pensando que quando chegasse o fim de agosto a compatibilidade com o Delphi 7 será simplesmente removida e seus aplicativos vão parar de funcionar. Infelizmente, algumas pessoas estão usando isso com um oportunismo, fazendo "terrorismo" nos usuários do projeto ACBr. Queremos que entendam que não é fácil manter a compatibilidade do projeto em tantas versões diferentes. E não estamos recebendo muita ajuda nessa área. É difícil manter compatibilidade com versões UNICODE quando nós mesmos não usamos. Mas então em janeiro meu aplicativo Delphi 7 deixará de funcionar com o ACBr? Não!!!! Seu aplicativo vai continuar funcionando. Isso é mentira, falácia, balela, uma grande prosopopéia para acalentar bovinos (conversa pra boi dormir). Então o ACBr não vai mais enviar alterações e correções de acordo com a legislação? Claro que vamos continuar enviando alterações e correções. Então não entendi... Pois é... Isso é o que a gente está tentando esclarecer... Deixa eu tentar... Como é o processo atualmente: Sempre que antes de enviar uma correção, alteração ou inclusão de nova característica, precisamos avaliar se vai funcionar no Delphi 7. Mas a maioria de nós não utiliza mais o Delphi 7. Então depois fazemos a correção, testamos na versão que utilizamos. Daí precisamos, por exemplo disparar uma máquina virtual, esperar ela carregar, copiar o novo código para a VM, fazer os testes no Delphi 7, voltar a máquina normal e só depois enviar ao SVN. Como queremos que seja o processo após janeiro de 2017: Fazemos a correção que precisamos, testamos nas versões que suportamos, e enviamos ao SVN. Mas e o Delphi 7? Os componentes até essa data vão continuar funcionando no seu Delphi 7. Mas a partir dessa data você deverá ter cautela para atualizar via SVN. Eventualmente, sem intenção, uma quebra de compatibilidade pode acontecer. Neste caso você sempre terá a opção de voltar para uma revisão que esteja funcionando. Mas se preferir poderá fazer algo: Corrigir você mesmo o problema; Encontrar algum voluntário para corrigir; Atualizar para uma IDE suportada; Quais as IDE suportadas? Lazarus ou Delphi 2009 ou posterior.

Correção svn!

Atualizado conforme solicitado. ACBrValidador_atualizado.zip