Painel de líderes

Bom dia a todos! As perguntas que eu mais escuto no dia a dia sobre o assunto e que eu julgo mais interessante de serem comentadas são: - Qual é a melhor opção a ser utilizada, SAT ou NFC-e? - Como faço para utilizar o SAT em rede 1 para N? E eu sempre dou a maior atenção nas explicações para que fique claro a quem me perguntou e sempre me coloco a disposição para debater caso a caso. Normalmente eu começo pela segunda pergunta "- Como faço para utilizar o SAT em rede 1 para N?" E sendo assim eu explico a dificuldade de fazer um Sistema Gerenciador (Software + Hardware com contingência) que seja economicamente viável. Eu comentei isso no post quem quiser entender meu ponto de vista. Após isso boa parte das pessoas conseguem identificar que é melhor ter um SAT por ponto de venda. Mas é claro isso não é pra todos. E então eu converso sobre a primeira pergunta que e o assunto deste tópico "- Qual é a melhor opção a ser utilizada, SAT ou NFC-e?" Utilizar a NFC-e é uma bela opção. Eu diria que seria o mundo ideal, a perfeição. Porém estamos diante de máquinas, sistemas e meios de comunicação que não são perfeitos nem tem 100% de disponibilidade. Sendo assim para utilizar a NFC-e temos que ter em mente que teremos alguns momentos de indisponibilidade, sejam eles causados pela Sefaz, pela rede interna, pela internet, por uma lentidão no trafego de dados, etc. Sejam eles curtos ou duradouros. E nestes momentos os estabelecimentos deverão ter um meio de gerar cupons de maneira off line para poder continuar operando, seja EPEC ou SAT. Nenhum contribuinte vai querer ficar parado aguardando estabilidade nm sistema on-line onde quer que o problema esteja. Como o melhor meio para emitir cupons off-line no estado de São Paulo é através do SAT o Aplicativo Comercial terá que gerar um novo XML e enviar para o SAT. E assim ter uma resposta instantânea. Você até pode usar EPEC, mas cai nas mesmas possibilidades de disponibilidade de rede, internet e sefaz. Vamos pensar como desenvolvedor em duas maneiras: 1 - Pra quem usa definitivamente o SAT: - Eu já tenho um SAT por PDV. (fui convencido pelo outro post) - Eu desenvolvo um Software que utiliza somente o SAT. - Eu emito as notas de maneira instantânea. 2 - Pra quem usa NFC-e e em contingência usa o SAT. - Eu já tenho um SAT por PDV. - Eu desenvolvi um Software mais complexo que utiliza NFC-e e em contingência utlizar o SAT. - Eu não tenho certeza da disponibilidade da Sefaz, a Sefaz também fica "fora do ar". - Eu não tenho certeza da disponibilidade da minha rede interna, pois pode um dia falhar. - Eu não tenho certeza da disponibilidade da minha internet, pois posso ficar dias sem internet. - Eu não tenho certeza da velocidade da minha internet, pois ela pode ficar lenta, ficar rápida, lenta, rápida, etc. - Quando isso acontecer meu sistema tem que identificar por um "timeout", gerar outro xml e enviar pro SAT. - E então eu emito as notas de maneira instantânea pelo SAT. Ou seja, eu tenho a possibilidade de ter um sistema instantâneo (SAT) e coloco um sistema que eu não tenho certeza por conta da disponibilidade da infraestrutura e quando eu perceber isso eu volto pro sistema instantâneo que eu já tinha disponível??? Até hoje eu ainda não encontrei um Sistema Gerenciador que seja economicamente viável e por isso eu defendo um SAT por PDV e quando tratamos a duvida entre SAT e NFC-e fico ainda mais convencido que utilizar o SAT definitivamente é a melhor opção. Em resumo, pra que trocar o Certo pelo Duvidoso?

Não tem razão... A configuração que me refiro é no ACBrMonitor... Vamos ver se uma imagem esclarece...

eu uso Fortes report com delphi Xe7 e sempre funcionou desde a versão XE4 sempre fiz assim (atualmente estou usando XE5, XE7 sem problemas cada um em uma maquina)

