strago

Pra usar o ACBr com o emulador, você vai precisar de um "emulador" de portas seriais, da uma procurada no fórum que eu lembro da galera ter sugerido alguns é um programa simples que cria uma porta COM virtual e possibilita que você utilize o emulador com o demo do ACBr sem precisar de cabos especiais, dlls, inis e afins.

Você setou o diretório do ACBr no Library Path do Delphi ? Da uma olhada no Leia-me e confere se você seguiu todos os passos de instalação.

O componente é como uma classe de java, voce cria a aplicação, e "informa" que ela vai usar aquela "classe" no caso do delphi, você seleciona o componente e solta em um formulário ou faz o processo todo em "runtime" (cria o componente e ajusta as propriedades via código ao invés de usar a IDE)

Bem vindo Ricardojp, Vai depender do tempo que você tem para se dedicar ao software, se mora em estados com PAF-ECF vai ter que correr atrás da questão de homologação (processo a meu ver, trabalhoso e caro), entre outros fatores. Eu aconselharia a você a trabalhar com o RAD 2010 como ambiente e ACBr (é claro), RxLib e JCL/JVCL como componentes de terceiros. Banco de dados você tem os "Free" MySQL, Firebird, Postsgres e os "non-Free" SQLServer, Oracle, etc. o site "apostilando" (googlar o termo) tem uma infinidade de apostilas, artigos e tutoriais, você pode olhar também, DevMedia, Fórum Script Brasil, ActiveDelphi, Planeta Delphi, são ótimas fontes para começar. Eu estou concluíndo um software para Materiais de construção, e talvez essas dicas possam lhe ser úteis ... Geração de código de barras interno usando o algoritimo do EAN13 (EX: tampa de vaso sanitario, 4 cores, o mesmo código de barras, porém a cor preta é mais cara, e talvez seu cliente queira um código diferente para ela) Impressão de etiquetas com código de barras (ACBr tem um ótimo componente para isso) ECF/TEF (bem provável com PAF) além de codificar tudo que, mesmo com a ajuda dos componentes não vai ser moleza, tem q homologar o TEF e o PAF/ECF (se o seu estado exigir) NF/NF-e me parece que por enquanto, materiais de contrução "AINDA" não são obrigados a emitir NF-e (MT ainda usa formulário impresso tipo A1), porém isso pode mudar até o final do ano e em 2012 é certeza que já serão obrigados. O detalhe de impostos diferentes para os chamados "materiais básicos" em relação aos outros produtos, pode ser que seu cliente queira trabalhar com duas empresas, para que uma de saida somente dos básicos e a outra do restante dos produtos, se for esse seu caso, terá que pensar em como dividir a nota entre esses dois "tipos" de produtos, para que os básicos saiam em uma nota emitida pela empresa X e o restante em outra nota emitira pela empresa Y Pense que nos PDV ou terminais de atendimento/pedido, que geralmente não são pcs muito potentes, em desenvolver a aplicação de forma mais enxuta possivel ou usar um servidor de terminais. No caso de Servidor de Terminais, você vai ter que dar uma olhada no ACBr Monitor Caso o seus sistema venha a emitir NF-e, pense no SPED, você precisa dar entrada nas notas de compra no sistema para poder alimentar o SPED Bom acho que já "falei" demais Caso precise de ajuda, meu msn [email protected], email [email protected] e skype joaoishiwatari Boa sorte.

Eu acho que o que ele quis saber é se, por ser participante do SAC, ele teria alguma garantia sobre tal trabalho. Você pode solicitar a qualquer membro do ACBr, colaborador ou não, que desenvolva uma ferramenta que você precise mediante pagamento(ou não ;D), independente de estar no SAC, visto que o SAC não presta esse serviço como foi dito anteriormente, ele somente esclarece dúvidas de carater técnico a respeito dos componentes, efetua correções caso seja detectado alguma falha e (me corrija se eu estiver errado) pode acelerar o processo de atualização do componente as novas exigências da sefaz por exemplo. Tudo isso você pode conseguir de graça, porém, sem garantias, seja de atendimento, resolução, prioridade, etc.

Só acharia de bom tom, que os colaboradores efetivos do projeto, ou seja, quem ajuda a manter o projeto funcionando deveria ter um bom abatimento no valor mensal ou ser isento dos valores enquanto fizer parte dos "commiters".

