Painel de líderes

Depois de alguns dias finalmente autorizou, era algum problema no Sefaz mesmo.

Segue Layout atualizado para o Banco Inter No Banco Inter, é oferecida a modalidade “Depósito por Boleto”, que é uma maneira simples e segura de se creditar valores na Conta Digital. Vale lembrar que essa modalidade tem a funcionalidade de depósito e não para cobrança, portanto, para casos de inadimplência, não será possível realizar protestos em cartório. Pelo fato do boleto ser para depósito e não para cobrança, o cadastro deverá ser feito boleto por boleto. A plataforma a ser utilizada no Internet Banking será "Folha" no padrão CNAB 240. O modelo é um formato universal de arquivo em lote de comunicação entre sistemas (borderô), seja cobrança, folha de pagamento, transações, etc. A orientação é de que se realize desenvolvimento conforme instruções do manual e arquivo modelo em anexo. Após realizar o desenvolvimento no caminho informado você poderá realizar os testes de importação de seu arquivo folha em formato CNAB 240. CNAB 240 padrão Febraban - Folha Exemplo.txt CNAB 240 padrão Febraban.pdf

Olá, Antes de mais nada, vi que esse é um assunto um pouco batido aqui no fórum e que já existem aqui vários tópicos, mas todos todos encontram-se sem resposta há algum tempo e acabaram sem solução, por isso optei por criar este. Um de meus clientes, que está no regime do simples, mencionou a necessidade de emitir CF-e com as CST 04 e 08 para o PIS e COFINS, pois do contrário ele sofreria bitributação. Seu contador alegou o mesmo, e disse inclusive que havia feito contato com o Sefaz/SP sobre isso. Como creio já ser de conhecimento de todos, devido a forma como o manual disponibilizado pelo Sefaz/SP está redigido geralmente usa-se a CST 49 para o PIS e COFINS na emissão de CF-e SAT quando a empresa é do regime do simples. Mas devido a insistência do cliente fiz contato com o Sefaz/SP e recebi o seguinte retorno: "No caso do PIS/Pasep e da Cofins, os valores registrados no CF-e-SAT devem ser escriturados conforme orientações da Receita Federal do Brasil, órgão responsável por estes tributos." Após algumas pesquisas, localizei este link no site da Receita Federal com perguntas a respostas sobre EFD contribuições: Perguntas e Respostas EFD Contribuições.pdf Na página 42, a questão 95 fala justamente sobre qual CST pode ser usada por PJ optante pelo simples. Embora fale sobre NF-e, creio ser perfeitamente aplicável a NFC-e e ao SAT CF-e também. E esta questão coloca que empresas optantes pelo simples podem usar as CST 49, 02, 03, 04 e 08 para PIS e COFINS (obviamente, depende do caso). Após algumas pesquisas verifiquei que a CST 49 pode ser usada por empresas do regime normal também, mas em algumas situações onde não há valor, como transferência de estoque. Se apenas empresas optantes pelo simples podem usar esta CST em vendas faz sentido o manual de especificações do SAT indicar esta CST como sendo para empresas optantes pelo simples. Mas ao mesmo tempo, isso não limita estas empresas a usarem apenas esta CST. Analisando o código do do ACBR vi que a unit "pcnCFeW.pas" estava limitando a CST a opção 49 quando a empresa era simples, gerando com uma tag errada caso usasse outra, o que ocasionava uma rejeição no SAT: "código de situação tributária do PIS inválido (diferente de 49)". Como já apareceram aqui no fórum vários casos além do meu, o Sefaz/SP indica que deve seguir as normas da Receita Federal, e a Receita Federal abre a possibilidade para uso e outras CST para PIS e COFINS além da 49, creio que isso é suficiente para um ajuste no componente para permitir estas CST. Fiz este ajuste comentando as linhas 409 a 414 e 507 a 512 da unit, segue o arquivo com os ajustes. Com este ajuste as tags geradas se basearão apenas na CST selecionada, sem considerar o regime. Meu cliente já está emitindo cupons com as CST 04 e 08, que já foram transmitidos e aceitos pelo Sefaz, sem nenhuma rejeição nem no SAT nem no site retaguarda do SAT. pcnCFeW.pas

