bnobre

Olá Waldir, Testei em duas máquinas aqui no laboratório e funcionou de primeira, sem demoras, agora irei levar aos clientes. Muito obrigado mesmo, "quebrou uma árvore". Só me tira uma dúvida sobre os parâmetros... O primeiro é o Host, óbvio. O segundo provavelmente é o timeout, correto? Coloquei aqui 300, que suponho serem 300 milissegundos. O terceiro se trata do que? Qual valor devo colocar? Abraços e novamente obrigado

Olá EMBarbosa, tudo bom? Eu já havia visto esse tópico, com o WMI ocorre a mesma lentidão as vezes, o que sugere que ele não obedece o timeout especificado. Com a API do Windows, não consegui fazer rodar, estou tentando com o código do link abaixo: http://www.delphipages.com/articles/ping_without_raw_sockets-9220.html Você já precisou realizar um teste parecido? Obteve exito com o timeout? Se sim, peço que poste seu código como exemplo. Desde já agradeço a atenção

Olá a todos, Possuo um sistema de emissão de NFC-e e quero que o mesmo funcione caso o servidor pare de funcionar, para isso gravo as vendas localmente e conforme o servidor esteja online eu dou carga nele. Até aí tudo bem, mas para saber se devo dar carga, preciso checar se o servidor está online na rede. Uso o Delphi 2010 e estou usando o seguinte código para a checagem: O problema é que nem sempre leva os 300 milisegundos especificados para ele desistir do ping e avisar sobre a desconexão do servidor. As vezes leva segundos. Alguém saberia como resolver essa lentidão e fazer o comando obedecer o timeout especificado? Desde já agradeço a atenção de todos

Valeu Fabiano, vou testar aqui. Vi outra diferença aqui e quero comentar, de repente ajuda mais alguém aí com o Zeoslib na migração. Um dos meus projetos tinha algumas tabelas com campos que o Zeos sugeria como READONLY, creio que pelo fato de serem campos dinâmicos como os campos "tipo" e "serial" abaixo: No Delphi 7 com Zeoslib 6.6.2-RC, sempre atribui valores para esses campos e o ZQuery aceitava de boa, mesmo estando marcados como ReadOnly. Agora no Delphi 2010 com o Zeoslib 7.1.4-stable ele dá erro, dizendo que o campo não pode ser modificado. Na verdade esse erro é o certo, dado o campo ReadOnly como True, mas na versão antiga do Delphi/Zeoslib ele aceitava. Outra diferença que eu vi também foi em uma tabela que eu tenho um campo chamado "to", referente ao estado de Tocantins. Mesmo se tratando de uma palavra reservada na versão antiga do Delphi/Zeoslib ele aceitava, agora dá erro no ZUpdateSQL, tive que mudar para outro nome. A princípio é isso, observando novas necessidades informo aos amigos.

Olá Fabiano, tudo bom? Rapaz, eu migrei do Delpi 7 para o Delphi 2010 também sem muitas complicações. Assim como no seu caso, o Delphi 2010 reclamou do tipo dos campos Fields gerados pelo Zeoslib, e assim como você tentei utilizar o localizar e substituir tudo de TStringField para TWideStringField. Mas no meu caso fiquei recebendo o erro1.jpg em anexo. Ao responder YES ele tenta marcar o field novamente como TStringField na unit e ao responder NO ele deixa como está, mas no Object Inspector (erro2.jpg) ele continua como TStringField e ao compilar acabo recebendo o erro3.jpg. Para resolver tal problema tive que ir em cada ZQuery e apagar todos os fields de cada uma, e depois inseri novamente (CTRL + F), forçando o componente criar os fields com o tipo correto, no caso TWideStringField. Só que desse jeito é bem mais demorado. Como você conseguiu só pelo Localizar/Substituir? Abraços

Olá a todos, parece que meu temor foi exagerado. Aparentemente meu projeto de NFCe já está compilando normalmente no Delphi 2010, acabei optando pelo 2010 por conta de alguns componentes de terceiros. A questão é que observei a presença de alguns alertas do tipo " W1058 Implicit string cast with potential data loss from ‘string’ to ‘AnsiString’". Ao usar o "Analyse to Project" do menu Project, observei que tais alertas também estão presentes em várias units do projeto ACBr. De acordo com o link http://www.andreanolanusse.com/pt/delphi-unicode-entendo-os-avisos-warning-do-compilar-sua-aplicacao/, posso ter problemas caso ocorram a presença de caracteres WideString(padrão default agora no 2010) indo para o AnsiString(padrão default do 7). Alguém está tendo problemas de perda de dados com isso? Eu creio que não, pois como mencionei o próprio projeto ACBr apresentou diversos alertas. Desde já agradeço a atenção de todos

