ivantgm

Bom dia senhores! Enfim consegui habilitar o ambiente simulado para transacionar com PIX. Foram passadas várias configurações pelo suporte da FiServ, nem me atrevo a descrever os passos, pois depende deles enviarem o instalador mais atualizado, passarem uma chave para acessar o módulo configurador, assim como os manuais atualizados. Então, caso alguém tenha a mesma dificuldade, o caminho é entrar em contato com a FiServ mesmo. Muito obrigado aos amigos!

Legal amigo, obrigado pela ajuda! O programa aqui já roda PIX em produção. Tenho um ajuste a fazer, e gostaria de testar no simulado. Acredito que vai ser como o Juliomar disse. Quando rodar, retorno aqui prá falar como foi. Valeu!

Olá! É esse mesmo, com 7 e 8.

Pois é, eu até tentei entrar na configuração do SitDemo, mas dá a seguinte msg: --------------------------- ATENÇÃO --------------------------- A configuração deste ambiente está com algum problema. Será necessário sua restauração para que volte à normalidade. Favor executar os procedimentos que serão mostrados a seguir. --------------------------- OK --------------------------- Na sequencia vem solicitando uma chave a ser fornecida pelo suporte da FiServ, então de qualquer forma terei que acionar o suporte. --------------------------- ATENÇÃO --------------------------- Não foi possível gerar a chave de verificação. Entre em contato com a equipe de Suporte da Fiserv e solicite um reinício da Verificação em Duas Etapas + Configuração. --------------------------- OK ---------------------------

Muito obrigado! Farei isso!

Senhores, bom dia! Preciso realizar testes relacionados com PIX em nosso módulo TEF, que já roda ok em produção, mas temos melhorias a serem implementadas. Instalei o SitDemo fornecido pela FiServ. Estou usando o TEFDDemoNF.exe para realizar os primeiros testes. Está funcionando ok, consigo simular o recebimento com cartão de crédito e débito. Também acesso as funções de CPF e troca de mensagem do PINPAD. No entanto, a funcionalidade de PIX está dando o erro a seguir (CliSiTef.log): -- 14/02 09:40:55:870 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 1 TipoCampo = -1 Buffer = Carteira Digital - Trn. nao habilitada Tam.Min = 0 Tam.Max = 0 -- 14/02 09:40:55:874 - CliSiTef DoExibeMsg: Oper: opmExibirMsgOperador Mensagem: Carteira Digital - Trn. nao habilitada Verifiquei o arquivo CliSiTef.ini, e está ok, inclusive adicionei uns códigos errados para testar, e deu erro, indicando que estou alterando o arquivo correto. [Geral] TransacoesAdicionaisHabilitadas=7;8 Então, venho pedir ajuda dos senhores. Será que tenho que pedir algo mais a FiServ? Vi em outro tópico algo sobre "configuração de comunicação do Modulo CardSE no SitefDemo".

Bom dia. Para que possamos adotar a melhor solução para o problema, segue foto do display. Estou a disposição.

Boa tarde. Sou o criador do tópico linkado pelo EMBarbosa. No meu caso tratava-se de uma balança rodoviária, para pesar caminhões. O peso mínimo para ativar a balança, salvo engano, era 50Kg. Me lembro que para testar foi necessário alguém colocar um carro, pois o peso de uma pessoa não ativava a balança. Assim, certamente não se trata do mesmo equipamento, já que na foto o display está exibindo 15,0Kg. A alteração como foi feita para mim funcionou, e tudo bem se quiserem voltar como era antes. Caso decidam voltar, eu multiplico por 10 e vida que segue. Estou a disposição.

Senhores, boa tarde. Estou utilizando o componente ACBrBal para comunicação com uma balança Tolelo 2180. Tudo funcionou, entretanto tive que realizar um ajuste na unit "ACBrBALToledo2180.pas", comentando a linha 133, como segue: 129. if (wPos > 0) then 130. begin 131. wResposta := Copy(aResposta, wPos + 1, Length(aResposta)); 132. wResposta := Copy(wResposta, 1, 6); 133. //Insert('.', wResposta, 6); <======= essa linha ======= 134. end 135. else 136. wResposta := 'I'; Vide manual a seguir, página 167, Protocolo P03: https://cdn.toledobrasil.com.br/app/institucional/files/manuais/MU TI400 - 3474457 - Rev. 05-08-19.pdf Neste protocolo o peso do display é enviado após o caracter #96 em 6 posições sem porção decimal. A linha de código 133 faz com que o peso fique dividido por 10. Estou a disposição para mais informações. Segue unit alterada anexo. ACBrBALToledo2180.pas

