francinaldoac

Eu já resolvi fazendo isso LFill(NUM_ACDRAW). Estou apenas reportando para o componente ser corrigido. Obrigado.

Bom dia, Tem um problema no registro C120, o campo NUM_ACDRAW é opcional e do tipo string, quando ele não é informado no registro, o componente está fazendo o preenchimento com zeros até o limite do tamanho do campo, isso causa erro no validador. Detectei que o problema reside no método "WriteRegistroC120" do código abaixo que está no arquivo ACBrEPCBloco_C_Class.pas : procedure TBloco_C.WriteRegistroC120(RegC100: TRegistroC100); var intFor: integer; strCOD_DOC_IMP: string; begin if Assigned(RegC100.RegistroC120) then begin for intFor := 0 to RegC100.RegistroC120.Count - 1 do begin with RegC100.RegistroC120.Items[intFor] do begin case COD_DOC_IMP of diImportacao : strCOD_DOC_IMP := '0'; diSimplificadaImport : strCOD_DOC_IMP := '1'; end; Add( LFill('C120') + LFill(strCOD_DOC_IMP) + LFill(NUM_DOC__IMP) + LFill(PIS_IMP,0,2) + LFill(COFINS_IMP,0,2) + LFill(NUM_ACDRAW, 20)) ; // RegistroC990.QTD_LIN_C := RegistroC990.QTD_LIN_C + 1; end; end; // Variavél para armazenar a quantidade de registro do tipo. FRegistroC120Count := FRegistroC120Count + RegC100.RegistroC120.Count; end; end; O trecho LFill(NUM_ACDRAW, 20) causa esse comportamento, corrigi fazendo a alteração para LFill(NUM_ACDRAW).

As pastas estão separadas, como disse funcionava normalmente há alguns dias, então passou a informar o erro, não houveram mudanças nessa rotina nas últimas semanas, não vi nota técnica com mudanças, por isso resolvi perguntar aqui no fórum se alguém sabia alguma coisa.

Copei os schemas do svn, mesmo assim o erro continua, não fiz mudança nessa rotina nas últimas semanas, nem alterei os schemas, simplesmente começou a dar o erro, há uns dois dias.

Eu também pensei que fosse, já tinha feito isso sem sucesso, por isso abri esse tópico.

Bom dia! Estou com o erro "Cabecalho - Versao do arquivo XML nao suportada.CStat: 239" ao consultar a DistribuicaoDFe do MDFE, usando o método ACBrMDFe.DistribuicaoDFePorUltNSU, isso começou ontem, verificando o portal da MDFe não encontrei mudanças para esse mês, alguém está tendo o mesmo problema?

Boa tarde, Existe algum projeto em andamento para denvolvimento da API, ou isso não está no radar da Acbr? Atualmente os novos das empresas estão sendo desenvolvidos usando a API e não mais o método de troca de arquivos texto.

Juliomar, meu cliente quer apenas enviar promoções para vários clientes ao mesmo tempo, sem lista de transmissão, individualmente, as conversas vão fluir pelo whatsapp web, tendo em vista isso, qual a API mais simples?

Em termos de preços e simplicidade, você daria alguma opinião? No caso o cliente que compra o serviço junto a integradora?

Boa tarde, Eu já havia escutado há uns meses atrás, mas isso já faz mais de um ano, então queria mais uma troca mais prática de experiências com os desenvolvedores do fórum.

Bom dia, Pessoal, andei olhando os posts sobre API whatsapp aqui no fórum e também pesquisando na internet, quero desenvolver uma integração, mas gostaria de saber de quem já desenvolveu, a experiência com essas APIs, já li sobre gupshup, twilio, zenvia, vi também um componente em delphi o "tinject", mas que dizem que pode ocorrer o banimento do número do cliente. Queria poder usar um ambiente de testes desses componentes, mas pelo li até agora apenas a twilio possui um. Existe alguma plataforma brasileira que vocês indicam? Grato.

Alguém sabe se é problema na SEFAZ SP?

Bom dia! Estou com o mesmo problema do colega, o emissor do CTe é de São Paulo, já conferi todos os dados e estou recebendo: "Rejeição: CNPJ-Base do Emitente difere do CNPJ-Base do Certificado Digital" ao tentar fazer o desacordo.

