Ir para conteúdo
  • Cadastre-se

Painel de líderes

Conteúdo popular

Showing content with the highest reputation on 30-06-2017 em todas as áreas

  1. Boa tarde a todos, Tem uma luz no fundo do poço e se ninguém jogar um balde de água fria, ano que vem teremos a NFS-e Padrão Nacional. Um único layout para todas as cidades brasileiras e um único Web Services. Não sei se o layout será o mesmo da NF-e ou teremos um layout especifico para a NFS-e. De qualquer forma, se vingar todos os problemas serão resolvidos.
    2 pontos
  2. Bom dia pessoal. Gostaria de agradecer a ajuda de todos voces. Juliomar, Bigwings, voces foram 10 ! Agradecer a paciência e a atenção ! Vou fazer uma doação para o projeto ! Resultado : Deu tudo certo ! Funcionou perfeitamente como eu queria ! Grato !
    2 pontos
  3. Damaris, Desculpa se entendi mal a pergunta, mas é o seguinte: O DANFE ( Documento Auxiliar de Nota Fiscal Eletrônica ) não é o Documento Fiscal e sim o XML. De acordo com Nota Técnica 002-003/2015, não terá alteração no DANFE, sairá apenas no XML por item.
    1 ponto
  4. Obrigado pela explicação, Italo. Vou analisar aqui como proceder neste caso, pois como a aplicação deve trabalhar com todas as versões do CT-e, não será possível utilizar a diretiva de compilação. De qualquer forma foi muito esclarecedor e mais uma vez agradeço pela atenção. Att.
    1 ponto
  5. Juliomar, Deletei todos os fontes da pasta Acbr2 e baixei novamente , instalei novamentee resolveu o problema . Obrigado pela colaboração.
    1 ponto
  6. Allan, Como dito para gerar o XML do CT-e na versão 1.04 é preciso habilitar uma diretiva de compilação. Se você abrir o arquivo ACBr.inc vai encontrar as linhas abaixo: // Definições para o compomente ACBrCTe // Define o Pacote de Liberação / Descomente o pacote a ser utilizado // Atenção: descomente apenas uma das definições //------------------------------------------------------------------------------ //{$DEFINE PL_103} //{$DEFINE PL_104} {$DEFINE PL_200} Note que por padrão esta habilitado a diretiva da versão 2.00. Para gerar o XML segundo a versão 1.03 temos que habilitar a diretiva PL_103, o mesmo ocorre com a versão 1.04 e 2.00 Não teremos uma nova diretiva para a versão 3.00 pois a estrutura do XML é muito parecida da versão 2.00, as diferenças conseguimos resolver com a propriedade VersaoDF. Não vejo necessidade de remover a condição, pois a rotina que contem essa condição só é usada pela versão 2.00 ou 3.00, como dito anteriormente para gerar na versão 1.04 é outra rotina que nem sequer tem essa condição. Ao habilitar a diretiva PL_104 é usada a rotina que se encontra no arquivo pcteCTeW_V104.inc Para demostrar o que estou dizendo, abra o arquivo pcteCTeW.pas temos logo no inicio: {$I ACBr.inc} unit pcteCTeW; interface uses SysUtils, Classes, pcnAuxiliar, pcnConversao, pcnGerador, pcteCTe, ACBrUtil, pcteConversaoCTe, pcnConsts, pcteConsts; {$IFDEF PL_103} {$I pcteCTeW_V103.inc} {$ENDIF} {$IFDEF PL_104} {$I pcteCTeW_V104.inc} {$ENDIF} {$IFDEF PL_200} // {$I pcteCTeW_V200.inc} //////////////////////////////////////////////////////////////////////////////// // // // Gera o XML para a versão 2.00 // // // //////////////////////////////////////////////////////////////////////////////// A linha em negrito e em vermelho foi colocada prevendo uma nova versão totalmente diferente da versão 2.00, mas isso não ocorreu. Logo não existe o arquivo pcteCTeW_V200.inc Espero ter deixado claro que não se faz necessário remover a condição.
    1 ponto
  7. Boa tarde, no campo ACBrNFe.SSL.ListaCertificados.RazaoSocial está vindo 2 caracteres no inicio da string #$13 e #$E. para remediar de momento alterei ACBrDFeWinCrypt.pas adicionando no método GetTaxIDFromExtensions stringReplace destes caracteres. aOID := StringReplace(aOID,#$13,'',[rfReplaceAll]); aOID := StringReplace(aOID,#$E,'',[rfReplaceAll]); *Obs: não são todos os certificados que estão acontecendo isto, é somente 1 ou outro que está vindo esse "lixo" no buffer; Versão atualizada em 30/06/2017 ACBR - Alterações :: linhas 498,499 e 510,511 ACBrDFeWinCrypt.pas Senhores admin, Favor excluir o post ou trancar, o mesmo foi resolvido rodando o apagarAcbr.bat e instalando novamente... Era algum arquivo que estava bagunçando; Desculpe o post inconveniente; Obrigado
    1 ponto
  8. Deu certo, pode encerrar o tópico, obrigado pelo suporte
    1 ponto
  9. Boa tarde Allan, Quem ainda usa a versão 1.04 do CT-e? Essa versão deixou de ser aceita pela SEFAZ em 01/06/2014. E esta previsto o fim da versão 2.00 em 04/12/2017, a partir dessa data a SEFAZ só vai aceitar a versão 3.00 do CT-e. Outra coisa para poder gerar o XML do CT-e segundo a versão 1.04 é preciso habilitar uma diretiva de compilação que encontra-se no arquivo ACBr.inc Com isso será usado uma outra rotina para gerar o XML que por sinal nem sequer existe essa condição, ou seja, as informações do seguro é gerado independente de versão.
    1 ponto
  10. Juliomar grato pelo retorno, e sim, acontecia o mesmo, porém veja o que fiz... Quando usei o apagarACBr.bat e em seguida fiz o SVN Update para a atualização dos componentes, o arquivo ACBr.inc retornou ao seu estado original com a linha {.$DEFINE USE_MINGW}, ou seja, deixou de usar as dlls da MINGW (no meu caso) e passou a tentar a usar as dlls da \OpenSSL\0.9.8.14 .... por esse motivo começou o Acess Violation se referenciando a dll MSVCRT.DLL. Depois de identificar esse detalhe, descomentei a linha {$DEFINE USE_MINGW}, dei um Build geral por aqui e a aplicação voltou ao normal novamente não ocorrendo mais erros. De qualquer forma fica ai o caso para ajuda se algum dia alguém passar pelo problema acima. Grato.
    1 ponto
  11. Sim, é exatamente isso (abre e fecha a porta)... Isso facilita o uso do componente com outras aplicações, que também usam a mesma impressora... Também resolve problemas de impressoras USB, onde é comum a porta Serial Virtual "sumir" temporariamente...
    1 ponto
  12. E esse sistema obtém o XML válido juridicamente? Ou faz o que muitos fazem por aí que é fazer a consulta no portal da nfe e montar um XML falso? No caso da DistribuicaoDFe, para o transportador identificado na NFe e terceiros com CPF ou CNPJ incluído na tag <autXML>, vem a NFe completa. Apenas o destinatário é obrigado a fazer a manifestação.
    1 ponto
  13. Bom dia, Está usando o método DistribuicaoDFe? Veja a observação na Nota Técnica 2014.002 v102b: Portanto, para obter a NFe completa, o destinatário antes deve fazer a Manifestação da NFe.
    1 ponto
  14. termine seu TXT aqui: [Rodo]RNTRC=00000000dPrev=28/06/2017 não precisa as outras linhas, e tira tb a linha Forpag. Configura o Monitor no Modelo Fortes
    1 ponto
  15. Cara , voce me salvou algumas noites de sono... era isso mesmo que voce disse, faltava o segundo parametro ... e assim estava modificando o xml retornado... nem testei ainda , mas ja entendi o que estava ocorrendo, muito obrigado Ítalo, essa rotina ja estava no sistema á algum tempo, quando eu vi isso, que estava alterando o xml, imediatamente tirei a consulta, e fiz os clientes buscarem la na sefaz o xml, até eu resolver de outra forma... e eu nao tinha ideia , porque estava alterando o xml, ainda bem que voce me mostrou uma luz no fim do túnel, muitissimo obrigado, vou devolver a consulta novamente agora com o segundo parametro e posto aqui o resultado
    1 ponto
  16. Alterações enviadas ao SVN, obrigado pela colaboração.
    1 ponto
  17. Obrigado Daniel, atualizado e testado. Tudo Ok após sua correção..
    1 ponto
  18. [RESOLVIDO] Pessoal, realmente foi um problema de demora e instabilidade de atualização do Sefaz com o Sat Sweda. Iniciei a atualização as 11:00, a "atualização em andamento" acabou as 18:40. Um amigo meu técnico disse que teve o mesmo problema com outros sats Sweda, inclusive teve uma máquina que ficou 2 dias na bancada atualizando. Se alguém passar por isso, só resta esperar.
    1 ponto
  19. não a menos que programe em delphi o monitor é escrito em lazarus e usa o fortes.
    1 ponto
  20. Concordo, Italo, essa alteração em ACBrDFe foi bem específica para minha necessidade mesmo, na verdade, pelo fato de eu não ter encontrado uma maneira de recuperar o nome e endereço do arquivo de resposta da função que faz a consulta do lote. Muito obrigado pelo retorno e pela alteração objetivando o atendimento de nossa cidade.
    1 ponto
  21. Italo A Data Prevista de Entrega continua sendo informada na versão 3.0, e a impressão da DACTE foi corrigida na versão 1.1.0.17 pelo Jose M.S.Junior atendendo solicitação minha ao SAC
    1 ponto
  22. O número deve ter 3 posições e o nome do grupo deve ser InfAdic. Ex: [InfAdic001]
    1 ponto
  23. Boa Tarde A implementação ACBrBancoBrasilSICOOB já está disponível no repositório. Obrigado pela Contribuição.
    1 ponto
  24. Houve uma atualização nos servidores do Sefaz (06/2017), referente a raízes de certificação, e isso acarretou um problema na emissão das notas fiscais, Principalmente nos estados da Ba SP MG dentre outros.Link ICP-BrasilV5: http://acraiz.icpbrasil.gov.br/ICP-Brasilv5.crt Link Raizes certificadora de todos certificados: http://acraiz.icpbrasil.gov.br/repositorio/v1_v2_v3_v5_msie.p7b Instalei ambos no repositório como Autoridades de Certificação Raiz Confiáveis e voltou a funcionar normalmente.
    1 ponto
  25. Não faço parte do Governo, e não sou fabricante de SAT... mas acho que o SAT é uma ideia infinitamente melhor e mais robusta do que a NFCe... Nosso software atende PAF-ECF, NFCe e SAT... ( www.djpdv.com.br ) e minha opinião, é que a NFCe é um "filho mal parido da NFe"... Autenticação online, para varejo ?? Resultado: fila nos caixas dependendo do horário... Nosso software faz o tratamento automático da entrada e saída de contingência, trabalha em Background na transmissão da fila do OffLine, e na resolução de outras pendencias... Muita da inspiração que tivemos na construção de nosso módulo emissor de Documentos Fiscais, veio da observação do funcionamento do SAT. Mas mesmo assim, nosso suporte, sofre com o NFCe... Cada estado tem uma peculiaridade, a Internet no interior do Pais é intermitente e de qualidade lastimável... então o que podemos observar, é que a experiência de uso do usuário com o SAT, é infinitamente melhor do que do usuário de NFCe... Se o fisco fizesse cumprir o rigor da lei, que obriga a transmissão dos XMLs emitidos em OffLine, em até 24 hs úteis, muitos estabelecimento já teriam fechado as portas... O projeto NFCe é uma péssima ideia para o varejo...mas que está sendo remendada aqui e ali, e vai funcionar aos trancos e barrancos... Sinceramente, o varejo estava bem melhor com os ECFs, do que com a NFCe. O projeto SAT por sua vez... demorou 3 anos para nascer, o fisco de SP fez inúmeras consultas públicas, convocando setores do varejo, fabricantes e Sw.Houses de Automação Comercial. Tudo isso para mitigar os problemas e deixar bem clara as regras e normas de uso. O Fisco foi aberto a sugestões, e criou uma especificação técnica clara, consistente e que funciona... O SAT, passou por um período de ajuste... Alguns fabricantes sofreram até deixar seus Sw.Básicos e DLLs robustos o suficiente para o uso.. O retaguarda do Fisco apresentou inumeradas falhas (reconheço que algumas ocorrem ainda hoje em dia)... Mas hoje, podemos afirmar, que o SAT está muito mais maduro e robusto do que a NFCe... e o que percebemos no uso dos clientes finais, é a filosofia: "Instale e esqueça"... pois depois de instalado o SAT, ele funciona sozinho... Porque vocês acham que SP não permite NFCe off-line ? Alguns estados, já perceberam o grande aumento da sonegação fiscal, quando passaram a permitir: offline + impressora não fiscal nos caixas... (afinal o empresário Brasileiro, não paga imposto só porque que é patriota) Os números falam por si... Quem esteve na última reunião do ENCAT pode presenciar... Atualmente, SP já autorizou mais CFe's (SAT), do que a soma de todas as Unidades Federativas do brasil autorizaram NFCe's. Incluindo nessa conta.. as milhares de NFCe's que o próprio SP emite...
    1 ponto
  26. Boa tarde, amigos. Não sei se é o caso do colega, posso está falando asneiras, mas comigo dá a mensagem "Certificado Digital não encontrado", quando eu atribuo o caminho do ".pfx" e informo a senha e o número de série. Para que o componente ACBr faça a leitura do seu certificado apenas pelo diretório onde ele se encontra sem a necessidade de está instalado, além de informar o caminho corretamente, você precisa informar apenas a senha do certificado, não informe o número de série, pois ao informar o número de série, as condições no condigo fonte irá procurar esse certificado instalado na máquina, por isso ele retorna que não foi encontrado! Se a sua necessidade é ler um PFX de um diretório e usálo, então essa é a forma que eu utilizo e funciona. Tente assim: ACBrNFe1.Configuracoes.Certificados.ArquivoPFX := caminho; ACBrNFe1.Configuracoes.Certificados.Senha := senha; ACBrNFe1.SSL.CarregarCertificado; if(ACBrNFe1.SSL.CertificadoLido)then ShowMessage(ACBrNFe1.SSL.CertNumeroSerie);
    1 ponto
  27. Ricardo tente reinstalar a capicom do acbr e também atualizar a cadeia de certificados.
    1 ponto
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...