Painel de líderes

Bom dia colegas. Antes de tudo, leiam este tópico do Juliomar. Quando o cliente reclama a "exclusão" do certificado, é o nosso sistema que causou o dano. Quando dá erro no sistema operacional, é o nosso sistema que está com problema. Quanto o erro é mau funcionamento do hardware, é o nosso sistema que está comportando de forma errada. Sem contar que, até mesmo quando a impressão não sai, é o sistema que está com problemas. Ora, para isso a resposta é bem simples! É o nosso sistema que está em uso em noventa por cento dos casos, e, quando algo não está correto, é certo que o cliente vai reclamar, e, neste caso será conosco. Mas vamos por parte. Quando nos ligam, informando sobre um determinado problema, creio eu que “eles” acreditam que somos magos, ou seja, basta dizer que ao tentar fazer uma nota deu um erro, mas não diz exatamente os passos que seguiu até o tal erro ocorrer. Não diz que, ao tentar assinar a nota por exemplo, ao ser solicitado a senha do certificado, ele digitou várias vezes, que, ao digitar não observou que o “Num Lock” estava desligado etc. Não diz também que, a leitora do tal certificado está inserida na usb frontal, ou em algum adaptador, enfim, uma série de informações que são de extrema necessidade que neste caso é você que tem que solicitar para chegar a uma conclusão de que, o problema não está no sistema e sim, nos periféricos. Por fim, foi que fiz com um cliente. Ao ser indagado de que o sistema teria “excluindo” o certificado, argumentei que o sistema não faz isso, apenas lê a informação da chave, foi aí que o cliente disse que foi a certificadora que lhe disse. Diante disso, entrei em contato com a certificadora e pedi para falar com o setor responsável, e, solicitei que fosse emitido um laudo assinado informando exatamente em que momento o meu sistema excluiu a chave do certificado. Neste momento o responsável começou a gaguejar, disse que era apenas uma suspeita e que não teria como fazer tal laudo. Diante da impossibilidade de elaborar tal laudo, pedi para que ele então elaborasse um documento afirmando que foi o sistema que excluiu o certificado. Mais uma vez, negativo. Importante ressaltar que, a prova incumbe a quem alega, se afirmar que foi o meu sistema eu exijo que o faça por escrito, que prove, caso contrário, seque cogite esta ideia, foi o meio que encontrei para solucionar de uma vez por todas estas desconfianças. Espero que ajude alguém.

Bom dia a todos, Será que é tão difícil pesquisar aqui no fórum? Esse assunto já esta sendo tratado a pelo menos 2 meses. Vocês notaram que existe uma propriedade de configuração que determina se o QR-Code será incluído no XML ou não? Se tratando de ambiente de homologação devemos solicitar a inclusão, caso contrario a nota será rejeitada. Por outro lado ao enviar para o ambiente de produção, não devemos incluir, pois o mesmo ainda não esta preparado para receber essa informação no XML.

