ws_junior

Encontrei esse problema aqui também. Tratei para Goiânia preencher vazio: (pnfsNFSeW_ABRASFv2 - linhas 999 e 1000) proGoiania, proMegaSoft: Gerador.wCampo(tcStr, '#4', 'Competencia', 19, 19, 0, '', ''); Realizados teste em produção de 10 NFS-e.

Perfeito @TBI, realizei a mesma modificação aqui e também deu certo. No meu caso, tinha homologado junto ao Safra a remessa e inclusive já tinha sido liberado para produção, porém os clientes não conseguiam pagar os títulos gerados pelo sistema. No entanto, após enviada a remessa, em produção, e gerado o boleto via "segunda via" no banco, o cliente conseguia pagar normalmente. Realizei a modificação citada, enviei nova remessa e realizei o pagamento do título gerado com sucesso. Muito obrigado pela atenção amigos. ACBrBancoSafra.pas

Boa tarde, poderia mencionar ou anexar o arquivo modificado? Estou passando pelo mesmo problema e gostaria de fazer testes.

Caros amigos @Italo Jurisato Junior e @Juliomar Marchetti fico muito feliz em dizer que deu certo o processo que precisava criar. A sugestão do Italo funcionou perfeitamente. Obrigado pela atenção.

Perfeito. Vou testar aqui com o autXML.

Entendi Ítalo, e concordo que não faz sentido se "eu emiti" e tenho a obrigação de guarda-lo e disponibiliza-lo, ter que baixar. A minha questão específica é que, como não sou exatamente o sistema que emite e preciso das informações citadas acima do motorista e placa, procurava uma forma de consegui-los. Agradeço pela atenção @Juliomar Marchetti e @Italo Jurisato Junior boa semana para todos.

procedure TForm1.actconsultarExecute(Sender: TObject); var i: Integer; begin if ACBrMDFe.DistribuicaoDFePorUltNSU('11111111111111', '1000') = True then begin if ACBrMDFe.WebServices.DistribuicaoDFe.retDistDFeInt.cStat = 138 then begin for i := 0 to ACBrMDFe.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Count - 1 do begin if (Trim(ACBrMDFe.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[i].resDFe.chDFe) <> '') then begin if ACBrMDFe.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[i].schema = schprocMDFe then begin VirtualTableMDFe.Append; VirtualTableMDFechave.Value := ACBrMDFe.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[i].resDFe.chDFe; VirtualTableMDFexml.AsString := ACBrMDFe.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[i].Xml; VirtualTableMDFe.Post; end; end; end; end; end; end; Da forma que faço com NF-e destinada, fiz com os MDF-e, porém ele me traz (como deveria) os documentos que forma emitidos para o "meu" cnpj. Preciso dos que "eu" emiti. Existem algum caminho para isso?

Bom dia @Juliomar Marchetti, obrigado por responder. Esses métodos estão no Demo? Busquei nos fontes e encontrei os métodos de distribuição, no entanto utilizo esses métodos no ACBrNFe para notas destinadas. Seria mais ou menos por ai o caminho? Na prática oque eu preciso é razoavelmente simples e, talvez, com a ajuda aqui da comunidade, seria possível fazer de outra forma. (Se baixar o XML funcionar mata o problema com certeza!) Os requisitos que tenho são: Com o XML pegar as informações do motorista (CPF) e placa do veículo e chave MDF-e; Situação do MDF-e (neste caso já consulto não encerrados); Acontece que utilizando "ACBrMDFe1.WebServices.Consulta.MDFeChave" o retorno não me traz as informações do motorista e veículo e o sistema que o cliente utiliza, como já citado, não disponibiliza de forma conveniente para consumo automático os XMLs.

Boa tarde amigos. Tenho uma dúvida, que acredito que é simples, porém não encontrei resposta ainda. Consigo fazer o download dos XMLs originais de MDF-e emitidos por uma empresa utilizando o certificado digital? A situação em concreto é que os documentos são emitidos em outra filial, por outro sistema que não quer "conversar" com ninguém, porém queremos, de posse desses XMLs, vincular com as cargas em uma base de dados para realizar os encerramentos. Obrigado desde já.

Enfrentei o mesmo problema hoje. Graças a este post consegui resolver o problema. Não seria interessante já implementar de forma definitiva a solução dada pelo colega @Juliomar Marchetti?

Bom dia Amarildo, a questão é que sem a modificação citada acima, quando preenchemos com "0.00" o valor vDesc a rotina de criação do xml o omite. Então tive que realizar essa modificação. Fiz o teste em Ambiente de Homologação 4.0 e funcionou, porém ainda não realizei teste em produção. Caso alguém tenha tido a oportunidade de testar em produção, por favor, informe por aqui para que possamos dar resolução ao problema. Perdão, acabo de checar com um colega aqui na empresa e ele me afirmou que na sexta-feira passada, soltamos uma versão em produção para um cliente com a correção citada acima aplicada e funcionou em ambiente de produção 4.0 (GO). Na ocasião os schemas não foram atualizados com a última versão disponível. (para conhecimento)

Amigo uma providencia, em ambito emergencial, que tomei foi alterar na linha 2208 do pcnNFew.pas foi essa: Gerador.wCampo(tcDe2, 'Y05', 'vDesc ', 01, 15, 1, nfe.Cobr.Fat.vDesc, DSC_VDESC); Veja que foi modificado o valor 0 para 1 no 6º parâmetro, para que assim o valor vDesc seja preenchido ainda que seja zero no código.