Olá Daniel, bem observado... Acha que tenho mais a ganhar com Lazarus ou Delphi?

Sim Juliomar, infelizmente apesar de frequentar constantemente como pode observar pelos meus posts (inclusive alguns trocados contigo), só vi agora, mas como eu disse não adianta "chorar o leite derramado". Também vejo como uma oportunidade, assim como disse. Mas como falei, preciso de um princípio para dele deslanchar, construindo algo o mais estruturado possível para não ser pego de surpresa novamente no futuro e ter que mudar tudo...O que acha... Lazarus ou Delphi? Prós e contras de cada um. Desde já agradeço a atenção

Obrigado pelas palavras Waldir, estou tenso aqui. Mas tenho certeza que tirarei algo de bom nisso, assim como todos os outros, que é a mudança para uma plataforma mais atualizada. Estou precisando de umas dicas para saber qual plataforma trilhar esse caminho, caso esse não seja o tópico mais apropriado peço desculpas desde já. Estou tendendo para o Lazarus, apesar da dificuldade do Jedi, devido o fator financeiro, mas fico receoso de o projeto entrar em desuso por ser Free e depois ficar "a ver navios". Quanto ao Delphi o problema é o valor. Alguém sabe os benefícios obtidos pela aquisição do mesmo, além claro de poder utilizá-lo? E as diferenças entre as vezes que oscilam de R$ 2.000,00 até R$ 10.000,00? Desde já agradeço a atenção de todos

Acabo de tomar um "tapa na cara". Eu sabia e me adaptei a mudança do trunk, do novo fortes, da nova pasta Schemas, mas NUNCA reparei na questão do fim do suporte ao Delphi 7. Soube agora através de um e-mail da TecnoSpeed anunciando que o ACBr não daria mais suporte ao Delphi 7. Imaginem como estou "sem chão", pelo que li no tópico muita gente ficou desesperada com 6 meses de antecedência, e eu vou ter que começar agora. Mas não adianta mais chorar o "leite derramado"... Agora é bola pra frente e dar meu jeito, mas gostaria da opinião de vocês para me colocarem no melhor caminho. Como programador só tenho experiência no Delphi 7, é a única linguagem que conheço e trabalho há 10 anos e por isso quero a sugestão de vocês. Ou eu migro para um novo Delphi ou migro para o Lazarus. Os 2 componentes de terceiros que mais uso é o Jedi VCL e o ZeosLib... O Zeos já verifiquei que tem suporte até o X7 e Lazarus, o que torna necessário que use o Delphi XE7 caso opte pelo Delphi. O problema é que o Jedi apesar de ter suporte até o XE10, não suporta o Lazarus a principio, pois andei olhando "por alto" que alguns conseguem fazer ele rodar de forma alternativa Pois bem, dado essas características de experiência com o visual e programação no Delphi 7 e componentes citados, qual seria a melhor escolha para mim? Estou muito preocupado por isso, pois será um caminho árduo, portanto quero optar o que me dê menos dor de cabeça agora e a longo prazo. Desde já agradeço a atenção de todos

Olá a todos... Uso o ACBrBal para a leitura de pesos da balança através da propriedade ACBrBAL1.LePeso( 2000 ); O problema é que as vezes o comando é executado quando a balança está estabilizando ainda, e nada é lido. Como fazer para ao efetuar a leitura ele aguarda a estabilização da mesma? Desde já agradeço a atenção de todos