Boa tarde, Sim, havia visto no manual que esses eram os métodos necessários para homologação, estou no momento desenvolvendo a integração básica, quando terminar vou tentar desenvolver o que falta. Os métodos de consulta são importantes porque de outra forma temos que sempre enviar os dados completos dos motoristas, veículos, proprietários antes do envio do CIOT, a não ser que façamos no sistema interno o registro que aquele cadastro já foi enviado. Obrigado.

No manual eles colocaram apenas o métodos necessários para homologação do integrador junto ao eFrete, mas lá eles falam dos outros métodos, nesse caso os de consulta, isso seria interessante, porque o sistema poderia consultar se o motorista, veículo, proprietário já existe na base do eFrete, isso evitaria ter que enviar esses dados. Exemplos: https://dev.efrete.com.br/Services/MotoristasService.asmx?WSDL https://dev.efrete.com.br/Services/MotoristasService.asmx?op=Obter

Sim, já fiz o cadastro lá e estou com acesso ao ambiente de homologação.

Bom dia! Estou implementando o ACBr CIOT, vi que a maior parte dos métodos de consulta não foram implementados, como o obter: motorista, veiculo, proprietário. Tem alguma previsão ou alguém trabalhando nisso? Grato mais uma vez.

Boa tarde, O problema eram os schemas desatualizados, atualizei pela pasta do svn "Acbr\Exemplos\ACBrDFe\Schemas\CTe" e deu certo agora. Obrigado.

Sim, eu atualizei logo cedo hoje, não testei com demo do exemplo, mas peguei de lá o código fonte para enviar o evento. Eu depurei o código até a função que pega a descrição do evento, verifiquei que estava OK, porém quando olho o XML que vai ser enviado, está sem os acentos e "cedilha" e dá o erro. Tem alguma coisa a ser atualizada nos "esquemas", porque não fiz atualização deles.

Bom dia, Ao enviar um evento de Prestação de Serviço em Desacordo no CTe, estou recebendo o erro de validação abaixo: Verifiquei que no campo "EP02 - DescEvento" está sendo enviado o valor "Prestacao do Servico em Desacordo" e de acordo com o manual deveria ser "Prestação do Serviço em Desacordo". Eu encontrei a função abaixo e fiz a correção: function TInfEvento.getDescEvento: String; case FTpEvento of tePrestDesacordo : Desc := 'Prestação do Serviço em Desacordo'; Porém o erro persiste, isto é, o XML continua sendo enviado com o valor "Prestacao do Servico em Desacordo". Vocês poderiam ajudar.

Funcionou perfeitamente Italo, obrigado.

Bom dia, Ao fazer isso da função : TpEventoToDescStr(ACBrCTe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[i].procEvento.tpEvento); Quando o evento é 310611 "MDF-e Cancelado", a função retorna "NaoMapeado", assim também a função: TpEventoToStr(ACBrCTe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[i].procEvento.tpEvento) Retorna o valor -99999. Meu componente está atualizado, tem algum problema ou essa função está descontinuada? Grato.

certo, obrigado.

Bom dia! Na geração do cnab400 da caixa econômica, no registro de transação, o campo Sacado.NomeSacado, está sendo gravado no lugar do campo Sacado.SacadoAvalista.NomeAvalista, posição 368 do registro. Unit ACBrBancoCaixa, procedure GerarRegistroTransacao400. O código estava assim: PadRight(Sacado.NomeSacado, 22) + // 368 até 389 - Nome do Sacador Avalista Na verdade deveria ser assim: PadRight(Sacado.SacadoAvalista.NomeAvalista, 22) + // 368 até 389 - Nome do Sacador Avalista Em anexo o manual, observar na página 21, essas informações são diferentes, no meu caso a caixa solicita que deixe o campo "Sacado/Avalista" em branco na remessa, mas preciso preencher o outro campo que é necessário. Desde já agradeço. Manual_de_Leiaute_de_Arquivo_Eletronico_CNAB_400 (1).pdf ACBrBancoCaixa.pas

Bom dia! Segue código fonte. ACBrBoleto.pas