Porque a minha aplicação, quando compilada no Trunk2 exige as DLLs do XMLSec ? O Trunk2, tem a habilidade de suportar OpenSSL (XMLSec) e CAPICOM, na mesma aplicação... e no ACBrNFe, existe a Classe TDFeSSL, que permite configurar qual será a biblioteca de SSL em Design ou Run-time Para isso, basta mudar a configuração usando comandos como abaixo: ACBrNFe1.Configuracoes.Geral.SSLLib := libOpenSSL; ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicom; ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicomDelphiSoap; // Mesmo que "libCapicom", mas usando a Indy Porém, para efetuar essa "magica", precisamos compilar todas as Units que dão suporte a CAPICOM e OpenSSL\XMLSec, e elas injetam a dependência de DLLs externas Porque eu usaria o suporte a OpenSSL ? O OpenSSL é ótimo para certificados do tipo A1... pois você não precisa instalar o certificado no Windows... basta apontar o caminho do arquivo PFX e a Senha: ACBrNFe1.Configuracoes.Certificados.ArquivoPFX := edtCaminho.Text; ACBrNFe1.Configuracoes.Certificados.Senha := edtSenha.Text; Porque remover o suporte a uma das bibliotecas de SSL ? A desvantagem, é que a sua aplicação agora ficou dependente de mais DLLs, e para alguns pode ser um problema, distribuir e instalar as mesmas Onde eu encontro as DLLs ? \ACBr\DLLs\OpenSSL \ACBr\DLLs\XMLSec Para onde eu copio essas DLLs ? Você deve copiar TODAS as DLLs das pastas acima indicadas (e não apenas algumas). Você pode copiar para a mesma pasta da sua aplicação .EXE ou para o "System" do Windows Observe que, essas DLLs são 32 bits, e portanto só funcionarão para aplicações compiladas com um compilador 32 bits (que é o padrão para Delphi e Lazarus)... Uma aplicação 32 bits roda em um S.O. 64 bits, mas o oposto não ocorre... Considerando que essa DLLs são 32 bits, então: Se o seu Windows for 32 bits, copie para a pasta: C:\Windows\System32 Se o seu Windows for 64 bits, copie para a pasta: C:\Windows\SysWOW64 Se você estiver instalando DLLs de 64 bits em um Windows 64 bits, então a pasta correta é: C:\Windows\System32 (vai entender... pergunte pra Microsoft) Como eu removo a dependência ? Nunca usou o OpenSSL ? Nunca deseja usar ? Então você pode remover o suporte do ACBr ao OpenSSL/XMLSec, e com isso, remover a dependência de sua aplicação das DLLs do XMLSec.. Edite o ACBr.inc... Observe que no inicio do mesmo, existem as linhas abaixo: {.$DEFINE DFE_SEM_OPENSSL} {.$DEFINE DFE_SEM_CAPICOM} Apenas remova o ".", se quiser ativar a remoção... {$DEFINE DFE_SEM_OPENSSL} Por que mesmo assim, a sua aplicação fica dependente das DLLs do OpenSSL (libeay32.dll, ssleay32.dll) ? O ACBr usa o OpenSSL para várias outras tarefas, como: criptografia e assinatura (ACBrEAD), comunicação segura (ACBrMail, ACBrHttp)... e outras... Então hoje, elas sempre serão necessárias... essa dependência já existia no "Trunk1"

Boa tarde Fernando, Pelo contrario, sobre esse problema na URL da SEFAZ-PB estou ciente a um bom tempo. Acontece que você propôs uma alteração no código do componente que ao meu ver não ser necessário, pois bastaria alterar a URL no arquivo INI. De uma forma ou de outra, você esta ciente que o problema não esta resolvido? Pois bem, não adianta montarmos uma URL para o QR-Code que seja validada pelos schemas e depois ao tentar ler o QR-Code impresso no DANFE nos é apresentado uma mensagem de erro. Essa alteração é apenas um paliativo para que você possa realizar os seus testes. Sendo assim, volto a afirmar que vocês devem infernizar a SEFAZ-PB até ela consertar essa mercadoria que fizeram na URL.