Olá a todos, Sou do RJ e acabo de desenvolver um emissor de NFe, mas ao observar outros emissores existentes no mercado eu constatei que quase todos preenchem informações automaticamente no campo "Informações Complementares", mas sem padrão... tais como: Lei 5817/10 PROCON-RJ: Rua da Ajuda, 05 - subsolo - Central do Brasil - Rio de Janeiro - RJ - Tel 151 - ALERJ T. 0800-282-7060 R. ALFANDEGA, 8 CENTRO RJ APROV. DO CRED. DE ICMS NO VLR DE R$ 0,00 CORRESPONDENTE A ALIQUOTA DE 0,00 %, NOS TERMOS DO ART. 23 DA LC 123. Vendedor : 1 Cliente : 1171 DINHEIRO Obs Total Aprox. Tributos NF: R$:159,24 Segundo a Fonte IBPT. Valor aproximado dos tributos: R$ 133,68 (33,42%). Fonte: IBPT. Dentre outras... A questão é... pela lei atual, que texto devo colocar obrigatoriamente nesse campo??? Desde já agradeço a atenção de todos

Olá... Rapaz, no momento que você consegue fazer o envio ONLINE da sua nota, que inicialmente foi emitida OFFLINE, o próprio componente salva o XML com o protocolo no diretório especificado por você. Dá uma conferida ai

Entendi. Mas em que categoria entra o 12029, falha de internet ou timeout (buraco negro)?

Acho que por aqui matamos. Para fechar bem Régys... Sei que o 12002 é do timeout, pois sempre que tenho essa problemática, é com esse código. Pela leitura de suas descrições acima, o 12007 seria o de falha de internet. Estou certo? E em que categoria entra o 12029, falha de internet ou timeout (buraco negro)?

Acho que "matei" o problema através do vídeo https://www.youtube.com/watch?v=znVzIe8T4PE. E a solução é mais uma questão de não observar o óbvio do que pode ser feito. Se observarem o vídeo e trazerem a nossa realidade do ACBR, a contingência só pode acontecer através de 2 motivos: 1 - Falta de internet 2 - Timeout (ou o tal BURACO NEGRO citado no vídeo) No caso da falta da internet é fácil, emite em contingência e pronto. Pois temos a certeza que a nota não foi autorizada. No caso do Timeout, não sabemos o que aconteceu. O problema está no tratamento que damos a ela, pois nós emitimos ela em contingência, entregamos para o cliente e REZAMOS para que ela realmente não tenha sido autorizada. O que o Claudenir faz no vídeo é uma grande "sacada". Como ele não sabe o que aconteceu, ele pula o número e já emite direto em contingência, para ter certeza que essa nota realmente não foi autorizada. Aí depois ele checa o que aconteceu com a anterior, se autorizou então CANCELA, se não, INUTILIZA. Pronto. Cliente com chave certa, QR Code certo, além de nossa aplicação está com a base certa. Acho que fechamos a problemática. Agora surgiu outra... Como diferenciar o erro se é de internet ou de timeout (BURACO NEGRO)?

Olá flavio80s... Sobre seu comentário: Está errado. Segue abaixo: Portanto na verdade os mesmos problemas que terei em relação a internet no modo SINCRONO, também terei no modo ASSINCRONO, mas ao meu ver, com uma menor complexidade de tratamento. Observe, no primeiro (Sincrono) eu envio e já recebo a resposta se deu tudo certo ou não. Se deu algum problema envio em CONTINGÊNCIA (envio offline e imprimir duas vias - Cliente e Estabelecimento) e continuo vendendo. No segundo (Assincrono) eu tenho que enviar, consultar o recibo e só depois, da mesma forma, checo se deu algum problema e envio em CONTINGÊNCIA e continuo vendendo.

Caro magnosystem, grato pela resposta. Mais tem um detalhe, eu só trabalho nos PDVs em modo SINCRONO e mesmo assim tenho esse problema, em todos os meus clientes. É relativo, com a internet boa a incidência é menor, mas com a internet ruim (por exemplo o 3G que aqui é péssimo) a incidência é bem maior. Outro detalhe, assim como o Régys questionou... Porque é inviável trabalhar nos PDVs somente em modo síncrono???

Bom dia Então Dércio, mas como não temos plena certeza, nem vale a pena fazer a alteração sugerida por você. Pois imagina se colocamos para dia 03-11-15 o componente gerar a tag do QRCode e a SEFAZ adia?!?! Vai ser o "caos na Terra".