Senhores, Desculpem ai pelo desabafo off topic, mas essa prorrogação da NT 60 "toda verdinha" só prejudicou quem foi pontual e cumpriu o prazo. Agora o ambiente de homologação ficou diferente do de produção e os testes ficaram confusos. Impedir a validação de uma NF porque não informou um campo "vDesc" com valor ZERO, é falta de inteligência. Obrigar que o nDup seja um valor sequencial, formatadinho com "000", é muita falta de inteligência. E essa comida de barriga com a data do vencimento.... Bom, só torcendo para que alguém do SEFAZ leia esse meu post. ?

Senhores, aqui voltou a funcionar!

O WS SP caiu, possivelmente o problema é do próprio SEFAZ, e já estão resolvendo o problema. Vamos aguardar.

Peço desculpas, acabei postando outro tópico com o mesmo assunto: Aparentemente o problema está com certificados SERASA.

Senhores, hoje é sexta! Sempre bom lembrar disso. Estamos recebendo de nossos usuários, que utilizam certificado da SERASA (tanto A1 como A3), o erro 403 forbidden. Outros usuários, que utilizam certificados de outros fornecedores, estão ok. O WS de SP, indica somente 403 - Forbidden, mas, o WS do ambiente nacional indicou mais informações: "HTTP Error 403.13 - Forbidden: Client certificate has been revoked on the Web server." Os erros acontecem no ACBr, no IE, e no Chrome também. Concluí (sem muita certeza) que a cadeia de certificação do SERASA no SEFAZ foi revogada. Estamos entrando em contato com o SERASA e colhendo mais informações. Fica aqui o tópico, para quem estiver com o mesmo problema ir relatando os fatos, assim podemos nos ajudar.

Senhores, bom dia A URL que passei no tópico anterior esta errada, considerar: https://nfehomologacao.etransparencia.com.br/sp.jau/webservice/aws_nfe.aspx?wsdl Marcos, também estamos analisando a viabilidade, o projeto está congelado no momento. Qualquer novidade vamos nos informando.