Boa tarde a todos, Me respondam uma coisa: Gostaria de saber qual é a dificuldade em, abrir com o bloco de notas o arquivo ACBNFeServicos.INI que encontra-se na pasta: ...\Fontes\ACBrDFe\ACBrNFe procurar por: ?cdFuncao e fazer a seguinte alteração: de: [NFCe_PB_P] Usar=NFCe_SVRS_P URL-QRCode=https://www5.receita.pb.gov.br/atf/seg/SEGf_AcessarFuncao.jsp?cdFuncao=FIS_1410 URL-ConsultaNFCe=https://www5.receita.pb.gov.br/atf/seg/SEGf_AcessarFuncao.jsp?cdFuncao=FIS_1410 [NFCe_PB_H] Usar=NFCe_SVRS_H URL-QRCode=https://www6.receita.pb.gov.br/atf/seg/SEGf_AcessarFuncao.jsp?cdFuncao=FIS_1410 URL-ConsultaNFCe=https://www6.receita.pb.gov.br/atf/seg/SEGf_AcessarFuncao.jsp?cdFuncao=FIS_1410 Para: [NFCe_PB_P] Usar=NFCe_SVRS_P URL-QRCode=https://www5.receita.pb.gov.br/atf/seg/SEGf_AcessarFuncao.jsp URL-ConsultaNFCe=https://www5.receita.pb.gov.br/atf/seg/SEGf_AcessarFuncao.jsp?cdFuncao=FIS_1410 [NFCe_PB_H] Usar=NFCe_SVRS_H URL-QRCode=https://www6.receita.pb.gov.br/atf/seg/SEGf_AcessarFuncao.jsp URL-ConsultaNFCe=https://www6.receita.pb.gov.br/atf/seg/SEGf_AcessarFuncao.jsp?cdFuncao=FIS_1410 Simplesmente removi da URL o "?cdFuncao=FIS_1410" Feita essa alteração saia do bloco de notas salvando o arquivo alterado em seguida dentro da mesma pasta temos um arquivo BAT chamado: Compila_RES Execute ele. Para finalizar essa odisseia, compile a sua aplicação com a opção Build. Pronto agora o XML será gerado com a URL do QR-Code e não vai aparecer erro durante a validação do mesmo. Lembre-se que essa alteração é para resolver o problema de validação, uma vez que a URL da SEFAZ-PB esta fora do padrão estabelecido pelo ENCAT. Mas o QR-Code gerado por essa URL será invalida, pois a SEFAZ-PB espera encontrar na mesma o campo cdFuncao que foi removido. E tem gente que quer alterar o código do componente uma vez que a solução é muito mais simples. É aquela velha história para que simplificar se posso complicar.

o IFDEF no Demo não é realmente necessário... e está lá apenas porque ainda não deu tempo de ajustar o Demo corretamente para o Trunk2

Bom dia Infelizmente, não tenho boas notícias. Me corrijam se estiver errado, mas a implementação para o provedor CONAM no trunk1 (ACBrProvedorCONAM.pas) é apenas uma tentativa não concluída de implementação. Simplesmente trocar o provedor em pnfsConversao.pas não vai resolver. O padrão da CONAM passa bem longe do ABRASF, em relação ao formato dos XMLs inclusive. Os nomes das tags são diferentes, as hierarquias são diferentes. A quem interessar, segue anexo um PDF com algo que me disseram ser a especificação (não tem sequer uma menção ao nome da empresa no PDF, estou acreditando que seja verdadeiro, parece piada). De fato, consegui consumir o WS seguindo esse manual, sendo barrado pelo "login". Agora preciso achar alguém que me autorize a utilizar o ambiente de homologação. Para quem vai se aventurar, a boa notícia é que não há necessidade de certificado digital. Penso que o melhor a fazer é implementar fora do ACBr. O trabalho é extenso demais para ser feito no descontinuado trunk1, e fazer no trunk2 não é viável por enquanto, pelos motivos já apresentados pelo Italo, os quais concordo plenamente. Quero deixar claro que isso não é uma crítica a comunidade ACBr, que alias, presta um trabalho sem precedentes na história do Brasil. Realmente não será fácil, sequer possível, conciliar todos os "padrões" da NFSe . webservicenfe2.pdf

Bom Dia, Com a inclusão do campo CEST para uniformização e identificação das mercadorias e bens passíveis de sujeição aos regimes de substituição tributária e de antecipação de recolhimento do ICMS com o encerramento de tributação, instituído no Convênio ICMS 92/15(Nota Técnica 2015.003), e ao analisar a Tabela CEST, percebi que além de um unico cest comportar "n" NCM's, um único NCM pode possuir mais de 1 código CEST correspondente, como no exemplo em anexo. Gostaria de alertar aos desenvolvedores sobre esse detalhe e acima de tudo buscar meios, soluções, dicas para automatizar o preenchimento automático do campo CEST baseado no NCM(Considerar os Válidos), e na manutenção desta tabela atualizada.

E agora já está no repositório tanto para delphi quanto para Lazarus!

Obrigado Juliomar, era o fuso do computador que estava errado apesar da data e horas estarem corretos. Valeu

Sim as configurações regionais do windows! veja se ele tá com a data e hora certa! o componente se baseia nisso para enviar

