rafaeldalbosco

Pessoal alguém tem alguma novidade sobre o registro das cobranças on-line via API diretamente no banco ? Se alguém tiver mais layouts de outros bancos, como Banco do Brasil, Santander, Caixa, Itaú entre outros que sei que já dispõe do serviço e puder postar.

@Juliomar Marchetti deu certo sim, obrigado por aceitar a alteração.

Algum moderador poderia verificar essa situação se será possível aceitar essa alteração?

@Italo Jurisato Junior acredito que a questão pode ser semelhante a do tópico abaixo que coloco aqui o link, algo com os caracteres especiais ocorre em alguns eventos como esse da consulta MDFe encerrados e do evento de prestação de serviço em desacordo do CTe que ambos no XSD o webservice da receita requer a descrição do evento com acentuação fora do encoding do XML (até achei estranho a receita solicitar assim esses eventos). No momento estou bem ocupado para fazer os testes, mas assim que sobrar um tempo vou testar também o Webservice da consulta MDFe não encerrados e a tópico acima com a opção SetCodePage(RBS, 0, True). Comentei aqui pois achei importante contribuir nesse momento.

@Daniel Simoes testei sua alteração e não obtive sucesso, somente com a alteração do @Gilvano Piontkoski funcionou.

Olá gostaria de sugerir uma correção na validação do Drawback da NFe, me deparei essa semana com uma nota de importação de um cliente, o qual tem seu registro de Drawback iniciando com 2016, sua concessão do Drawback é valido por 2 anos, conforme anexo abaixo destaquei data de registro e validade, acontece que o ACBR NFe existe uma validação que estava retornando Falso o qual impedia a emissão da NFe, ajustei o método ValidaDrawback do fonte ACBrDFeUtil.pas, anexei nesse post tanto o fonte completo como o patch de correção do ACBr como for mais fácil para comparar com minha alteração. Também aproveito para postar aqui o código de como estava: function ValidaDrawback(AValue: String): Boolean; var ano: integer; begin // AValue = AAAANNNNNND // Onde: AAAA Ano corrente do registro // NNNNNN Número sequencial dentro do Ano ( 6 dígitos ) // D Dígito Verificador, Módulo 11, Pesos de 2 a 9 AValue := OnlyNumber(AValue); ano := StrToInt(Copy(IntToStr(YearOf(Date)), 3, 2)); if length(AValue) = 11 then AValue := copy(AValue, 3, 9); if length(AValue) <> 9 then Result := False else if not ((StrToInt(copy(Avalue, 1, 2)) >= ano - 1) and (StrToInt(copy(Avalue, 1, 2)) <= ano + 1)) then Result := False else Result := copy(AValue, 9, 1) = Modulo11(copy(AValue, 1, 8)); end; E como ficou depois da minha alteração: function ValidaDrawback(AValue: String): Boolean; var ano: integer; begin // AValue = AAAANNNNNND // Onde: AAAA Ano corrente do registro // NNNNNN Número sequencial dentro do Ano ( 6 dígitos ) // D Dígito Verificador, Módulo 11, Pesos de 2 a 9 AValue := OnlyNumber(AValue); ano := StrToInt(Copy(IntToStr(YearOf(Date)), 3, 2)); if length(AValue) = 11 then AValue := copy(AValue, 3, 9); if length(AValue) <> 9 then Result := False else if not ((StrToInt(copy(Avalue, 1, 2)) >= ano - 2) and (StrToInt(copy(Avalue, 1, 2)) <= ano + 2)) then Result := False else Result := copy(AValue, 9, 1) = Modulo11(copy(AValue, 1, 8)); end; Qualquer dúvida estou a disposição e agradeço caso a sugestão de alteração seja aceita. ACBrDFeUtil.pas.patch ACBrDFeUtil.pas

MagoSchmidt também estava pesquisando sobre isso e encontrei só o layout do Bradesco, sabe me dizer se é somente esse banco que tem essa integração?

Bom dia Pessoal, estou com o mesmo problema, atualizei meu repositório ontem, está na revisão 11706 e passou a dar erro no método NativeStringToUTF8 da unit ACBrUtil, essa situação já havia sido resolvida pelo Daniel Simões no tópico: Mdf-E - Nt 01.2015 - Novo Webservice De Consulta Manifestos Não Encerrados na revisão 11418 funcionava, mas analisei a alteração do Daniel na época e a mesma continua. O erro acontece na unit ACBrUtil, método NativeStringToUTF8 aonde existe a chamada do método "SetCodePage(RBS, 0, False);" ao passar por esse ponto o texto do xml que contém a string "CONSULTAR NÃO ENCERRADOS" é alterado para esse "CONSULTAR NÃO ENCERRADOS". Em testes conforme o tópico acima alterando a chamada do método para "SetCodePage(RBS, 0, True);" resolveu, mas não sei se isso irá ou não solucionar o problema ou gerar mais problemas, pois não tenho conhecimento do que esse método faz. Estou compilando o ACBr e a minha aplicação na versão Delphi XE7