Marcos, boa tarde. Sim, eu já fiz isso. Já mexi em tudo que vc imaginar. Eu criei um usuário e um prestador de serviços. Tanto o usuário como o prestador ganham um código, tipo um hash, e esses códigos devem ser utilizados no XML: <ns0:Login> <ns0:CodigoUsuario>hash usuário aqui</ns0:CodigoUsuario> <ns0:CodigoContribuinte>hash contribuinte aqui</ns0:CodigoContribuinte> </ns0:Login> Num primeiro momento, meu cadastro estava como "não autorizado", e ao consumir o WS dava erro, dizendo exatamente isso. Depois autorizaram meu cadastro, e o erro ao consumir o WS passou a ser outro, ou seja, está funcionando. No momento não tenho quase nada programado. Os testes que fiz, foi fora do ACBr. Eu utilizei o Delphi XE7, menu Components -> Import WSDL, passei a URL do WS (https://nfehomologacao.etransparencia.com.br/sp.jau/webservice/aws_dcl.aspx?wsdl ), ele gerou com sucesso o esqueleto do cliente, ai umas garibadas aqui e ali, e consegui consumir o WS.

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

Senhores, boa tarde. A prefeitura de Jaú/SP está trocando de provedor. Atualmente GINFEs, sendo substituído por CONAM. A troca foi anunciada 23/10/2015, e passa a valer 01/11/2015. O ambiente de homologação está operacional, pelo menos a URL do WS concatenada com "sp.jau", já está acessível: https://nfehomologacao.etransparencia.com.br/sp.jau/nfe/principal.aspx O prazo é apertado, infelizmente não tive acesso a informação com mais antecedência. Mas isso é "cada um com seus problemas". A questão é: Qual o melhor caminho a ser tomado nesta situação? Gostaria de sugestões dos amigos... Estou pensando em modificar o ACBr no Trunk 1, pois emergencialmente não me parece uma boa ideia tentar usar o Trunk 2... ou é melhor usar o trunk 2 ? Bem, se possível, alguns dos colegas poderia me dar algum direcionamento? Grato.

Senhores, boa tarde. Comigo aconteceu exatamente o mesmo. Quando CST=51, o campo vICMS deve ser informado no XML, mesmo que ZERO. Resolvi editando o arquivo PCN2/pcnNFeW.pas, alterando a linha 1301 como segue: de: Gerador.wCampo(tcDe2, 'N17', 'vICMS ', 01, 15, 0, nfe.Det[i].Imposto.ICMS.vICMS, DSC_VICMS); para: Gerador.wCampo(tcDe2, 'N17', 'vICMS ', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vICMS, DSC_VICMS);

Bom dia Não sei responder sua pergunta, mas vou pesquisar. Penso também que seria melhor através de parâmetros, até porque eles já existem, são as propriedades `ExpandirLogoMarca` e `Logo`. A propósito, há também as propriedades de configuração de Margem (top, left, superior...) , que também não surtem efeito na versão Basic. Não tenho experiencia com Fast, estou utilizando por ser o padrão do XE7, e o ACBr instalou redondinho com ele selecionado. Editei o arquivo FR3 por um mau entendido; quando vc disse que a versão básica do Fast "não possui muito recurso", pensei que não fosse possível acessar o layout via código delphi. De qualquer forma, o workaroud acima resolve o problema paliativamente.

Juliomar, grato pela resposta! Sim, estou utilizando o Fast que vem com o Delphi. Editei o arquivo DANFeRetrato_Basic.fr3, criando dois novos arquivos, DANFeRetrato_Basic_SemLogoMarca.fr3 e DANFeRetrato_Basic_ExpandirLogoMarca.fr3, os quais estou enviando anexo. Em meu código, para manter a lógica das propriedades `Logo` e `ExpandirLogoMarca` (Quick e Rave), fiz da seguinte forma: if(ACBrNFeDANFEFR1.Logo='')then begin ACBrNFeDANFEFR1.FastFile := 'DANFeRetrato_Basic_SemLogoMarca.fr3'; end else if(ACBrNFeDANFEFR1.ExpandirLogoMarca)then begin ACBrNFeDANFEFR1.FastFile := 'DANFeRetrato_Basic_ExpandirLogoMarca.fr3'; end else begin ACBrNFeDANFEFR1.FastFile := 'DANFeRetrato_Basic.fr3'; end; DANFeRetrato_Basic_SemLogoMarca.zip DANFeRetrato_Basic_ExpandirLogoMarca.zip

Senhores, boa tarde. Utilizando a impressão do DANFe via Fast, não consigo fazer funcionar a propriedade ExpandirLogoMarca. Tanto faz TRUE ou FALSE, continua saindo o logo pequeno e os dados do emitente do XML. Além disso, informar uma string vazia na propriedade `Logo` faz a imagem desaparecer, porém o espaço continua sendo ocupado, ou seja, fica um "buraco" branco onde a imagem era exibida, sem o rearranjo dos campos. Utilizei em FastFile "DANFeRetrato_Basic.fr3", e os demais arquivos nas pastas do ACBr, sem sucesso. O que será que estou fazendo errado? Grato.

Senhores, boa tarde. Tenho uma dúvida a respeito do envio de NFe em modo assíncrono. ACBrNFe1.NotasFiscais.Clear; ACBrNFe1.NotasFiscais.LoadFromFile(GetXML); ACBrNFe1.NotasFiscais.GerarNFe; ACBrNFe1.NotasFiscais.Assinar; ACBrNFe1.NotasFiscais.Valida; ACBrNFe1.WebServices.Enviar.Lote := GetLote; ACBrNFe1.WebServices.Enviar.Sincrono := false; ACBrNFe1.WebServices.Enviar.Executar; //// <<<< AQUI A DÚVIDA {armazena o Recibo para buscar o retorno no próximo passo} SavarRecibo(ACBrNFe1.WebServices.Enviar.Recibo); {o usuário aguarda um tempo e busca o retorno} { ... } ACBrNFe1.WebServices.Retorno.Recibo := GetRecibo; ACBrNFe1.WebServices.Retorno.Executar; for i:= 0 to ACBrNFe1.WebServices.Retorno.NFeRetorno.ProtNFe.Count-1 do begin // verifica se NFe autorizada, denegada, recusada, grava resultados, etc end; O pseudo código acima é funcional. A NF é recebida pelo WS, colocada na fila, e o Recibo é armazenado para ser consultado no WS posteriormente. No entanto, vamos supor que a internet em um momento se torne instável. O WS recebe o lote, coloca-o na fila de processamento e envia o Recibo, só que, devido a instabilidade da internet, não recebo o Recibo. Não sei se o WS recebeu a NF, tão pouco sei se foi autorizada ou não. Nesse caso, preciso guardar o XML assinado e transmitido, e consultar a NF pela chave de acesso: ACBrNFe1.WebServices.Consulta.NFeChave := GetNFeChave; ACBrNFe1.WebServices.Consulta.Executar; Caso retorne “não-autorizada”, corrijo o erro, gero novo XML, e repito o processo. Caso retorne “autorizada”, monto o “nfeProc”, conferindo o DigestValue do protocolo e do XML assinado são idênticos. Aqui cheguei no ponto! Preciso me certificar de ter o mesmo XML recebido e autorizado pelo WS, senão corro o risco de ficar com um XML incorreto. Em outras palavras, caso o Recibo do lote se perca, preciso resguardar o XML, não podendo deixar o usuário editá-lo, até confirmar se foi autorizado ou não. Minha dúvida: Ao chamar: ACBrNFe1.WebServices.Enviar.Executar; Qual o melhor caminho para identificar a situação descrita acima? Quando devo “travar” o XML? A chamada acima gera um Exception nesses casos? É difícil reproduzir a situação, tentei puxando o cabo de rede, mas não deu certo PS – sei que se tudo der errado (digestValue diferente) posso fazer o download do XML pelo site do SEFAZ, mas ai complica pro usuário que só sabe apertar botões. Grato.

Grato pela resposta Italo Vou tentar implementar. Penso que o primeiro passo é estudar e entender o código fonte do componente. Não vou fazê-lo caso não me sinta a vontade em alterá-los. Quando concluir este passo pergunto novamente pela funcionalidade, pois alguém pode pegar este trabalho antes de mim. Caso tenha algum texto para me indicar antes de iniciar o trabalho de codificação, agradeço. Boas!

Senhores, boa tarde. Antes de mais nada, informo que testei e conferi exaustivamente, e todas as funcionalidades do provedor Fiorilli estão funcionando corretamente. Fica aqui meus parabéns a equipe do ACBr - vocês realizaram um excelente trabalho! No entanto, pesquisando no fórum, mas precisamente este post: http://www.projetoacbr.com.br/forum/index.php?/topic/10504-adicionar-novo-provedor-fiorilli/?p=70124 , entendi que o serviço SubstituirNfseEnvio não foi implementado. Analisando o código do componente cheguei nesta mesma conclusão. Neste mesmo tópico, foi explicado que a substituição nada mais é do que um pedido de cancelamento seguido pela geração de uma nova NFSe. A definição está correta ao meu entender. Porém, a prefeitura da cidade de Bariri não pensa desta forma. Foi passado pelo setor fiscal da prefeitura que a rotina de cancelamento não deve ser utilizada, sendo obrigatório utilizar a substituição. Para cancelamento, deve-se abrir um "processo administrativo", realizando um pedido pessoalmente no setor fiscal. Bem, deixo o fiscal de lado, assim como apurar a verdade desta informação, pois isso não é da minha ossada. Não sei afirmar se em produção a prefeitura pode desabilitar o WS de cancelamento, mas penso que se isso não foi feito, haverá algum tipo de sanção a quem cancelar NFS. Isso posto, o componente acabou não atendendo 100%. Entendo que o componente é gratuito e a dificuldade para abstrair todas as diferenças entre os provedores. Nem vejo isso como uma deficiência, pois a substituição não é tão comum, e é possível realizá-la via interface WEB. Mesmo assim, ficam minhas perguntas: Existe interesse ou previsão desta funcionalidade ser adicionada ao componente? Se eu programar esta funcionalidade existe a possibilidade do meu código ser adicionado? Caso sim, qual o caminho? Grato pela atenção.