No svn a correção obrigado

Boa tarde Veríssimo, Então você entendeu errado. Pois segundo a NT 2015/003 versão 1.10 - página 4 diz que o elemento pai da TAG CEST é o I01. O elemento I01 nada mais é que a TAG prod conforme consta na página 53 na NT 2013/005 versão 1.22 Na verdade prod é um grupo que contem todos as TAGs referentes a um produto. Sendo assim a TAG CEST vai aparecer em todos os itens contidos na nota, ou seja, se a minha nota tiver 30 itens vou ter um CEST para cada item, portanto essa TAG vai aparece no XML 30 vezes.

Bom dia, nunca trabalhei com TEF, vou ficar te devendo, mas a respeito do meio de pagamento diferente que a sefaz determinou, uma idéia é informar nas Informações adicionais do CFe. Sds, Ricardo.

Então.. apliquei mudanças nos demos para que se possa entender e usar essa mudança em runtime entre os tipos de emissão Favor atualizar o svn e testar!

Olá, Depois que mudou pro trunk2 ainda to meio perdido com os arquivos, mas obrigado pela informação!

Prega fogo e remove! Tenho aqui na empresa a 6 meses rodando onde dependendo do cliente um ou outro ele usa !

Amigos Moderadores, Seria interessante implementarmos uma solução definitiva no fonte, para ficarmos despreocupados e não precisarmos usar o INI como a única alternativa. Acabei de receber um e-mail da sefaz PB com a seguinte informação: RESPOSTA DA GTI PARA PROBLEMAS DA URL Em 21/10/2015 : 10:30hs Bom dia, A URLhttp://www6.receita.pb.gov.br/atf/seg/SEGf_AcessarFuncao.jsp?cdFuncao=FIS_1410 pode ser substituída por www.receita.pb.gov.br/nfce Atenciosamente, --) Analista de Sistemas indracompany.com Este prazo foi prorrogado p 01/12/2015, veja "informes" disponivel no Portal Nacional da NFE, site: http://www.nfe.fazenda.gov.br/PORTAL/principal.aspx 16/10/2015 - Atenção: Publicada atualização da NT2015/002 e respectivo Pacote de Liberação, contendo as seguintes alterações Atenção: Publicada atualização da NT2015/002 e respectivo Pacote de Liberação, contendo as seguintes alterações: Alteração do prazo de implantação da versão em produção para o dia01/12/2015, por solicitação das empresas; Alteração do campo de valor do Encerrante para 3 casas decimais; Eliminação da regra de validação prevista originalmente para o piloto da NFC-e (RV: A02-10); Para os casos de exportação indireta (CFOP=3.503, 7.501) passa a ser obrigatória a informação de Nota Fiscal referenciada (RV: I08-190); Para a NFC-e, não deve ser informado o grupo de exportação (tag:detExport, RV: I50-10); Melhor definidas as regras de validações relacionadas com a venda de Combustível pela NFCe, documentando a obrigatoriedade da informação do grupo de combustível conforme critério da UF (eliminada RV LA01-10 e LA01-30, alterada RV LA01-20); Na validação do QR-Code da NFC-e, serão aceitos os caracteres hexadecimal em letras maiúsculas ou minúsculas, conforme Manual do DANFE da NFC-e (RV: ZX02-64, ZX02-92, ZX02-116); Flexibilizada a implantação em produção de algumas regras de validação, permitindo que elas sejam implementadas pelas empresas em uma data variável, a partir da implantação da NT em produção pela SEFAZ Autorizadora até a data informada na própria regra de validação (data limite = 01/01/2016). Ou seja, a empresa pode implantar as mudanças necessárias em seus aplicativos, dentro deste período informado, em qualquer data a seu critério. As regras de validação com esta flexibilização são: RV I05-20, LA01-20, LA11-10, N12-30, N12a-20, N12a-30, YA04-10, YA04a-10, YA05-10, ZX02-10, entre outras alterações detalhadas na Nota Técnica. Assinado por: Coordenação Técnica do ENCAT 25/09/2015 - Atenção: Publicado o Manual de Especificações Técnicas do DANFE NFC-e e QR Code - versão 3.3, contendo os Padrões Técnicos do DANFE-NFC-e e QR Code. (link para o Manual de Especificações Técnicas do DANFE NFC-e e QR Code - versão 3.3) Assinado por: Coordenação Técnica do ENCAT

