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?

Ok, obrigado Italo, atualizei aqui e realmente já esta correto.

Boa tarde pessoal, estou tento o alerta do comente que o Número da RE não é valido. No Campo RE dos detalhes de exportação esta sendo informado esse número 150401963001 pelo que verifiquei nos códigos do componente o motivo é que quando é gerado o XML no Detalhe de Exportação é chamado o método "DFeUtil.ValidaRE". Então abri esse método e acredito que encontrei uma correção a ser feita conforme os comentário do métodos: // AValue = AANNNNNNNSSS // Onde: AA Ano corrente da geração do documento // NNNNNNN Número sequencial dentro do Ano ( 7 dígitos ) // SSS Serie do RE (001, 002, ...) Verifiquei que existe uma comparação que acredito que esta fazendo um copy errado dessa String, atual: else if not ((StrToInt(copy(Avalue, 2, 2)) >= ano -1) and (StrToInt(copy(Avalue, 2, 2)) <= ano +1)) then Acredito que seria essa a condição do teste: else if not ((StrToInt(copy(Avalue, 1, 2)) >= ano -1) and (StrToInt(copy(Avalue, 1, 2)) <= ano +1)) then Estou anexando o código fonte com a sugestão desta correção. Abraços. ACBrDFeUtil.pas

Obrigado Juliomar.

Bom dia Juliomar, essa alteração será possível?

Ok juliomar,. vou desenvolver minha integração, com base no que me passaram e assim que concluir repasso para subir no SVN. Pois da maneira que ficou ainda é necessário uma refatoração, pois o ncc.star concluir com base no NFS-e, e ainda tem muita coisa no código do NFS-e no meio.

Olá pessoal, como no ano passado conversei com o ncc.star aonde ele me mandou via e-mail o componente que segundo ele para a repom tava funcional, e já existia algo para o e-frete, estou dando continuidade no desenvolvimento deste componente, nesta versão mesmo, se alguém tiver um repositório dos fontes na última versão seria o ideal, ou então caso exita a possibilidade do fórum disponibilizar um repositório de desenvolvimento para esse seria bem vindo, caso contrário posso criar um repositório no GitHub para o desenvolvimento até que se for de interesse do fórum em adiciona-lo como um projeto do ACBr. Sobre a minha integração que tenho aqui para fazer é com a RODOCRED, estou dando sequencia no desenvolvimento, refatorando as classes que são necessárias, criando novas classes para esse provedor, como segundo o ncc.star ele iniciou o desenvolvimento baseado no NFSe, pegando o componente e adicionando suas funcionalidades, eu estou aproveitando a arquitetura de classes utilizadas, e assim que possível irei remover o que existe ainda da NFSe. Hoje recebi todos os manuais e XSD's do pessoal da Rodocred com as informações para o Desenvolvimento, também posso contribuir com isso caso seja necessário.

Boa tarde pessoal, também tenho interesse nesse projeto, já existe algo pronto, estou querendo para a Rodocred, caso não tenha pronto para esse prestador tenho intenção de auxiliar no desenvolvimento deste componente.

Gostaria de sugerir uma alteração para o fonte ACBrMDFeUtil.pas no método ValidaModalMSXML pois não esta disponível CoInitialize(nil) e o CoUninitialize, se faz necessário para o acesso em um ambiente de threads no Delphi (no meu caso Servidor REST Delphi XE5), verifiquei que no método ValidaMSXML já possui, somente adicionei no método ValidaModalMSXML. Se for possível enviar essa alteração para o SVN agradeço. O fonte alterado foi este que esta em anexo. ACBrMDFeUtil.pas ACBrMDFeUtil.pas

Boa tarde Juliomar, acabei de atualizar com a última versão do Repositório e continua ocorrendo. Em anexo o fonte com a alteração que fiz, que passou pela validação. pcnNFeW.pas

Esqueci do anexo no post anterior, segue o mesmo abaixo. pcnNFeW.pas