Olá magno...Grato pela explicação... Mas me tira outra dúvida... Não entendi o comentário desse seu except: Except //exceção muda para pegar o cstat em seguida. End; Como assim? O que aconteceria ou eu deveria fazer aqui dentro? Não deveria ser o comando abaixo a entrar nesse except, pois quando tentasse enviar dinovo (dessa vez como online) daria outra exceção de duplicidade, nesse caso com mesma chave - cstat 204 if NFCE.WebServices.Enviar.cStat = 204 then //marca a flag da nota como enviada. Outra questão que já apontei até nesse outro tópico criado por mim http://www.projetoacbr.com.br/forum/topic/24237-nfc-e-em-duplicidade/. Esse negócio de enviar a nota em modo SINCRONO e não receber o retorno acontece direto comigo nos clientes, aí fiz igual você falou, coloco em CONTINGENCIA, pois não sei o que aconteceu com a mesma e libero o cliente. Quando a internet volta eu tento enviar em contingência e descubro que ela havia realmente sido enviada ONLINE na última tentativa, pois dá erro de Duplicidade com Chave Diferente, troco o XML para online e envio dinovo, dá erro de Duplicidade com a Mesma Chave, tenho certeza que a nota já havia sido enviada e como ONLINE, marco como ONLINE na minha base e pronto. Aí que está a questão. Na minha base está tudo certo, mas o DANFE que o cliente levou nesse caso está com chave errada e QR Code errado, ele nunca vai conseguir consultar com esse DANFE que levou errado como CONTINGENCIA. Está certo o meu raciocínio? E se sim, ficamos a mercê da sorte nesse caso? De ante mão já agradeço a sua atenção

Olá Dércio, tenho acompanhado o seu tópico e assim como você, me preocupa o fato de ter que mudar o executável apenas no dia 03-11 para todos os clientes. Mas tenho outra preocupação...Sou do RJ, que pelo o que o Italo falou usa os Servidores do RS... E se no dia 03-11 essa mudança não estiver realmente pronta e a produção continuar negando as notas com a informação do QR Code?

Caro Magno, Agradeço o seu tópico, está me dando uma "grande luz". Estou com um sério problema nos meus clientes que cai na situação do seu "pulo do gato". Eles enviam a nota em modo SINCRONO e devido a problemas de conexão eu não tenho o retorno positivo da mesma. Antes eu cancelava a gravação na base e perdia todos os dados da venda. Agora estou seguindo a sua dica e jogando em contingência. Como você falou, ao tentar enviar a contingência, recebo o erro Duplicidade com chave diferente, pois a nota pra mim está como OFFLINE e para a SEFAZ está ONLINE. Até aí tudo bem. Dai para frente que eu não entendi o seu exemplo. Você orienta gerar a mesma novamente de forma ONLINE e enviar... mas aí não vai dar Duplicidade com a mesma chave? Você poderia postar o seu código frisando essa parte? Seria de grande ajuda Desde já agradeço a atenção

Olá a todos, Estou desenvolvendo um emissor NFC-e, e pelo que observei em alguns exemplos de XMLs sobre o cálculo do valor do ICMS para empresas de CRT normal é o seguinte: Se eu tenho um produto de R$ 15,00 e uso 60 % de Base de Cálculo, tenho R$ 9,00 de base para o cálculo do imposto. Com 17% de alíquota de ICMS sobre esses R$ 9,00 de Base de Cálculo, teria que pagar R$ 1,53 de Valor do ICMS. Minha primeira dúvida é: Nesse exemplo que dei, os valores estão corretos? É assim que se calcula? Minha segunda dúvida é: Observei esses cálculos em empresas de CST 00 e 10. Sei que em outros CSTs outras informações são obrigatórias como Reduções, ICSM ST e etc, mas o cálculo de BC, alíquota de ICMS e valor de ICMS funcionam da mesma forma??? Desde já agradeço a atenção PS: Se alguém tiver algum material interessante com exemplo de cálculos de tributos de NFC-e e NF-e peço que mandem.

Grato amigo, muito bem explicado!!!!

Realmente amigo, estou muito desatualizado mesmo. Quanto a desenvolver, o meu medo é ter que ficar atualizando sempre o sistema devido a schemas de validação que mudem frequentemente ou outros detalhes... Isso acontece com muita frequência??? Pois se ocorrer nesse momento não poderei dispor de tempo para dar tal manutenção, daí a terceirização ser uma opção viável para mim, pelo menos nesse momento. Mas se isso não ocorrer, vale a pena eu "resolver" com uma ferramenta própria aliada aos componentes da comunidade.