Painel de líderes

Bom dia a todos, Acabo de enviar para o Repositório a implementação do provedor SP destinado a cidade de São Paulo. Não realizei testes, somente de compilação do componente, sendo assim não existe erros de sinaxe, mas pode ocorrer erros de lógica. O provedor foi implementado conforme o Manual Nota Fiscal Eletrônica de Serviços versão 2.4.2 Não tenho condições de realizar testes de envio, consulta, etc. deixo a cargo dos demais colegas. Não foi utilizado nenhuma DLL a não ser as que já fazem parte do projeto ACBr. Vamos torcer que as assinaturas sejam realizadas conforme esperado pelo provedor.

Você tem que sempre ter em mente o seguinte: 1. AnsiString é a String antiga dos Delphis não Unicode, na maioria dos casos é desnecessário utilizá-la, mas isso vai depender do seu código. 2. Em Unicode cada caracter é representado por 2 bytes, um para o caracter e outro para a página de códigos, por isso em alguns casos corta ou um loop não lê toda a string, mais uma vez, depende da forma como foi implementado o método. 3. Um livro bom para entender o Unicode é o: "Recursos Avançados do Delphi", ele possui 1 capítulo inteiro somente sobre Unicode. Segue outros links sobre o assunto: http://blog.marcocantu.com/blog/d2009_whitepaper1.html https://www.embarcadero.com/images/dm/technical-papers/delphi-unicode-migration.pdf https://www.embarcadero.com/images/pdf/Delphi-Unicode181213.pdf

Regys, muito obrigado pela retorno, Deus seja louvado através de sua vida... Muito obrigado Mesmo Daniel respondeu de uma forma direta, obrigado meu amigo...!! Responta que precisava, acabei aqui descobrindo isto na prática, tenho um .exe responsável por códificar / decodificar texto para meu sistema, ao migrar ele para XE "Unicode" usei AnsiString e String... Usando String ao decodificar não voltava para o mesmo texto, alguns caracteres eram perdidos, dai cheguei a conclusão do Daniel, agora ele com sua vasta experiência evidencia o que notei aqui... Muito obrigado a todos, e em parte pressão de vocês me vez evoluir estou satisfeitíssimo com todos os meus projetos na plataforma XE.

Use obrigatoriamente "AnsiString", quando estiver manipulando "buffers" ou conteúdo binário (caracteres não legíveis) Por exemplo, no ACBrECF, recebemos muito caracteres de controle do protocolo (ETX, STX, NUL)... Nesse caso é necessário o AnsiString...

Parabéns Italo!

Boa noite a todos, O ACBrNFe também dispõe do método DistribuicaoDFe que também baixa da SEFAZ o XML completo da NF-e. Esse método também necessita que a empresa que deseja obter o XML tenha o Certificado Digital.

Eduardo, Se está começando, sugiro que implemente por socket em TCP/IP. A comunicação é mais rápida e dispensa a manipulação de arquivos. Eu tinha esse problema, meu log ficava cheio de mensagens de falha de acesso aos arquivos... Com TCP/IP, o log fica limpinho, as operações fluem com mais rapidez. Tenho um único servidor trabalhando para gerenciar as notas fiscais da matriz e de 10 filiais em tempo real sem nenhum problema.

Acabei de Fazer o teste aqui a DANFE Fast Funciona 100% exatamente como eu preciso, agora é pensar em adquirir o componente R$(Dilmas)800,00

Prezados, Encontrei os seguintes links que podem ser úteis para quem cair neste tópico buscando informações sobre a emissão de GNRE para ES, SP e RJ. Para o RJ, cheguei no seguinte link que explica o funcionamento do webservice desta UF. http://www.fazenda.rj.gov.br/sefaz/content/conn/UCMServer/path/Contribution%20Folders/site_fazenda/informacao/cadastro/arrecadacao/documentos/transmissao.html Para o SP, cheguei no seguinte link para processamento de arquivo de lote. E em anexo está o DOC do manual citado no link. O link é um executável que descompacta o DOC. https://www.fazenda.sp.gov.br/guiasinternet/gare/paginas/lote.aspx Para o ES, o link é o que segue. http://app.sefaz.es.gov.br/DuaPortal/ Ainda não implementei nada referente a estes três serviços. Mas creio que já serão de grande ajuda aos colegas. guias_lote.doc

Infelizmente tem locais onde não atualizam o windows. Vários clientes ainda com Windows XP, também, apresentam o mesmo problema em relação ao horário de verão, pois o Windows "acha" que o horário de verão terminou dia 14. A solução tem sido alterar o fuso horário das máquinas para -2 temporariamente, o que seria melhor resolvido se o UTC pudesse ser atribuído pelo próprio sistema, e utilizar a informação do windows de forma opcional.

Boa tarde Daniel.... Pesquisei e encontrei algumas informações sobre o serviço do Gmail gratuito para envio de emails. Utilizei a opção do link abaixo para liberar a conta para outros aplicativos e o processo funcionou corretamente... Acessar o link abaixo e habilitar a opção Ativar https://www.google.com/settings/security/lesssecureapps Obrigado pela força Daniel...

Show Sérgio, valeu a dica!

Daniel, era a quantidade com 4 casas depois da virgula, corrigido e BINGO anexo o XML assinado na homologação. Vou preparar atualização do monitor para os clientes e espero ter concluído mais essa saga. HASA AD35160208723218000186599000040220005060357673.xml

