Ir para conteúdo
  • Cadastre-se

Mark Apollo

Membros
  • Total de ítens

    707
  • Registro em

  • Última visita

  • Days Won

    7

Tudo que Mark Apollo postou

  1. Dan Daniel, me desculpe, mas, a estrutura toda de classes e enums são reescritas, inclusive todos os registros dos SPED's, NFe, ou qualquer outro projeto, Sim, concordo que centralizar a regra de negocio em um único lugar facilita, também concordo com a experiência do ACBr, não é atoa que estou aqui, colaboro e tento discutir, não para gerar confusão, mas, ao contrário, para ajudar o ACBr a melhorar ainda mais o quanto for possível. Mas, só estou tentando passar a experiência que estou tendo, com melhor desempenho, por exemplo, que posso comprovar que foi "gritante", ao menos para consultar notas destinadas. Mas, como falei, caso seja de interesse geral, eu disponibilizo o código, sem problemas nenhum, caso contrário, continuarei o desenvolvimento para uso próprio, aproveitando a experiencia do ACBr. Mas, só disponibilizarei em consenso com os administradores do ACBr, justamente para não criar projetos fragmentados/paralelos. Abraços.
  2. Pergunto: qual a dificuldade/problema em reproduzir a biblioteca em .NET, Java, etc, vejo no ACBrFramework que boa parte das classes são reproduzidas, boa parte do código já é reproduzido e outros mais para possibilitar a interoperação. Não tive muito trabalho em fazer alguns recursos do NFe funcionar, acredito que vou ter mais trabalho é na geração do DANFe. Sei que a toda alteração teria que dar manutenção em vários códigos, mas, já é assim hoje, se, por exemplo, adicionarem mais um elemento no xml da NFe, tanto o componente delphi terá que ser alterado, quanto a framework, apesar de ser um excelente trabalho o que está sendo feito.
  3. [OFF Topic] Tenho medo de falar sobre outras linguagens em fóruns por causa de retalhação, mas, sinceramente, aqui me sinto mais a vontade, mas, tomo muito cuidado em apresentar argumentos para que eu não acabe levando a conversa produtiva à discussões xiitas sobre linguagens, detesto isso... [/OFF Topic] Sim, tenho um conhecimento básico sobre os itens citados, sim, dentro da minha disponibilidade, poderia juntar forças com a galera. Também não creio que a questão do desempenho seja pela capicom, mas, por outras questões que, sinceramente, não saberei dizer, fato é que tive este ganho de desempenho, Quero terminar o componente NFe para poder ter mais informações, Tenho tentado fazer o máximo possível na estrutura do componente em delphi, aproveitando nomes de propriedades e eventos, acredito que, caso seja interessante, não será possível, por exemplo, substituir a parte referente a ele no ACBrFramework, por exemplo.
  4. Esse é outro problema que tive, que não consegui contornar.
  5. Tenho acompanhado o processo do framework também, quando decidir reproduzir o ACBr para .NET ainda não existia ele, somente a dll, mesmo assim decidi por conta própria continuar. Tenho um certo receio em algumas coisas, tais como o uso do CAPICOM, que já foi abandonado pela microsoft a anos, outra coisa que acabei percebendo foi que, ao menos na consulta de NFe's destinadas, as requisições ficaram muito mais rápidas, tipo: antes eu não conseguia realizar a consulta até o ultimo NSU de todos os CNPJ's que necessito, mesmo que deixasse rodando um dia inteiro, hoje, em cerca de 1 hora eu consegui recuperar todas as notas, mesmo iniciando do NSU 0, agora demoro 10 segundos para retornar todas as notas de um dia para 14 CNPJ's. Também tive menos erros de conexão, etc... Estes são alguns dos motivos que têm me motivado a migrar o componente para .NET.
  6. Porque não consegue, algum erro??
  7. Devemos sempre estar com os xsd's mais atualizados, logo, é mais fácil sobrescrever do que verificar o que mudou, para saber o que mudou devemos ficar ligados nas Normas Técnicas (NT), esta vêm explicando o que mudou e as novas validações, caso hajam.
  8. Ei, Juliomar, sim, já olhei, só que eles não estão migrando o projeto, eles estão fazendo um interop, ou seja, continuamos presos ao 32 bits, se não for possível compilar os componentes em 64 bits. O que eu estou fazendo é não utilizar a dll, não utilizar um código em delphi, somente em .NET. Estou preparando algumas informações e, assim que tiver mais concreto, dou mais notícias. Mesmo se a galera não se interessar, estou fazendo por mim, pois estou precisando muito e estou aproveitando muito do aprendizado e da estrutura dos componentes ACBr para o desenvolvimento, já que, ao meu ver, a suite ACBr é a mais estruturada do mercado, mesmo quando olhamos um único componente.
  9. Mago, também tenho tido alguns problemas com o CAPICOM, o que me fez tomar uma decisão: estou migrando os componentes que necessito para .NET. Estou aos poucos fazendo isso no meu tempo vago, hoje tenho em produção somente a consulta de NFe's destinadas, mas, aos poucos quero migrar, primeiramente o ACBrNFe e, de acordo com minha necessidade, os outros também. Assim que tiver com eles mais completos posso, caso achem interessante, disponibilizar na comunidade.
  10. Até onde sei, ou você adquiri um certificado, ou solicita emprestado de alguma transportadora. (não é tão fácil conseguir emprestado)
  11. Também tive essa dificuldade, no final, passei a gerar em Fortes e tudo funcionou!
  12. No Demo do CTe tem um exemplo de como validar: DMCTE.CTe.Conhecimentos.Assinar; DMCTE.CTe.Conhecimentos.Valida; DMCTE.CTe.Enviar(Lote); DMCTE.CTe.Conhecimentos.Imprimir;
  13. No manual de Itegração do CTe v1.04, na página 100:
  14. O problema não está no seu trecho de código, se ler a mensagem verá que está informando '2' no campo tpEmis, e o valor aceito é somente 1,5,7 e 8.
  15. Rapaz, existem, e não são poucos não, viu...
  16. Regis, há previsão de liberar a impressão de eventos para Fortes? já há no fórum um tópico com a contribuição do código, mas até o momento não foi liberado nada. Abraços!
  17. Sim, também sei disso, mas, acredito que existam mais pessoas como eu, rodo o aplicativo em windows server e sei que dentro de poucos anos não teremos mais suporte ao windows 2003 e daí a pouco ao 2008, sei que é um futuro (pouco) distante, mas, gostaria muito de me antecipar...
  18. Sempre me ponho a pensar sobre o projeto NFe para .NET, vejo que está sendo realizado o desenvolvimento do framework, mas utilizando interop, minha preocupação é sobre o futuro do CAPICOM que já foi descontinuado, logo teremos que migrar para novos servidores e já estão sendo reportados problemas com windows 8.
  19. Estou louco para que a NFC-e entre em produção no RJ.....
  20. Brother, se você passar o xml fica mais fácil pra galera testar.
  21. Atualizaram os schemas??
  22. Ele usa o Monitor ou você utiliza o componente no seu projeto?
  23. Olá, Luiz Eduardo, No guia prático, versão 2.0.11, página 179, traz uma tabela com todos os modelos e tipos de documentos utilizados na EFD. Posso estar enganado, mas, ao que me lembro, NFSe não é declarado na EFD.
  24. qual report você utiliza? e, anexe o xml para testarmos..
×
×
  • 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.