Aqui, já consegui acertar. Antes no trunk1, eu enviava acbrnfe1.enviar(lote) - enviava e salvava o xml com os dados da autorização. No trunk2, envia e imprimia, mas não salvava o xml com os dados da autorização. Depois de quebrar a cabeça e estudando o componte, percebi que tinha que setar: AcbrNfe1.Configuracoes.Arquivos.Salvar:=true; E beleza, está atualizando meus xml como antigamente. Mas foi um parto, pois sempre funcionou do jeito anterior, somente percebi após clientes reclamarem

Bleza Juliomar... muito obrigado... iremos fazer mais algumas implementações e assim que for liberar crio um novo tópico do ACBreSocial trunk2... vlw

Mto obrigado Juliomar.

Bom dia, o Fortes também deve ser instalado com permissão de adm. Meu ambiente é exatamente o mesmo Win 10, 64bit XE7 usando Trunk e Seattle 10 com Trunk2 com Fortes e ainda FastReport, tudo 100% funcionando. Lembre-se ACBrInstall só funciona para o Trunk ACBrInstall_Trunk2 só para Trunk2 Se tiver usando o ACBrInstall para a pasta Trunk, não será criado nenhuma BPL mesmo não, pois no trunk2 eu renomeei os nomes dos pacotes para ficarem padronizados. com as iniciais ACBr_

Boa noite, Recebi o e-mail da sefaz hoje pela manha ele me mandou a URL com os parametros , deixei completa ai você faz o corte Segue abaixo a URL:nfceh.sefaz.ce.gov.br/pages/ShowNFCe.html?chNFe=&nVersao=&tpAmb=&cDest=&dhEmi=&vNF=&vICMS=&digVal=&cIdToken=&cHashQRCode= amanha cedinho vou ligar pra la e perguntar o endereço de consulta , ai posto novamente Um abraço e até lá

Boa noite. Quanto ao problema na URL da Paraíba, acredito que o pessoal da SEFAZ não tem interesse de padronizar conforme a documentação QR-Code Versão 3.3 conforme a citação nesse tópico, pois já mandei diversos e-mails Dúvidas / Sugestões: E-mail: [email protected] informando que o schema PL008h não reconhece o parâmetro cdFuncao=FIS_1410 que encontrasse na URL do estado, e não obtive êxito. Então fiz a seguinte alteração no fonte para poder resolver o problema e não ficar esperando uma resposta que nunca vem da SEFAZ PB, e acredito que eles não irão mudar a URL e padronizar como são nos outros estados, pois o pessoal é meio fraco e lento. OBS: OS FONTES DO ACBR DEVERÃO ESTÁ ATUALIZADOS TRUNCK2, pois os fontes já possui os schemas atualizados. Infelizmente com essa alteração não será possível acessar os dados via QRCode, porem vai passar pela validação do schema e vai transmitir, a consulta vai ficar via site e informado a chave do cupom até eles resolverem o que vão fazer digo a SEFAZ PB. então segue o código abaixo: Na Class: ACBrNFe Método: GetURLQRCode foi colocado o seguinte código: function TACBrNFe.GetURLQRCode(const CUF: integer; const TipoAmbiente: TpcnTipoAmbiente; const AChaveNFe, Destinatario: String; const DataHoraEmissao: TDateTime; const ValorTotalNF, ValorTotalICMS: currency; const DigestValue: String): String; ... // Passo 6 if Pos('?', urlUF) > 0 then begin if (Pos('cdFuncao=FIS_1410', urlUF) > 0) then Result := StringReplace(urlUF, 'cdFuncao=FIS_1410', '', [rfReplaceAll, rfIgnoreCase]) + sEntrada + cIdCSC + '&cHashQRCode=' + cHashQRCode else Result := urlUF + '&' + sEntrada + cIdCSC + '&cHashQRCode=' + cHashQRCode; end else Result := urlUF + '?' + sEntrada + cIdCSC + '&cHashQRCode=' + cHashQRCode; end;