Pedron, Ótimas ideias... acho que podemos manter uma String para o "TimeZone"... e ela pode ser Published... no SetTimeZone, escrevemos um código para saber se o usuário está passando um valor válido...

Na verdade, o ideal seria ter um jeito de passar uma configuração de TimeZone completa (como a que o próprio ACBr pega do Windows), o que incluiria fuso e horário de verão, por exemplo, (entre outros detalhes)... Mas aí fica mais complicadinho de implementar como propriedade published no componente... Teria que ser algum public mesmo, pra passar na mão...

Opa, muito obrigado, copiei as DLLs para a SysWow64 e funcionou de primeira. Muito obrigado, fiquei quebrando a cabeça ontem o dia inteiro hehe.

Sempre é bom dar uma pesquisada.

A princípio havia pensado num Integer, mas aí não daria pra deixar vazio... Talvez uma string mesmo, onde fosse informado '-2', '-1', ou '' (vazio). Nessa idéia se a string foir vazia o comportamento do componente permaneceria o mesmo Poderíamos fazer também um tipo enumerado... Colocando todos os possíveis fusos do Brasil, algo como TAcbrUTC = (utcNenhum, utcMenos3, utcMenos4). Nessa idéia o utcNenhum assumiria o comportamento atual do Acbr. Sobre o local da propriedade, poderia ser lá nas configurações do WebService (algo como "Configuracoes.WebServices.FusoHorario"), me parece que dá mais certo... Enfim, estou aberto a sugestões...

Terá que escolher um que se assemelha e usar ! Faz uma aplicativo de teste bota rodar e já vai ver se funciona como você quer

Complementando essa situação, analisamos o código fonte do MonitorPlus e verificamos que no DoACBrNFeUnit.pas nos métodos 'criarnfe' e 'enviarnfe' existe uma chamada para ConfiguraDANFe(False, False). Para efeitos de testes comentamos essa chamada nos dois métodos e o communication error passou a ocorrer apenas no 'imprimirDanfe', que é a situação correta. Seria possível colocar uma alteração neste sentido no monitor? Como utilizamos apenas para emissão de NFCe não sei dizer se isso tem impacto na NFe. Anexei o arquivos conforme modificamos. DoACBrNFeUnit.pas

Por essas e outras, que recomendo apenas A1 e OpenSSL... onde esses problemas de certificado, não existem...

Mais um ponto de preocupação (além do Switch e cabos de rede)... se a máquina do Servidor SAT para... TODOS os caixas morrem... Sei que não é simples desenvolver um servidor desse nível...e deve ser muito bacana ver ele funcionando... mas sinceramente... acho que isso é "economia a base da porcaria"... eu não entro nessa conversa do Cliente... Seu cliente pode achar que está economizando... mas no dia que der um problema em um dos componentes cruciais...e ele ter prejuízos e reclamações, ele vai querer achar um culpado... mesmo que o motivo seja a queima dos equipamentos por descarga elétrica... Bom... acho que já deixei claro meu ponto de vista... vou parar de monitorar esse tópico...

Boa tarde Cesar, Que eu saiba o idToken não pode ser "000000" e sim: "000001" ou "000002" ou ....

D7 já está morto faz tempo... não faz sentido ficar preso ao passado... para quem tem como descupa o custo de uma nova IDE, hoje em dia o Lazarus/FPC é muito melhor do que o D7, e "de grátis" (na DJSystem já usamos o mesmo a anos)... Os novos Delphis XE, são fantásticos, e ainda compilam para Mobile... sinceramente, não vejo porque ficar preso ao passado

Boa tarde senhores. Estou precisando trabalhar na minha empresa com duas versões da Bemafi32.dll da Bematech, por ter encontrado problemas ao usar a dll versão 7 com IFs do convênio anterior ao 09/09. Para tal, criei uma subpasta para armazenar a Bemafi32.dll versão 7 (convênio 09/09). Após criar o componente AcbrECF, atribuo o valor dessa subpasta à propriedade "AcbrECF.ECF.PathDLL". ECF := TACBrECF.Create(Application); ECF.Modelo := ecfEscECF; ECF.ECF.PathDLL := ExtractFilePath(Application.ExeName)+'bematech09\'; Se eu verificar o valor da propriedade antes de chamar qualquer função, está lá o valor que atribuí, porém, na classe da bematech (ACBrECFBematech) onde dá a carga nas funções da dll, o valor de "PathDLL" está zerado, então não é considerado o valor por mim atribuído: procedure BematechFunctionDetect( FuncName: String; var LibPointer: Pointer; LibName : String = cLIB_Bema ) ; var sLibName: string; begin if not Assigned( LibPointer ) then begin // Verifica se exite o caminho das DLLs if Length(PathDLL) > 0 then sLibName := PathWithDelim(PathDLL); Tentei verificar no código mas não encontrei nada de estranho. Alguém tem alguma ideia do que pode estar acontecendo? Estou atribuindo o valor para a propriedade errada? Ou a classe da bematech estaria olhando para a propriedade errada? Agradeço desde já!

Olá boa noite a todos, Alguém já teve problemas para iniciar o ativador? Na minha maquina só aparece um logo da nota paulista.