Vamos lá, qual é o objetivo do SAC pago afinal ? ganhar dinheiro com o suporte, independente de qualquer outra coisa OU ajudar a financiar o projeto, remunerando o tempo gasto pela equipe de desenvolvimento/colaboradores ? Dá pra ser os dois ???? eu acho que sim, só falta entender o que realmente está por tras da proposta. Se for pra ganhar dinheiro, então ótimo, definam um preço mensal, pacotes de pagamento com desconto bimestral, semestral, anual e definam as regras de como isso irá funcionar, deixando claro que é um serviço independente do projeto em si, ou seja, quem quiser um suporte especializado nos componentes, paga por isso e quem não quiser, continua dependendo da boa vontade do pessoal do fórum. Se for pra ajudar a financiar o projeto como um todo, cobrir os custos de hospedagem do site/forum, dar uma ajudinha financeira pra quem REALMENTE colabora com códigos para o projeto, então façam como eu sugeri, alguem quer algo pra "ontem", entra em contato com os responsaveis pelo serviço, PAGA pela requisição, e ela seria incorporada ao projeto posteriormente. Se querem os dois, façam os dois um suporte pago independente para ganhar $$ e um serviço de pedidos emergenciais de ajuda para patrocinar o projeto. Bom, mais cedo ou mais tarde, a grande maioria vai precisar de algum tipo de ajuda de emergencia e seria ótimo se alguem estivesse prestando esse serviço. Sem contar aqueles que não tem tempo para "destrinchar" os fontes e entender a fundo o funcionamento de cada componente, precisarão de algum tipo de assistência com relação a isso, então acho que á espaço para ambos os serviços. Independente do que se resolva eu vou continuar apoiando o projeto, ajudando no que eu puder e quem sabe contribuir financeiramente também. Sem Mais João Ishiwatari

Bom galera, o assunto ta rendendo pano pra manga, então eu andei pensado ... e se .... Ao invés de criar um novo fórum pago, e cobrar o acesso a esse novo recurso e as devidas soluções geradas por ele, porque não fazem de forma mais aberta, assim como a GPL propõe ? Crie uma sessão nesse mesmo fórum com acesso somente leitura para TODOS os usuários, quem quiser uma solução rápida ou tiver alguma dúvida urgente, entraria em contato com os responsáveis pela parte de suporte pago, efetuaria a pergunta ou pediria uma resolução de problema e pagaria por isso. A pergunta/probluema e sua respectiva resposta/solução entrariam no fórum apartir de X dias da data da resposta/resolução. Por que eu acredito que essa seria a forma mais "clean" de proceder ? Bom, lendo o tópico todo, eu percebi que, ao criar um novo fórum restrito, os colaboradores atuais do projeto que já não possuem muito tempo disponível, usariam esse precioso e pouco tempo que lhes resta dando mais atenção ao fórum pago, visando uma possível remuneração e o fórum aberto cairia em desuso ou ficaria seriamente defasado, visto que, na sua maioria, as pessoas "usam" o projeto e são muito poucos os que realmente colaboram com ele. Como eu disse no meu ultimo reply, acho mais do que justo ter um tipo de sistema de suporte pago, porém , pensando no lado "ideologico" do négocio do open source, a proposta inicial iria desviar drasticamente o foco dos colaboradores para a solução paga.

Se o forum for pago, as pessoas que não querem pagar ou não "podem" dispor de uma quantia X por mês irão criar fóruns paralelos e como o projeto vai continuar Open, as dúvidas continuarão sendo sanadas, as correções continuarão sendo feitas, enfim, isso só vai servir pra descentralizar o knowledge do projeto. Concordo com a ideia de um suporte pago, a maioria dos softwares open-source tem algum meio de suporte pago, a Canonical oferece esse serviço para o ubuntu, a Oracle para o mysql, enfim, uma coisa é cobrar por um serviço opcional, outra é fechar a base de conhecimentos, seria um retrocesso e acarretaria um atraso gigantesco no desenvolvimento colaborativo. Quanto ao valor, quem somos nós para colocar preço no serviço que nós mesmos não somos aptos/dispostos a fazer ? Como dizia minha avó, cada um sabe onde o calo aperta, se acha que 500 reais por mês é caro, faça uma proposta em particular, nada como uma boa negociação.

EDITADO NOVAMENTE =p Pacote anexado a este tópico é a versão mais recente do componente. Assim que a versão para D7 estiver estável ou pedir o up do projeto no branch do ACBr. EDITADO Fala pessoa, Alguns anos depois de ter postado e a infelicidade de não ter ter continuado o projeto, eis quer surge .... hehe, brincadeira. Mas falando sério, retomei o projeto e estou disponibilizando uma cópia dos fontes (agora com demos). O ACBrAtualização, é um derivado de um componente meu que estou adaptando e doando para o projeto, até agora só pude testa-lo no Delphi 7 e sei que ele irá apresentar alguns "probleminhas" no XE com relação a compatibilidade de alguns métodos (coisa que pode ser resolvida rapidamente mas meu foco ainda está no D7, faltam alguns ajustes para acertar antes de pensar em aparar as arestas para outras versões). Pois bem, Basta instalar o pacote (Compile | Install), definir o librarypath e pronto. Existem 2 Demos no pacote, o primeiro, na verdade é uma vista explodida do componente, onde vocês poderão conhecer todas as propriedades, métodos e eventos, com descrições detalhadas e exemplos de uso. O documento xml ainda não está completo, falta acrescentar os dados dos métodos, mas farei isso rápido. O segundo demo, é um "Gerenciador de Atualizações", um demostrativo de como administrar atualizações de aplicações distintas por uma única interface usando o TACBrAtualizacao. Concluindo, Vou acrescentar um terceiro demo ao pacote, com o uso completo do componente, da criação e publicação de um pacote de atualização a atualização do cliente em si. Caso tenham dúvidas ou alguma dificuldade no uso, ou queiram reportar erros, fazer sugestões é só me mandar um email. [email protected] D7-ACBrAtualizacao.zip