Daniel, só para confirmar que a sua alteração funcionou certinho aqui para min.

Realmente Daniel, pelo que vi isso vai resolver também. Vou fazer um teste aqui para verificar se funciona.

Bom dia Pessoal, gostaria de compartilhar com você, ontem estive com um problema semelhante, e estou postando abaixo a solução que fiz para min, estava ocorrendo porque após configurar o componente eu não estava dando esse comando: WS.SSL.CarregarCertificado; Com ele consegui resolver, porém comecei a investigar o problema do porque o mesmo ocorre e identifiquei que no fonte ACBrDFeCapicom.pas nos métodos TDFeCapicom.Assinar e TDFeCapicom.Validar é utilizado o seguinte código: CoInitialize(nil); try CarregarCertificadoSeNecessario; ... Acontece que no método CarregarCertificadoSeNecessario também é validado se tem ou não o número do certificado carregado, caso não tenha executa o método que carrega o certificado digital para memória, dentro desse método também se executa o CoInitialize(nil); e CoUninitialize; acabando liberando o recurso. Uma sugestão de melhoria caso queiram aceitar seria alterar nos dois métodos "TDFeCapicom.Assinar" e "TDFeCapicom.Validar" para que o código fique dessa maneira: CarregarCertificadoSeNecessario; CoInitialize(nil); try ... Isso irá evitar esse tipo de problema caso o programador esqueça de na hora de configurar de chamar o método: WS.SSL.CarregarCertificado; Anexei o fonte com a alteração caso queiram aceitar. ACBrDFeCapicom.pas

Relamente era o CFOP que estava sendo utilizado CFOP de Saída, consegui autorizar o meu CTe, obrigado.

Boa tarde Italo, essa é uma rejeição: 519 - Rejeição: CFOP inválido para operação Realmente o CFOP deveria ser 5206 porem acontece a mesma rejeição. <CFOP>5206</CFOP> <tpCTe>2</tpCTe> Emitente SC Remetente PR Destinatário PR esse é o retorno o XML que o WebService retorna: <cteRetRecepcaoResult xmlns="http://www.portalfiscal.inf.br/cte/wsdl/CteRetRecepcao"> <retConsReciCTe xmlns="http://www.portalfiscal.inf.br/cte" versao="2.00"> <tpAmb>2</tpAmb> <verAplic>RS20150311110853</verAplic> <nRec>423000006248159</nRec> <cStat>104</cStat> <xMotivo>Lote processado</xMotivo> <cUF>42</cUF> <protCTe versao="2.00"> <infProt Id="CTe290420151456230360"> <tpAmb>2</tpAmb> <verAplic>RS20150311110853</verAplic> <chCTe>42150411326781000125570040000008981492770139</chCTe> <dhRecbto>2015-04-29T14:56:22</dhRecbto> <digVal>fk4JBQe+yRKump3M5Y1G1VEMRqo=</digVal> <cStat>519</cStat> <xMotivo>Rejeição: CFOP inválido para operação</xMotivo> </infProt> </protCTe> </retConsReciCTe> </cteRetRecepcaoResult>

Olá pessoal alguém conseguiu passar por essa validação? Pelo que vi na o CFOP é o que foi citado acima porém não consegui autorizar o meu Cte meu XML está da seguinte forma <ide> ... <CFOP>6206</CFOP> ... <tpCTe>2</tpCTe> ... </ide> <emit> ... <enderEmit> ... <cMun>4216909</cMun> <xMun>Sao Lourenco do Oeste</xMun> <UF>SC</UF> ... </enderEmit> </emit> <rem> ... <enderReme> ... <cMun>4108403</cMun> <xMun>Francisco Beltrao</xMun> ... <UF>PR</UF> <cPais>1058</cPais> <xPais>BRASIL</xPais> </enderReme> ... </rem> <dest> ... <enderDest> ... <cMun>4117206</cMun> <xMun>Nova Olimpia</xMun> <UF>PR</UF> ... <cPais>1058</cPais> <xPais>BRASIL</xPais> </enderDest> ... </dest>

Boa tarde Pessoal, essa semana no site da NFe conforme link abaixo tem um comunicado que a Sefaz do RS irá alterar os endereços dos WebServices. http://www.nfe.fazenda.gov.br/portal/informe.aspx?ehCTG=false#339 Alguém sabe se tem algum prazo de desativação do endereços antigos? Atualizei hoje o projeto e verifiquei que no ACBrCteUtil e ACBrNFeUtil os endereços atuais do site do portal da NFe estão comentados, descometei os mesmos e funcionaram em homologação, alguém já fez o teste em produção?