Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

consultoria_sticker.png

Conteúdo para desenvolvedores
 ao vivo de terça a quinta!
Saiba mais

dev.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


Saiba mais

beneficios.png

Paulo Roberto Medeiros

Membros
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Paulo Roberto Medeiros

  • Rank
    Novato

Recent Profile Visitors

524 profile views
  1. Essas respostas só mostram como vocês pouco de importam com as pessoas que utilizam o ACBR, vocês desenvolvem somente para vocês mesmos, e ainda colocam como projeto "livre" para se aproveitar da comunidade. Vão ver se os grandes open sources como java ou linux são como essa zona aqui. Com certeza eu faria um projeto mil vezes melhor, se tivesse tempo e interesse em um tecnologia morta.
  2. Essa é minha primeira e unica postagem sobre esse assunto, e pareceu ser o tópico mais especifico sobre esse problema que pelo visto já está aí a um bom tempo. Acho o ACBR um grande projeto, mas infelizmente muito mal administrado. É terrível como alteram as classes e liberam elas com milhares de bugs. E o pior é que parecem nem ligar para coisas críticas como problemas na emissão de notas fiscais. Acredito que o problema seja na função TNFSeWebService.DefinirSignatureNode, ela está definindo um FxSignatureNode que não existe no Betha.
  3. Pelo visto está acontecendo com todo mundo, já tem várias postagens reclamando disso. Notei que a função TDFeCapicom.Assinar é chamada duas vezes, na primeira o SignatureNode tem o valor './/ds:Signature' e tudo dá certo, na segunda vez que passa ali o SignatureNode vem com o valor './/ns3:EnviarLoteRpsEnvio/ds:Signature', e aqui ocorre o problema. Algum desenvolvedor do ACBR pode nos ajudar a corrigir esse BUG do ACBR?
  4. Também comecei a ter esse problema depois de atualizar os fontes essa semana. Nota de São José/SC (Betha)
  5. Parece que voltou a funcionar com o certificado Betha. Vlw!
  6. Apareceu mais um erro de formatação: "[3513405 Nome=Cruzeiro". Esquece, já foi corrigido.
  7. Alguém pode fazer essas correções no Cidades.ini? 1) São José / SC (4216602): Voltou a usar o sistema Betha, ou seja, precisa mudar o provedor de Pronim para Betha. 2) Porto Velho / RO (1100205): Está faltando fechar o conchetes no nome da sessão.
  8. Ressuscitando o tópico, o erro voltou a ocorrer. Estava tudo normal até o final de 2015, agora começou a dar esse erro no ambiente de Produção sem eu ter alterado nada em meu sistema. Observações: 1) O certificado que estou usando está dentro da validade. Peguei outro no sistema Betha e o erro continua. 2) O erro ocorre somente no ambiente de Produção. No ambiente de Teste a nota é processada com sucesso. 3) Testes realizados com a prefeitura de São José/SC. 4) Atualizei os fontes dia 18/01/2016 (trunk2) e o erro persiste.
  9. Analisei esse manual e as únicas coisas erradas são os itens I e X03, as demais erros são do acbr e não do manual. Além disso a Nota Técnica que te passei está correta, só teve aquele pequeno erro de digitação, mas está bem claro que é erro de digitação.
  10. Sobre o NVE, não cheguei a implementar a posição correta dele, mas ele fica em linhas separadas como essas: I05a|ED4324| I05a|AS4324| Veja também que podem existir mais de um NVE para cada item. A Nota Técnica NT2013.005_v_1.10 possui os detalhes sobre como é o layout, embora ela mesma contenha alguns erros, por exemplo, no caso desse campo ela coloca o ID desse campo como 105a, mas na verdade é I05a. Os outros campos que alterei é praticamente só cópia do layout 2.00, pois não houve alterações na versão 3.10, apenas a inclusão de novos campos em linhas novas. Nenhuma linha já existente s
  11. As correções foram feitas com base nos erros identificados durante a importação pelo emissor do sefaz (importação do txt). Código Anterior: LoadLayout('<C02> C02|CNPJ¨'); LoadLayout('<C02a> C02a|CPF¨'); LoadLayout('<E02> E02|CNPJ¨'); LoadLayout('<E03> E03|CPF¨'); LoadLayout('<E03a> E03a|idEstrangeiro¨'); LoadLayout('<I01> I|CProd¨|CEAN¨|XProd¨|NCM¨|NVE¨|EXTIPI¨|CFOP¨|UCom¨|QCom¨|VUnCom¨|VProd¨|CEANTrib¨|UTrib¨|QTrib¨|VUnTrib¨|VFrete¨|VSeg¨|VDesc¨|VOutro¨|indTot¨|xPed¨|nItemPed¨|nFCI¨'); LoadLayout('<O07> O
  12. A geração de TXT para a versão 3.10 estava cheia de erros no layout, fiz as correções e estou enviando em anexo para integração aos fontes. pcnLayoutTXT.pas
  13. O arquivo txt gerado está incompleto, estão faltando as duas primeiras linhas (A e A01). Vejam exemplo em anexo S911-NFe.txt
  14. Ao enviar uma Inutilização e o sefaz retornar uma mensagem de erro, ela não está sendo atribuída ao campo Motivo. Uma possível correção (pcnRetInutNFe.pas, linha 117): Código atual: if leitor.rExtrai(1, 'infInut') <> '' then (*DR08 *)FxMotivo := Leitor.rCampo(tcStr, 'xJust') else (*DR08 *)FxMotivo := Leitor.rCampo(tcStr, 'xMotivo'); Correção: if leitor.rExtrai(1, 'retInutNFe') <> '' then (*DR08 *)FxMotivo := Leitor.rCampo(tcStr, 'xMotivo') else (*DR08 *)FxMotivo := Leitor.rCampo(tcStr, 'xJust'); Obs.: Usando Layout 3.10
×
×
  • Create New...