Vou criar um novo tópico com o andamento do projetos, os recursos que compõem o componente, e o cronograma para o término da nova versão. Por favor, fechem o tópico.

o problema é que podem ocorrer falhas no processo de atualização usando o application.terminate. pra tentar contortar isso vou ter que criar um loop no arquivo de lote/bash e um temporizador OU posso usar um: ECHO Feche todos as copias do "APPNAME" em execucao. PAUSE (Pressione qualquer tecla para continuar) implicito do DOS e algo parecido no bash script do linux Não é uma saida elegante porque o compo vai abrir uma tela do DOS/Terminal mas até agora acho que foi o método mais seguro que eu consegui pensar. PS: Fiz um "fork" na ideia do ACBrCNIEE ;D, espero que não fique chateado com isso

Eu vou começar o desenvolvimento das rotinas de envio e recebimento agora, já concluí as rotinas de compressão e descompressão e estão 100%, vou olhar o ACBRCNIEE o problema maior é a questão do Lazarus/FPC no linux, eu uso a API do windows pra matar os processos ativos e arquivo de lote para efetivar as atualizações, se alguem puder ajudar com essa parte, acho que ja posso deixar o componente compativel com o lazarus. tenho algum conhecimento de bash script mas nao sei praticamente nada de expressoes regulares (que seria muito util pra gerar o script de atualização) e eu não sei se o lazarus trabalha com pid files para os binários, se ele não trabalha com os pid, precisarei mesmo usar expressões regurales pra filtrar a saida do comando `ps` para matar o processo do binario. Vou tentar um método tupiniquim pra ver se deixo pelo menos funcional para o lazarus. (e ainda tem o detalhe da permissão para o kill -9 do linux) Acho que vou seguir a filosofia do Jack ... "Vamos por partes ..."

Se puder me informar os erros que ocorreram pra que eu corrija na nova versão ... Se eu puder chutar, é bem provável que tenha retornado erros referente a alguns metodos referentes a indy, se for esse o caso, abra a unit JSi e adicione um {$IFDEF} para a versão do seu compilador onde se encontram as outras condições ja pré estabelecidas.... Agora, se quiser aguardar a nova versão, não estou mais usando a indy nem o tbackup, então esses problemas deixarão de existir.

Estou procurando pessoas que possuam outras versões de delphi instaladas e que estejam dispostas a testar o componente pra mim, coisa simples, se da algum erro na compilação do pacote por exemplo. quem estiver disposto a ajudar, me adicione no msn [email protected] Estou trabalhando na versão nova e quero fazer o upload com tudo funcionando.

Mas como eu havia desenvolvido inicialmente o projeto para uso independente de uma "biblioteca" eu dei preferência os recursos nos quais eu poderia disponibilizar para os possiveis usuários sem maiores problemas, pensando também que a maioria das pessoas tem o indy disponível na IDE. Vou analisar a Synapse e olhar o ACBrEAD para substituir os métodos existentes e colocar os eventos. O demo é tranquilo, vou revisar todo o componente (se me permite ja na nomenclatura do ACBr, e assim que possível vou disponibilizar a nova versão).

Ae pessoal, Primeiro, eu gostaria de saber se estão tento algum problema com a utilização com componente, seja na instalação ou no uso, qualquer dúvida me avise. Segundo, se tem alguma sugestão ou crítica a fazer, fiquem a vontade. Por ultimo, vou começar a manter o componente em Delphi 2010 (RAD Studio 2010). Estou trabalhando na nova versão, mais elaborada e mais intuitiva, assim que estiver concluída eu posto aqui. EDIT - 13/05/2011 - 20:18 GTM -4 Como prometido, Pacotes para versões Delphi 7 e Delphi 2010 no anexo Eu aproveitei pra organizar os arquivos do diretório e corrigir alguns possíveis bugs de compatibilidade, tais como Unit MD5 virou UntMD5, etc. Exclua a versão anterior (caso tenha instalado), selecione o pacote para o seu Delphi, compile e instale.

