Ir para conteúdo
  • Cadastre-se

Roberto.Godinho

Membros
  • Total de ítens

    192
  • Registro em

  • Última visita

Tudo que Roberto.Godinho postou

  1. Boa tarde, O acbr esta utilizando um valor inválido para tratar o horário de verão do SVRS, ou seja, está utilizando o dhRetorno para comparar a diferença de horário, como sempre vem zerado a condição é atendida independente do horário do WS ser o mesmo da UF que requisitou o status, neste caso a BA e RS tem o mesmo fuso horário. Notem que quando não for horário de verão o sistema utiliza essa diferença de horário para decrescer em 1h o dhRecebto, para corrigir utilizei o dhRecebto para fazer a comparação. Em Anexo está a unit alterada. ACBrNFeWebServices.pas
  2. Boa tarde Luca, A "ciencia da operação" indica que você esta ciente da operação em seu cnpj, no entanto você ainda pode cancelar a operação com outro evento "Operação não realizada", sendo assim você obtem um resumo da nota. Já quando você emite a "confirmação da operação" você recebeu e confirma que esta em concordância com o documento emitido, neste caso já não pode usar "desconhecimento ou operação não realizada" e assim pode obter o documento completo, espero ter sido claro. abraço
  3. Bom dia, @anpecha já que você tem acesso mais fácil a prefeitura de São Luis, eles por sua vez podem cobrar mais facilmente do provedor, vou te passar um erro que seria bom o provedor resolver de uma vez, já entrei em contato com ele a algum tempo e nem sequer deram resposta, portanto se você conseguir cobrar a prefeitura talvez eles tenham melhor sucesso. O erro consiste no seguinte: no método Consulta Lote quando não há lote com a numeração especificada está retornando o XML com erro na tag "descricao", note que a tag não é fechada corretamente, desta forma fica comp-licado ler a tag descricao sem precisar fazer gambiara; Estou anexando o XML de retorno. <codigo>1</codigo><descricao>lote nao encontrado com o numero 0<descricao> 0-lista-nfse.xml
  4. Bom dia, Qual é o nome do provedor Carina? Carina, Tenta o seguinte "acbr.Configuracoes.Geral.ConsultaLoteAposEnvio := False", desta forma ele não vai efetuar a consulta do lote quando efetuar o envio sendo necessário faze-lo manualmente para verifica o resultado do lote. Verifica nos manuais e notas técnicas se este provedor da suporte ao método de consulta lote, se sim, verifica qual o nome do método e configura no arquivo INI.
  5. Então @fernandoschulz, nunca parei pra analisar documentação especifica sobre a danfe da NFS-e, se é que existe. No meu caso, como é posto de combustível e a NFSe é emitida para acobertar troca de óleo ou lavagem, as informações adicionadas são a placa do veiculo e dados motorista, são poucas informações e nenhuma de cunho fiscal, sendo assim não creio haver problemas.
  6. Boa tarde, Então Fernando, só tem um jeito e como falado anteriormente é enviando na discriminação, eu tive este problema também e um modo que encontrei pra resolver o problema foi o seguinte: gero a NFS-e normalmente, armazeno no banco de dados as informações complementares mas não envio, como uso o componente pra imprimir a danfe então eu carrego o XML para o acbr, leio do banco e informo a tag OutrasInformacoes e mando imprimir, ou seja, a danfe vai conter esta informação mas o XML não.
  7. Bom dia, Tem uma implementação minha pendente de analise exatamente sobre isso @Henrique Gusso Netzka, inclusive com os manuais.
  8. Boa tarde, A propriedade PrintDialog é setada True quando atinge a condição MostrarPreview=False" e a "Impressora="Vazia"", ou seja, se quando você chamar o método Enviar você passar "True" para o parâmetro Imprimir o sistema identifica que você deseja que esta nota seja impressa, sendo assim ela deve mostrar o Preview e você escolhe a impressora ou a impressora tem que ser informada, do contrário o PrintDialog será mostrado (PrintDialog não é o preview) pra resolver seu problema pode fazer o seguinte, setar false para a propriedade "MostrarPreview" do componente Danfe e quando Chamar o método ACBrNFe.Enviar para o parâmetro imprimir = false ou faz uma verificação simples antes de enviar: FACBrNFe.DANFE.MostrarPreview := False; FACBrNFe.Enviar(FID_LoteNFe, FImpressoraNFe <> ''); Assim só irá chamar o método de impressão caso houver uma impressora configurada e o preview não será mostrado, podendo ser chamado após a conclusão do processo de envio.
  9. Boa tarde, @anpecha segue os fontes atualizados para a versão atual da NFSe no trunk2 (revision 12835) como havia prometido, só peço desculpas por não conseguir mais cedo, lembrando que a implementação é parcial, quem puder contribuir que o faça, conforme sobra um tempinho eu vou alterando. Nesta ultima alteração efetuei alguns ajustes sugeridos pelo @Italo Jurisato Junior de ajustar o provedor ISSDSF para atender o CTA e removi a unit pnfsNFSeG_CTA.pas e passei a utiliza a unit do issdsf. Testei Envio, consulta por lote, rps e periodo, cancelamento e esta funcionando a contento. CTA.rar
  10. Boa tarde, @Juliana Tamizou você conseguiu dar uma olhada e ver se esta ok para adicionar ao svn?
  11. São dois provedores diferentes http://www.dsfnet.com.br/site/ e http://www.ctaconsult.com/sistema-de-nota-fiscal-eletronica-nfs-e-nfse-a/ este ultimo do CTA vive com problemas, inclusive o site deles esta fora do ar hoje. Já entrei em contato com o pessoal do CTA pelo email fornecido no site pra solicitar os schemas atualizados e nem sequer recebi uma resposta, a inclusão do token passou a ser obrigatório a pouco tempo. Há varias inconsistências que aparentemente eles não estão afim de resolver, por exemplo na consulta lote pede o número do lote mas é o Protocolo que deve ser informado, no retorno desta mesma consulta quando retorna erro a tag retorna errada. <Erros> <Erro> <Codigo>1</Codigo> <Descricao>Lote nao encontrado com o numero 2010<Descricao> </Erro> </Erros> note que a tag <descricao> não é fechada corretamente. No RetornoConsultaNotas consultado notas por periodo o xml esta retornando com a TAG "CodigoVerificacao" escrita erroneamente "CodigoVerificao" dificultando a leitura. Estas e outras correções eu já enviei para eles e não tive retorno. o email deles é cta@ctaconsult.com. Quanto as implementações eu acabei fazendo com pressa, tanto que nem cheguei a terminar, então com certeza tem algumas coisas que precisam ser revistas, fiz mais pra ajudar o nosso colega @Leandro Medeiros que estava precisando destas implementações. Vou só esperar passar este período conturbado e vou rever os fontes e diminuir as redundâncias do código. Disponibilizei aqui para o caso de alguem estar precisando ou se tiver tempo da uma mãozinha. Quanto a estar desatualizado creio que deve estar um pouco mesmo, não muito, é que fui fazendo aos poucos conforme sobrava um tempinho.
  12. Vou anexar aqui alguns exemplos usando as implementações que fiz e anexei acima, não tinha nenhum de envio, devo ter limpado a pasta dos testes, mais tarde vou anexar o banco de teste e gerar alguns de envio e autorização. NO anexo tem exemplo de consulta nota, lote e cancelamento. xml testes.rar
  13. Então Italo, eles são de fato parecidos, no entanto não são iguais, uma das diferença entre eles é o Token exigido pelo CTA, alem de varias outras diferenças entre eles, abaixo vou por um diff do CTA.ini e do IssDSF.ini pra vc ter uma ideia da diferença. Eu comparei ambos os servidores pra ver se daria pra usar o IssDSF e cheguei a conclusão que a implementação deles teria que ser separadas.
  14. Bom dia, A impressão da DANFe no modo Simplificado não está apresentando a logo, analisando o código notei que a sentença que mostra ou não a logo estava invertida, segue print: Estou anexando o arquivo corrigido. Outro problema que encontrei é que ao gerar a NFC-e a lista de alertas está sendo duplicada, isto ocorre por que ao enviar a NFCe a nota é gerada duas vezes, uma delas durante a assinatura e outra quando está gerando o qrCode, como a lista de alertas não é limpa antes de chamar o método XML então as mensagens estão sendo duplicadas, efetuei uma correção para este problema e estou anexando os fontes alterados. Ficaria grato se alguém puder analisar e adicionar ao SVN. ACBrNFeDANFEFRDM.pas pcnNFeW.pas
  15. Boa tarde, Pessoal, a um bom tempo que não tenho conseguido contribuir com algo útil ao ACBr devido a falta de tempo, esta semana consegui tirar um tempinho pra implementar o provedor CTA no Trunk2 pois vi que tinha uns quantos com problemas, eu estou rodando ainda no Trunk antigo só que é inviável pois vou ter que ficar compilando uma versão diferente só pra clientes que utilizam o CTA, então resolvi alterar de uma vez, no entanto fiz alguns testes parciais apenas, métodos que estão funcionando são Enviar, ConsultaLoteRps, ConsultaNFSeRPS, Cancelamento, faltou mexer e testar no método no ConsultaNFSe, como não sei se vou conseguir voltar a trabalhar nisso dentro dos próximos dias então, vou disponibilizar os fontes alterados e se alguém puder contribuir com testes ou implementação/correção ficaria grato, desta formas podemos checar logo no Trunk2 do ACBrNFSe e por pra funcionar. NFSe CTA- Trunk2.rar Qualquer duvida estou a disposição.
  16. Bom dia, Segue o manul referente ao boleto. Manual Layout Sicoob - Correspondente Banco do Brasil - Impressão Local.pdf
  17. mandei o arquivo com um erro anteriormente, segue agora correto. pcnNFeW.pas
  18. Boa tarde, A implementação checada na Revision 12638 na unit pcnNFeW.pas está gerando erro na emissão de NF-e 3.10 na BA, verifiquei e notei que duas implementações não contem a validação de versão, segue erro e print abaixo. -------------------------- ERRO --------------------------- OCORREU UM ERRO DURANTE O ENVIO DA NFE: FALHA NA VALIDAçãO DOS DADOS DA NOTA: 1190 '60' VIOLATES ENUMERATION CONSTRAINT OF '41'. THE ELEMENT '{HTTP://WWW.PORTALFISCAL.INF.BR/NFE}CST' WITH VALUE '60' FAILED TO PARSE. --------------------------- OK --------------------------- Efetuei uma correção pra funcionar corretamente. pcnNFeW.rar
  19. Boa tarde, Foi implementado um solução para o Boleto SICOOB via Banco do Brasil e venho disponibilizar para que seja analisado e adicionado ao ACBr. Arquivos modificados/adicionados: ACBrBoleto.pas (modificado) ACBrBancoBrasilSICOOB.pas (Adicionado) ACBrBoleto.rar
  20. De acordo com https://httpstatuses.com/415 o servidor esta se recusando a atender a solicitação por estar em um formato de mídia invalido, alterei o content-type de : 'Content-Type: application/soap+xml; charset=utf-8' para: 'Accept: application/soap+xml Content-Type: application/soap+xml; charset=utf-8' Aparentemente funcionou assim no entanto o acbr retornou um erro em branco, verificando os arquivos de retorno tive o seguinte erro: <?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" ?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope"> <faultcode>S:Client</faultcode> <faultstring>Cannot find dispatch method for {http://dsfnet.com.br}enviar</faultstring> </S:Fault> </S:Body> </S:Envelope> Obtenho o mesmo retorno se mudar a versão do soap para 1.0 no arquivo ini, assim o content-type vai como "text/xml". Se alguém souber algo por gentileza avise.
  21. Bom dia, Utilizo o provedor IssDFS para a prefeitura de São Luis-MA, está ocorrendo os erros mencionados acima, alterei o arquivo ini para n UseCertificado=0 e deixou de gerar o erro "Erro ao ajustar INTERNET_OPTION_CLIENT_CERT_CONTEXT" , no entanto passou a gerar o erro "Unsupported Media Type (415) -'http://sistemas.semfaz.saoluis.ma.gov.br/WsNFe2/LoteRps.jws?wsdl'". Alguém passou por isso ou sabe o que causa o erro pra poder nos dar uma luz? Grato desde já. 61-env-lot-soap.xml
  22. Boa tarde Wellington, Não é possivel recuperar os XML nessas condições, os meios utilizados por alguns sites cujos você informa a chave d acesso e eles te apresentam a danfe não são meios válidos, portanto o ACBr não dispões destes recursos. Se for poucos XML's ele pode fazer o download acessando o site da SEFAZ, faz a consulta da nf-e pela chave e no final da pagina terá uma opção para download do documento, no entanto precisa do certificado do emitente.
  23. Bom dia, O XML da NF-e, quando da consulta, é atualizado com os dados do protocolo de autorização, se autorizado é claro, portanto você pode tratar para que quando for efetuar o reenvio desta nota faça antes uma consulta pra verificar a situação dela, se a nota não existir ai você envia, senão você só fará as tratativas no seu sistema pra armazenar os dados da autorização retornado pela consulta. Creio que isso resolver boa parte dos seus problemas de duplicidade no reenvio desta nota.
  24. Pior que não esqueci Italo, se fosse discorrer sobre isso meu post ficaria exageradamente grande, mas tenho que concordar contigo Italo, o maior problema são os programadores de meia tigela que por uma duzia de trocados submetem-se a fazer o trabalho porcamente. Eu não entendo onde esta a dificuldade de um fornecedor enviar o arquivo xml, não entendo como pode haver sistemas que não façam isto por default, basta que o cadastro do cliente tenha um misero campo para o email e com poucas linhas você envia o xml, danfe, a foto da vó, do cachorro, enfim, é tão fácil que chega a ser ridículo haver reclamações quanto a isto mesmo depois de tanto tempo e tantas orientações a respeito. Mais ridículo ainda são as empresas que não cobram seus fornecedores e acham mais fácil cobrar o desenvolvedor pra que de um "jeitinho" de conseguir o xml, e por trás de tudo isto tem sempre aquele programadorzinho que vai passar o resto da vida dele fazendo gambiara por que é acha mais facil do que se adequar as normas.
  25. Jorge, Eu compreendo o que você quer dizer, no entanto não posso concordar, imagine bilhões de documentos armazenados em uma base de dados colossal, milhões de usuários acessando esta base e baixando arquivos ao seu bel-prazer, torna-se insustentável. Assim como há os usuários conscientes a muitos outros que não o são, portanto deve haver algum tipo de regulamentação. 180 dias é tempo mais que o suficiente pra fazer o que for necessário com o documento, se houver necessidade efetuar o download e etc. alias, se a empresa é organizada 30 dias são mais que suficientes pra isso. Era dever da empresa armazenar estes documentos quando em papel, assim como agora o é, a regra não mudou ainda. Os webservices foram implementados justamente pra facilitar os tramites deste documentos e principalmente pra facilitar a fiscalização, por isso não posso concordar com o seu argumento "Hoje estes documentos estão em poder do fisco, então, deveria ser obrigação dele a guarda e nos fornecer sempre que precisarmos, mesmo que tenhamos a obrigação da guardá-los.". Como disse anteriormente, o dever do contribuinte continua o mesmo, só mudou a forma como vai fazer este armazenamento, e temos que concordar que é centenas de vezes mais fácil armazenar digitalmente do que ter aquelas salas repletadas de caixas de documentos fiscais criando baratas. Além do mais o fisco só vai solicitar as suas cópias armazenadas em caso de auditoria, então se a empresa esta trabalhando de modo legal não tem por que se preocupar com isso.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...