Olá amigos, depois de mais um cliente ter perdido o certificado resolvi que ia tentar descobrir oque estava causando isso, e depois de muita peleja(são 4:00 da manhã ), acho que consegui chegar ao causador do problema, pelo menos tive sucesso em excluir um certificado por diversas vezes assinando um XML. E como muito se falava, não é diretamente o ACBR que está excluindo o certificado, pelo que constatei é a MSXML que está "reiniciando" o certificado e somando isso a mais algum problema está causando a exclusão. Se você assinar um XML e deixar o administrador do token aberto, verá que no momento da assinatura, no trecho "xmldsig.sign(dsigKey, CERTIFICATES);" o token muda de: Operacional >> Ausente >> Presente >> Operacional, como se o cartão fosse removido e inserido novamente. Pensei aí tem coisa! Tentei remover o cartão durante a assinatura mas não consegui simular a exclusão do certificado, imaginei que não estava sendo rápido o suficiente. Então coloquei um loop no trecho do ACBR que pega a chave privada do certificado, antes de executar a assinatura, percebi que até aí o PIN do certificado não era solicitado, somente mais a frente quando ocorre a assinatura com "xmldsig.sign(dsigKey, CERTIFICATES);". Porém quando removi o certificado da leitora e inseri novamente dentro do loop(o mesmo que a MSXML faz durante a assinatura) foi me solicitado o PIN e logo depois veio a mensagem: "O conjunto de chaves não está definido", olhando no administrador do token que estava aberto pude ver o certificado sendo excluído: O PIN que ele me solicitou foi para excluir o certificado! O que imagino que esteja acontecendo é que se você chamar o método Assinar repetidamente, antes de dar tempo do cartão ficar operacional novamente, o certificado pode ser excluído. Isso explicaria o porque da exclusão ser esporádica e também não acontecer com todos os sistemas, pois dependeria da lógica usada por cada um para assinar, como assinaturas em sequência ou mesmo mais de uma thread acessando o certificado. Fiz um vídeo mostrando o momento da exclusão, note que não consegui excluir na primeira tentativa, porque demorei muito pra inserir o cartão, estava com uma mão ocupada filmando, ia editar isso mas tô com muito sono. MODERAÇÃO: vídeo removido a pedido do usuário Vou dormir um pouco e amanha ver se me aprofundo no problema.

@renesul Após fazer uma instalação limpa do ACBR não tive mais problemas, e esta normal o tempo.

Hj, que tive tempo de trabalhar nisso, atualizei o Fontes do ACBr e o .ini já estava com os URLs atualizados. Obrigado mais uma vez @BigWings e a todos do Projeto ACBr

Se você usa certificado A3 a unica forma de evitar a perda de mais certificados é usar a nova biblioteca de assinatura que não depende da libxml5.dll que causava esse problema. Já testei amplamente e não ocorreu mais a exclusão usando as novas classes, inclusive estou usando em produção já. Mais informações em:

Deu certo, obrigado. Ficou assim procedure TfrmPrincipal.RegC010(pBloco: TBloco_C); begin try with pBloco.RegistroC010New do begin CNPJ := SomenteNumeros(queryEmpresa.FieldByName('cgc').AsString); IND_ESCRI := IndEscriIndividualizado; end; except on E: Exception do raise Exception.Create('Erro ao criar registro C010. Motivo:'+#13+E.Message); end; end;

vou fazer um usando os mesmo exemplo do demo acbr, só que em iw, obrigado

A minha intenção é refazer do zero, vou mudar a arquitetura do sistema para RESTful. É desenvolvido sob medida e estão começando a surgir necessidades diversas, tais como mobile e web. Não creio que no meu caso tenha havido muitas alterações nas normas, nossas vendas são restritas a apenas um segmento. Mas...

Olá BigWings, Perfeito sua observação... A nota em que eu efetuei o teste era de VENDA, fiz agora uma de devolução e aceitou o "Sem Pagamento" com o valor 0,00. Obrigado e abraços

Realmente, era isso mesmo!! Muito obrigado!!

Boa tarde Dois novos ajustes foram necessários, agora no bloco K, registro 220. ACBrEFDBloco_D.pas ACBrEFDBloco_D_Class.pas ACBrEFDBloco_K.pas ACBrEFDBloco_K_Class.pas

Compreendo sua resposta @Juliomar Marchetti e @hleorj é uma boa ideia mas infelizmente falta tempo. Se alguém souber de outra solução ou ideia.

O nfecalc ( desenvolvjdo por @hleorj ) , foi um exercício de cálculos sem integração com ACBr. Acho existe um demo bem antigo no ACBr. Acho que merece uma nova atualização.

Bom dia conforme já postei em outros locais não está liberado nada desse componente estou trabalhando no mesmo para liberar.

Há uma exceção para essa validação no caso de notas de ajuste e devolução (NT 2016.002 v1.42). Então não deveria ocorrer a rejeição. Foi preenchida a tag finNFe como 4 - Devolução?

O problema ocorre porque o delphi não consegue localizar o arquivo midas.dll no PATH, para corrigi-lo, devemos entrar no Painel de controle -> Sistema - Variáveis de ambiente; Edite variáveis e faça o upload do caminho correto de acordo com a versão em que estamos trabalhando

Sinceramente Janio, prefiro não me envolver. Enquanto não existir um manual e versão oficial do Integrador(funcionando) disponível no site do SEFAZ do Ceará irei congelar o desenvolvimento no ACBr referente ao MFE. Não podemos ficar nessa de tentativa e erro em algo que vai afetar gravemente os contribuintes do Ceará.

O mesmo problema com Delphi Seatle para resolver tive que pegar midas.dll da pasta bin e colocar na pasta System32, SysWOW64 e na pasta do Meu Projeto