não seria mais negocio colocar o código numa thread ???

Acho que se você criar uma rotina única para que o cliente execute-a no final do mês para fazer tudo seria a solução ideal ... 1 - Separe os xml por Ano-Mês ou CNPJ-Ano-Mês (caso trabalhe com mais de uma empresa no mesmo local) 2 - Crie uma rotina para compactar as notas do mês especifico 3 - Dê opções para o cliente quando a rotina for executada, para que ele possa escolher como quer enviar as notas para o contador, EX : Salvar arquivo em mídia removível (Disquete, PenDrive, MemoryCard, etc) Enviar para um servidor FTP remoto (disponibilizado pelo contador) Enviar por email (deixar que ele informe o email de destino)

No componente que eu postei no Tópico "Doação de Componente" tem um componente que acompanha o auto-atualizador, a unit BACKUP e os .obj, o componente é bastante fácil de usar e bem rápido. facilita sua vida na hora de "enviar" suas notas para o contador

Outra saída seria organizar por pastas. Na rotina de emissão da NFe você cria pastas como MES-ANO\CNPJ\ para cada CNPJ, sempre que gerar uma nota o sistema verifica se a pasta do mês existe, senão cria, verifica se a pasta do cnpj existe, senão cria, e por fim, copia o xml gerado do local padrão para a pasta final. Quando o contador solicitar os xmls é só copiar a pasta MES-ANO e envia-la, seja por pendrive, cd, disquete, email, FTP ou qualquer outra alternativa. Uma outra ideia referente ao questão envio para o contador, seria o contador disponibilizar um servidor FTP para que você faça o Upload dos arquivos (lembrando que todo o processo de transmissão e recebimento de dados é passível de falhas e pode corromper os dados, e um xml corrompido = NADA)

O que seria muito interessante também seria consulta no sintegra, pra quem precisa de informações para cadastro de clientes para NFe por exemplo, o problema é que infelizmente as páginas do sintegra divergem muito de estado para estado e fica impraticável produzir algo 100% eficaz para todos os casos.

Na verdade essa, a meu ver, seria a solução adotada pelos sites que oferecem o serviço de consultas, salvo que haja "convênios" que tratam diretamente essa questão. Porque para o infoconv, acredito que não importa realmente quem estará de posse das informações no final da cadeia e sim quem as consultou, ou seja, o dono do certificado, se você possui uma empresa com uma carteira de clientes razoáveis onde o custo do certificado poderia ser diluído entre seus clientes, não vejo problema em trabalhar com o "repasse" das informações por um sistema de "camadas" por assim dizer, ou até mesmo uma base de dados paralela tipo knowledge, armazena as consultas já realizadas com um lifetime e caso alguem queira repetir a consulta, nem precisaria acessar o webservice da infoconv. (Partindo do princípio de que maus pagadores são consultados com mais frequência no comércio). O maior problema é que, pelas informações que você passou, não é possível nem testar o serviço para que pudéssemos esboçar um componente.

sem problema, infelizmente ainda não pude fazer as atualizações que eu estava prevendo, mas acredito que até lá eu já tenha feito mais modificações no componente. EDIT 07/05/2011 Hoje efetuei a prova de fogo do componente e é com imensa satisfação que venho informar que o componente de atualização automática funciona perfeitamente. Oito aplicações diferentes Usando 6 servidores distintos Mais de 800 estações Versões de Windows váriadas (XP/2000/SEVEN/W3K TERMINAL SERVER) UPLOAD IDE - Envolve, compressão, hash, dtx e envio ao servidor usando a IDE do Delphi - NÃO FORAM ENCONTRADOS PROBLEMAS UPLOAD Runtime - Envolve, compressão, hash, dtx e envio ao servidor usando rotina de upload - NÃO FORAM ENCONTRADOS PROBLEMAS ATUALIZAÇÃO - Envolve, download do dtx, download do zip, verificação de integridade do zip, descompressão, verificação de integridade dos arquivos descomprimidos, auto-atualizações - NÃO FORAM ENCONTRADOS PROBLEMAS (Somente um detalhe, ao gerar o arquivo de lote para a atualização o componente exibe uma caixa de dialogo informando a ação. Essa caixa será removida). Conclusão : PRÓXIMO DA PERFEIÇÃO EDIT 08/05/2011 É, parecia tudo perfeito mas encontrei um pequeno erro, a rotina que faz a comparação das versões sempre retorna necessidade de atualização do aplicativo.

Na verdade eu presumo o seguinte .... Você como empresa, cria um webserver com apache ou IIS e compra o certificado para esse servidor, e trabalha usando camadas com seus clientes, tipo, app cliente envia a solicitação pro seu webserver que por sua vez acessa o webservice da receita e retorna a informação para o seu cliente acredito que funcione muito bem dessa forma.