Muitos tem visto que o código dependendo do tamanho do BD do seu cliente algumas operações podem ficar muito lentas. Em especial notamos isso na geração dos arquivos como SPED e Sintegra. Então, na medida do possível, estou analisando aqui alguns métodos que são muitas vezes utilizados e podem fazer grande diferença no código para otimizá-los, fazendo-os serem executados com o mínimo de tempo possível. Especificamente neste caso, as vezes o problema está na constante alocação de memória e redimensionamento das strings. Vejam um exemplo o código do método ACBrUtil.TiraPontos. O método atual é executado várias vezes nos registros Sintegra. A seguinte linha abaixo causa realocação de memória ao redimensionar a string xStr toda vez que é executada: xStr := xStr + str[i] Podemos remover essa realocação por inicializar a string no começo e apenas redimensioná-la no final. Nos meus testes isso reduziu o tempo de execução em pouco mais de 80%. Quer dizer, se você utiliza esse método várias vezes chegando ao tempo total de aproximadamente 1,33 segundos, o tempo gasto depois de corrigido é de menos de 0,23 segundos. Criei o projeto abaixo para demonstrar como isso pode afetar o código quando é executado muitas vezes. Assim outros podem testar e ver a otimização. program project; {$APPTYPE CONSOLE} uses SysUtils, ACBrUtil, Diagnostics; function TiraPontosX(Str: string): string; const InvalidChars : set of char = ['/',',','-','.',')','(',',',' ']; var i, Count: Integer; begin SetLength(Result, Length(str)); Count := 0; for i := 1 to Length(str) do begin if not (str[i] in InvalidChars) then begin inc(Count); Result[Count] := str[i]; end; end; SetLength(Result, Count); end; var st1: TStopwatch; c: Extended; s: string; I,N: Integer; begin try { TODO -oUser -cConsole Main : Insert code here } st1 := TStopwatch.Create; for N := 1 to 3 do begin st1.Start; for I := 0 to 3000000 do begin s := ACBrUtil.TiraPontos('0.0'); end; st1.Stop; c := st1.ElapsedMilliseconds; Writeln(FloatToString(c)); st1.Reset; end; for N := 1 to 3 do begin st1.Start; for I := 0 to 3000000 do begin s := TiraPontosX('0.0'); end; st1.Stop; c := st1.ElapsedMilliseconds; Writeln(FloatToString(c)); st1.Reset; end; Readln; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end. Aproveitei para adicionar alguns testes para esse método específico e não causar nenhum problema ao inserir a otimização. (: Essa não é uma mudança que resolve todos os problemas. O método precisa ser chamado muitas vezes para começarmos a ver diferenças. Mas se fizermos isso com mais funções, com certeza teremos uma execução muito mais rápida. Conseguindo fazer o mesmo com outros métodos avisarei aqui nesse tópico.

Dércio, Sim os endereços apresentados no Portal já são os novos. Inclui esses endereços no componente mas deixei eles comentados. Fonte: ACBrNFeUtil.pas Por favor descomente e realize os testes. Fico no aguardo de um retorno.

Boa tarde, No início deste mês atualizei os fontes do ACBrNFSe (estava na revisão 7877 do dia 28/11/2014) e entao o erro "Assinatura do HASH não confere" voltou a acontecer e não consegui mais enviar (Utilizo o método ACBrNFSe1.Gerar) NFS-e para Itajaí, cujo provedor é o Pública. Contornei o erro voltando a pasta dos fontes do ACBrNFSe para a revisão 7877 enquanto esperava por um tempo livre para encontrar a causa do erro. Hoje encontrei e vim postar para que se mais alguém passe pelo mesmo problema, possa achar uma possível solução, e para que se for mesmo erro no componente, que possa ser corrigido. Bom, na revisão 7907, foi comentado o seguinte código na Unit pnfsNFSeW: procedure TNFSeW.GerarXML_ABRASF_V1; begin //if FProvedor in [proLexsom, proPublica] then // FIdentificador := 'id'; Isso faz com que o XML fosse primeiro assinado e só depois de assinar fosse subistituído a tag "Id" para "id" causando assim o erro de HASH (assinatura ficava inválida também na validação no site da receita), removi o comentário e não deu mais o erro pois então o XML seria assinado e enviado sem modificações posteriores. No Log, o motivo desse código ter sido comentado: [*] Para os provedores Lexsom e Publica o identificador estava sendo alterado para id antes de ocorrer a assinatura. Mas acredito que essa é a forma correta, modificar e então assinar, não o contrario, mas em fim, ficaria grato se alguém puder me informar o motivo de estar dessa forma e se eu estou equivocado, como então proceder para evitar o erro de HASH. Obrigado.

Acho que voce poderia fechar esse tópico Juliomar. Já tem outro tópico com muito mais informações a respeito desse mesmo problema.

Meu, 1o vc não pesquisa direito, depois não le o que foi pedido, leia, vc não fez os passo que foi pedido no post.

Samantha para juntar a sua documentação vc pode baixar a NT2013.005 v1.01 neste link: http://www.sefaz.al.gov.br/nfe/notas_tecnicas/NT2013.005_v1.01.pdf, também está em anexo. (Página 97) como o Italo citou. Porém nas outras versões das NTs constam apenas: | Número da DI / DSI inválido ***Implementação futura | NT2013.005_v1.01.pdf NT2013.005_v1.01.pdf

Boa tarde Samantha, Eu me refiro a versão 1.01 da NT e não 1.02

Complementando o que o Juliomar disse, a NFC-e é usada exclusivamente na venda a consumidor dentro do estabelecimento, então ela não pode ser usada para operações interestaduais e outros. Para estas outras operações use sempre a NF-e.

Você precisa primeiro recompilar o ACBr todo, feito isso abra o formulario onde está o ACBrECF, a mensagem de falta da propriedade vai aparecer novamente, confirme, altere algo no formulario e salve. Recompile o projeto após feito isso.

Fez o que o Italo pediu? e também compilou os componentes novamente?

Boa tarde não existe! precisa do manual deles o schemas e os endereços! pode se basear em algum que seja parecido para implementar depois anexe o código aqui

Vc só encontrou esse item na pesquisa? Deve pesquisa pela palavra chave do erro "FormMsgFonte", e olhe e lei post por post que encontrará.

Bom dia! Além da NT que o Italo citou, caso tenha interesse em ver o que já foi discutido sobre o assunto, vc pode acessar o link abaixo:

Bom dia a todos! Galera, recebi resposta da SEFAZ. Como eu previa, o problema é mesmo com eles. Segue resposta: Senhor Cleber, bom dia! Segue parecer da Superintendência responsável: Nossa área de TI já identificou um erro na validação das NFe emitidas em contingência EPEC, este erro gera a rejeição 467. Estamos providenciando uma nova versão de produção da NFe com a correção deste erro. Solicitamos ao contribuinte que aguarde a nova versão para realizar a transmissão destas NFe. A previsão é que a nova versão seja disponibilizada em produção na segunda feira (27/04/2015). Atenciosamente, FALE CONOSCO - SEF Diretoria de Gestão do Atendimento ao Público Superintendência de Arrecadação e Informações Fiscais Tel.: 155 para todo o Estado de Minas Gerais; (31) 3303-7995 para outros estados e países.

Favor fazer uma pesquisa no fórum, já tem post com a resposta para esse error.

Qual a sua IDE?

Infelizmente não sei... não participo do desenvolvimento do Fortes... Certamente eles devem ter uma área de suporte...

Obrigado Cristiano, seu post foi bem explicativo

Bom dia Samantha, Nota Técnica 2013/005 versão 1.01, página 97 - Anexo X item 01 - Identificador: Numero da DI / DSI.

Para o TEF não fiscal, essa mensagem é mostrado pelo aplicativo e não retornada pelo TEF, para fazer corretamente basta no evento de impressão mostrar a mensagem e tomar a decisão conforme o que o usuário escolher.

Poxa, desculpa. Agora verifiquei no manual e estas tags são de preenchimento do equipamento SAT, por isso não estava funcionando. Valeu!

Não..o ACBr não faz uso das DLLs dos fabricantes... Provavelmente a velocidade do ECF está a 115.200, você precisa configurar isso usando o botão "Serial", na aba do ECF

Pessoal, Hoje fui adicionar o Delphi XE8 na lista. Não sei o que eu fiz de errado, mas acabei zerando os votos... Me desculpem. Todos terão que votar novamente. Já que eu já tinha feito lambança, acabei por fazer uma limpeza neste tópico e colocando os itens em ordem.

Olá, não sei se você conseguiu resolver. Mas tente assim: IF (uf do destinatário)<>(uf da empresa) THEN IDE.idDest := doInterestadual // fora do estado ELSE IDE.idDest := doInterna; // dentro do estado Sem mais Alessandro Esteves - Solução Sistemas

baixe essa versão no svn svn://svn.code.sf.net/p/fortesreport/svn/trunk e faça assim: abra o arquivo RLibWinDXE3.dpk clique com o botão direito em RLibWinDXE3.bpl no lado direito da IDE clique em save as.. e salve com RLibWinDXE7.dpk depois va em build e install eu faço assim e comigo funciona

Conforme prometido, os fontes da biblioteca foram adicionados no Git. Endereço: https://github.com/adeniltonbs/Zeus.Net.NFe.NFCe

Abra o arquivo Fontes\ACBrComum\ACBr.inc e descomente a linha {$DEFINE SoapHTTP}, dê um build all no seu projeto e tente enviar novamente.

Eu penso que o fisco não tem como utilizar este campo via sistema do contribuinte. Ele provavelmente é usado para algum tipo de carimbo, selo, autenticação etc, porém pelo agente e/ou posto de fiscalização. O Governo de SP chegou a exigir um selo de controle através do DECRETO 48.475/2004 e foi revogado pelo DECRETO 49.115/2004, permanecendo apenas a exigência da informação do código do posto fiscal e não tenho mais informações mas penso que também já foi revogado e mesmo que não tenha sido, acredito que este tratamento era para os modelos 1 e 1-A. Enquanto isto acredito que podemos tomar como base o próprio manual de integração que consta na sua página 92 Obs.: Emboras a TAG é criada, ela faz parte apenas do XML e consta no quadro Informações Complementares do DANFE, portanto não indo para o quadro "Rervado ao Fisco". Item seguinte, mesma página. Portanto pelo que entendo este quadro não deve ser preenchido pelo sistema do contribuinte. Para os que usam os fontes do projeto ACBrNFe até podem criar uma opção alterando os fontes do sistema e assumindo a responsabilidade, uma vez que os fontes orinais não possuem esta opção. Para os que usam o modo compilado ACBrNFeMonitor não existe possibilidade de imprimir neste campo. Caso você tenha um conhecimento maior sobre o assunto e alguma base legal que entre em discordância com o Manual de Integração, por favor compartilhe conosco. Em se tratando apenas de uma curiosidade o que posso compartilhar é isto que descrevi e também dizer que possuo pouco conhecimento sobre o assunto e fico torcendo para que a nossa legislação um dia venha a ser mais simplificada e de fácil interpretação.