Boa noite, o SAT só aceita as formas de pagamentos pré-definidas no Manual de especificação(página 92), na página 275 tem as Credenciadoras de Cartões que você pode usar. http://www.fazenda.sp.gov.br/sat/downloads/Especificacao_SAT_v_ER_2_15_04.pdf Exemplo de XML com meio de Pagamento: Cartão de Crédito (Cielo) -<pgto> -<MP> <cMP>03</cMP> <vMP>3.00</vMP> <cAdmC>012</cAdmC> </MP> </pgto> Sds, Ricardo.

Boa tarde Veja que subi no Branches na mesma estrutura que está o trunk2! assim conforme forem trabalhando ele peço para que criem um tópico novo e mencionem meu nome que vou subindo as alterações!

Marcio, Vai junto, na Path do executável do programa. Ainda não foi disponibilizado ainda! Mandamos o arquivo ini do provedor para o Italo analizar, mas ainda não veio nada. Estamos tentando acertar, mas acredito que ainda falta algo para funcionar para o provedor Infisc. Alguém do fórum conseguio enviar o RPS no provedor Infisc? Att. Moro

Bom dia Juliomar... segue em anexo a ultima versão do componente do eSocial que estamos implementando... Foi ajustado o cabeçalho, retirado os schemas incluido em uma unica pasta, os fontes ja estão em classes separadas, no padrão que eu defini com o João Kiko na versão anterior... pegamos a versão que eu o João tínhamos implementado e adequamos ao novo layout e tambem ao trunk2 herdando agora da ACBrDFe... Pode dar uma olhada e verificar se tem mais algum problema, mas acredito que ja está no padrão dos componentes do ACBr pois é o mesmo que criei com o João. QQr coisa so avisar que realizamos as alterações. Att ACBReSocial.rar

Bom dia Carlos, Vou puxar a sua orelha, essa nota técnica se refere a eventos, sendo assim funciona exatamente igual ao evento da CC-e, Cancelamento, Manifestação do Destinatário, EPEC, etc.

Vale lembrar que nem todos os recursos e provedores estão funcionando no Trunk2 e não ha nenhuma previsão de ficar pronto. Se vc precisa implantar imediatamente no seus clientes, dependendo do provedor, não vai funcionar ainda no Trunk2

Isso vai de quem tiver afim de implementar conforme a sua necessidade, o que temos a necessidade agora é gerar o componente, e eu e o Tiago estamos implementando ele, gerar os xmls, validar, assinar e enviar pros webservices... depois de tdo isso pronto se alguem tiver a necessidade de implementar o monitor só colocar a mão na massa e desenvolver, a estrutura ja existe.

Recebi um e-mail do David I hoje. E agora sim é confirmado a venda da Embarcadero para Idera, temos nova casa, vamos vê o que nos espera, pois nos últimos anos temos mudando diversas vezes de casa, Borland, CodeGear, Embarcadero e agora Idera. Segue um trecho do e-mail: "I am Randy Jacops, the CEO of IDERA, Inc. You likely saw the press announcement of IDERA's recent acquisition of Embarcadero Technologies. Here is a link to the announcement (http://embt.co/IderaCEOLetter) if you have not seen it. We welcome you to the IDERA family and look forward to continuing Embarcadero's history of market leading products for data professionals and developers. I'm writing this letter to introduce IDERA and explain why we are excited to own Embarcadero."

Boa tarde, Aqui no RJ já enviei com mais de 20 dias de atraso sem nenhuma alteração no XML. Não sei se tem algum problema legal, mas o webservice recebeu e devolveu o cStat = 150 - Autorizado o uso da NF-e, autorização concedida fora de prazo.

Segue ai o motivo da Falha no Shema da NT2015.002

Erro estendido (086 -> CCD ou RG não aberto) eu estava com esse erro, estava ocorrendo por que estava enviando o comando para cortar o papel e a ECF não tinha guilhotina, espero que ajude.