Bom dia. Peço desculpas pela mudança na indentação, é uma mania de Ctrl+D que tenho e configurações pessoais no Delphi, mas o @Daniel Simoes tem razão no conteúdo citado. Com referencia no Help (http://iws.ibpt.org.br/help/index#!//Produtos_Get) esses campos comentados no código realmente não são obrigatórios para a consulta. Inclusive, testei em aplicação já com o código modificado e a consulta foi realizada normalmente.

Apresento uma sugestão de modificação (bastante simples) no componente TACBrIBPTax na consulta da API. Argumento que não são valores obrigatórios na API, portanto não faz muito sentido serem validados na unit. Linhas 498 do arquivo. (anexo) ACBrIBPTax.pas

Realizei modificações para homologação na Caixa, acho que é pertinente neste tópico, e estou enviando os arquivos. Trata-se de Local de Pagamento e Mensagem do rodapé da caixa, retirando "reclamações não solucionadas e denuncias". Estas modificações foram solicitadas pela Caixa. ACBrBancoCaixa.pas ACBrBancoCaixaSICOB.pas ACBrBoleto.pas

Encaminho sugestão de modificação para unit ACBrNFSeDANFSeFR. Modificação: Criar objetos TfrxDBDataset com Enable = False. Isso proposto para não apresentar os objetos no FastReport quando for criar relatórios em run-time. O mesmo já foi realizado na NF-e. ACBrNFSeDANFSeFR.pas

Tentei entrar em contato Regys, mas sem sucesso. Na realidade notei um certo descaso, já que no telefone do suporte quanto liguei alguém atendia - retirava o telefone da base - e logo desligava. Até a semana passada, conforme histórico do tópico, o retorno era diferente. Ainda com conteúdo fora do padrão. Já hoje, além do XML acima, houve retorno de processamento de lote sem conteúdo algum. Fiz teste em ambiente de produção e a nota é enviada e validada com sucesso, confirmando que não há falha no componente. Deixo o telefone de contato da Sefaz GO, departamento de TI responsável pela NF-e: (62) 3269-2049 / 3269-2110

Alguém de vocês está conseguindo enviar para a Sefaz-GO? Quando envio, passando pela etapa anterior, o retorno do lote é completamente vazio.

Mais uma vez a Sefaz GO faz uma cagada. (Perdão pela expressão) Agora os retornos vem com "nfe:", provocando o mesmo erro citado anteriormente. <?xml version="1.0" encoding="UTF-8"?> -<nfe:retConsStatServ versao="3.10" xmlns:ns0="http://www.w3.org/2000/09/xmldsig#" xmlns:nfe="http://www.portalfiscal.inf.br/nfe"> <nfe:tpAmb>2</nfe:tpAmb> <nfe:verAplic>GO3.0</nfe:verAplic> <nfe:cStat>107</nfe:cStat> <nfe:xMotivo>Serviço em operação</nfe:xMotivo> <nfe:cUF>52</nfe:cUF> <nfe:dhRecbto>2016-05-10T16:52:58-03:00</nfe:dhRecbto> <nfe:tMed>1</nfe:tMed> <nfe:dhRetorno>2016-05-10T16:52:58-03:00</nfe:dhRetorno> <nfe:xObs>Aguarde 3 minutos para a realização de uma nova consulta.</nfe:xObs> </nfe:retConsStatServ>

Que bacana. Valeu.

Nem precisa ir longe, a questão está a dois posts! @p.emoraes postei uma solução temporária acima. A solução foi dada pelo nosso colega @Cleiver 7 posts acima. Trata-se de um erro, que espero ser corrigido logo pela Sefaz-GO, por isso o ACBr não tem como 'commitar' algo corrigindo, pois é pontual e terá impacto desnecessário para usuários de outros UF. Dá uma lida ai irmão!

Juliana na prática muda que o banco está oferecendo um serviço a mais para o usuário como opção ao protesto, só que mais barato. Na nossa realidade, não vi direitinho ainda o documento farei esse fds, acredito que teremos que implementar a geração da remessa com informações de "quantidade de dias para negativação expressa". Isso seria como a instrução de protesto só que definido em outra coluna no arquivo de remessa.

Ola. Hoje um cliente entrou em contato pedindo para configurar a "Negativação Expressa" do Itau com 05 dias. Confesso que não tinha nem ideia que isso existia. Buscamos informação e, segundo as rotinas do Itau, trata-se de uma opção que o cliente pode utilizar como alternativa ao Protesto (Que sai mais caro). O banco lê o comando de dias e inclui o Sacado no SPC/Serasa automaticamente, como no protesto. No recebimento é retirado automaticamente ou por comando via Web do banco realizado pelo cliente. Bom, a pergunta é: Existe algo nesse sentido já preparado no ACBrBoleto? Segue documentação enviada pelo Itau para nós. cobranca_400bytes_cnab_itau.pdf

Fiz o tratamento em todas as funções "TratarResposta" do ACBrWebServices.pas adicionando o código que @Cleiver mencionou. No entanto, gostaria de saber se o tratamento realizado pela Sefaz-GO, que até o momento pelo que se sabe é a única que provoca esse erro, está correto. Seguem em anexo o .pas e .xml de retorno com o erro. ACBrNFeWebServices.pas 20160428090005-sta.xml

Sigo com o mesmo problema em ambiente de homologação (GO). Ocorre tanto em NF-e quanto em NFC-e. A mensagem retornada sempre retorna vazia.