Ademar DC

Boa tarde, fontes atualizados e testados, funcionando !! Obrigado.

Bom dia, ao realizar os testes no CT 4.00 de MG na funcionalidade de Status a mensagem estava vindo vazia, ao debugar o código vi essa condição no ACBrCTeWebServices, porém no arquivo em anexo eu notei que usa o "Cte" também, sem o T maiúsculo, retirei essa condição e deixei apenas o "Cte", depois disso formatou correto o status. if FPConfiguracoesCTe.Geral.VersaoDF >= ve400 then CTeRetorno := TRetConsStatServ.Create('CTe'); else CTeRetorno := TRetConsStatServ.Create('Cte'); retorno_status_400.xml

Comigo também, hoje 29/05 ainda persiste o problema, verifiquei o portal do SPED de MG e ele diz que foi implementado, porém até o hoje não consegui testar.

Boa tarde @Daniel InfoCotidiano, beleza irei atualizar os fontes, obrigado pela atenção.

@Daniel InfoCotidiano, bom dia, ok, no aguardo.

@Daniel InfoCotidiano Boa tarde, o contato do Bradesco me passou o seguinte manual sobre Layout de cobrança no CNAB 400 (segue em anexo, Layout cobrança CNAB 400.pdf), a parte de informar o nosso número está igual ao que já temos: 071-082 - Identificações do Título no Banco (Nosso Número) (Página 17) "EMISSÃO DO BOLETO PELO BANCO Cobrança com Registro: nesse caso, esse campo deverá ser enviado com “zeros”, pois o sistema informará o Nosso Número no arquivo-retorno, quando da confirmação de entrada." Porém, na página 18, posição 093 - Condições para Emissão do Boleto de Cobrança tem-se a condição: "Se for igual a 1 = o Banco emite o boleto e processa o registro. ⇒ Se o Nosso Número for informado nas posições 71 a 82 do registro de transação, o Banco assume" Nesse caso, é contraditório porém não impeditivo, ele orienta a mandar com 0, porém se informar um número válido ele assume o número, mesmo sendo o banco o responsável pela emissão.

@Daniel InfoCotidiano Bom dia, eu consultei essa mesma documentação, solicitei ao cliente para entrar em contato com o Bradesco para que eles nos forneçam a documentação oficial deles com relação à carteira 09, por enquanto a única fonte que posso repassar é de um outro site: (https://www.neointerativa.com.br/_home/asp/Cobranca_Bancos_e_Carteiras.asp), porém assim que tiver retorno do Bradesco irei notifica-los.

Bom dia @Juliana Tamizou, a lógica de geração em si acredito que esteja correta, porém esse condição abaixo estava zerando o Nosso Número, caso o ACBrTitulo.NossoNumero seja igual a '0015' e a expressão depois do igual seja também '0015' (considerando que o tamanho máximo seja somente 4 dígitos) ele zera o NossoNumero em seguida com as instruções do IF. (ACBrTitulo.NossoNumero = PadLeft(ACBrTitulo.NossoNumero,ACBrBanco.TamanhoMaximoNossoNum,'0')) Dessa forma, ao gerar os boletos para o cliente estava zerando o NossoNumero mesmo ele sempre indo preenchido para o componente, essa condição creio que seria apenas para pegar caso o NossoNumero não seja preenchido ou seja todo preenchido com zeros ele seja formatado para o tamanho no leiaute com os zeros para ficar no tamanho correto.

Bom dia, realizei os testes atualizando o componente e funcionou corretamente, obrigado.

Bom dia, notei que ao realizar a consulta de GTIN produtos que possuem NCM com 0 a esquerda estão vindo sem o mesmo, por exemplo: Para o EAN 7898970338246 Padrão: Para resolver apenas inseri um PadLeft, considerando que sempre o NCM deve ter 8 caracteres, no tratamento de dados no retorno, no método TGTINConsulta.TratarResposta: FNCM := GTINRetorno.NCM.PadLeft(8,'0'); Com PadLeft: PS: Não achei tópico específico para ACBRGtin então lancei neste mesmo. É válida a alteração ? (Arquivo em anexo) ACBrGTINWebServices.pas

Boa tarde, essa alteração chegou a ser analisada ou já efetuada ?

Entendi, obrigado.

Boa tarde, realizei os testes novamente e continua igual, se eu informar: "Params=NaoGerarGrupoRps" com a função IndexOfName, apesar do fSl conter a palavra ele não consegue identificar. Porém, se eu informar "Params=NaoGerarGrupoRps:", com esses dois pontos no final, ele reconheceu o parâmetro, vi o commit com relação a outras cidades e resolvi experimentar, ai ele reconheceu a presença do parâmetro, porém acredito que ele esperava uma chave=valor, no debug aparece "NaoGerarGrupoRps=" apenas, mas funciona.

Sim, quem emite o boleto e envia é o Bradesco, o cliente só manda a remessa. Se não me engano é um contrato que a carteira escolhida permite essa opção do banco emitir e mesmo assim o número ser de acordo com a empresa.

Bom dia, um cliente foi gerar um arquivo remessa para o banco Bradesco, CNAB 400, e após enviar a remessa o mesmo foi notificado que o "Nosso número" não está informado na remessa, ao ver a lógica notei que estava caindo nessa condição: Arquivo: ACBrBancoBradesco.pas Método: ValidaNossoNumeroResponsavel (linha 100) Revisão: 28437 (06/02/2023 10:06) if (ACBrTitulo.NossoNumero = '') or (ACBrTitulo.NossoNumero = PadLeft(ACBrTitulo.NossoNumero,ACBrBanco.TamanhoMaximoNossoNum,'0')) then begin ANossoNumero := StringOfChar('0', CalcularTamMaximoNossoNumero(ACBrTitulo.Carteira, ACBrTitulo.NossoNumero) ); ADigVerificador := '0'; end Porém como o número é passado preenchido, e essa condição é para os vazios acredito que tenha um problema com essa segunda condição: (ACBrTitulo.NossoNumero = PadLeft(ACBrTitulo.NossoNumero,ACBrBanco.TamanhoMaximoNossoNum,'0')) o nosso número ao debugar tem o valor de exemplo: "00000001234", quando comparado com o PadLeft desse valor (considerando o tamanho máximo como 11) ele resulta também em "00000001234", e acaba caindo na condição e resultando em "00000000000", como se estivesse vazio. Ao remover essa segunda condição o funcionamento voltou ao normal para meu cliente. Segue o arquivo modificado em anexo. ACBrBancoBradesco.pas

Boa tarde, o "contrário" realmente foi um erro meu, porém quis dizer que ele informava negativo para a presença do parâmetro quando nesse caso deveria informar positivo pois ele estava informado no arquivo. Fiz essa pequena POC estática apenas para ilustrar o que quis dizer: procedure TForm1.Button1Click(Sender: TObject); var fs : TStringList; i : Integer; begin // i := 99; fs := TStringList.Create(); fs.Add('teste_de_insert'); i := fs.IndexOfName(Trim('teste_de_insert')); if i >= 0 then showmessage('IndexOfName'); i := fs.IndexOf(Trim('teste_de_insert')); if i >= 0 then showmessage('IndexOf'); end; No primeiro caso (IndexOfName) ele retorna -1, esquivando da condição, já com o indexOf ele já encontra a palavra no TStringList e retorna a posição (no caso 0), então durante o debug no componente notei que o stringlist estava preenchido com a string "NaoGerarGrupoRps", porém na hora de verificar utilizava o IndexOfName, e assim o código seguia como se não tivesse informado o parâmetro. Compilei algumas vezes (tanto a POC quanto o ACBR) e o resultado se manteve igual na execução.

Compreendo, no arquivo realmente consta os dois links, contudo contatei a IPM pois já tivemos alguns problema com a anteriormente e fui respondido da seguinte forma: (segue em anexo o print do email), o exemplo sobre o parâmetro será citado em resposta ao comentário do Italo.

Bom dia, estava realizando alguns testes e notei que haviam alguns detalhes com relação ao componente ACBRNFSeX, o primeiro deles é com relação aos parâmetros, ACBrNFSeXParametros, o método "TemParametero" utilizava o método IndexOfName e mesmo contendo o parâmetro ele retornava o contrário, portanto alterei para IndexOf e funcionou corretamente. O outro detalhe é com relação ao provedor IPM, no GravarXML a homologação só estava ativa para a versão 1.0 (não encontrei no código nada sobre essa condição), porém estudando os manuais não encontrei razão para esse condição e a removi, deixando apenas a validação se o ambiente é homologação. Apesar de serem alterações triviais anexei os arquivos aqui de uma vez. ACBrNFSeXParametros.pasIPM.GravarXml.pas

Bom dia estou com o mesmo problema, ao atualizar o total da nota de acordo com os valores do PISST e do COFINSST gera um erro de Schema mesmo indicando que compõe o valor da nota, agora indicando que compõe valor da nota e não agregando realmente o valor no somatório total da NFe ele emite corretamente. PISST_COFINSST_ERRO_SCHEMA.xml

Estou com o ACBR na versão 21838 com os schemas atualizados, porém ao tentar emitir um CTe no modo SVC-SP (HOMOLOGAÇÃO) estou me deparando com o erro "17760 -> 851-Rejeição: Endereço do site da UF da Consulta via QR Code diverge do previsto", porém eu chequei o ACBrCTeServicos e o "URL-QRCode" está correto, chequei no componente no arquivo ACBrCTe o método "GetURLQRCode" que os queryParams da URL estão de acordo com o MOC 3.0 da CTe (em especial a regra de validação G242 -> "Se tipo de emissão for igual a Normal ou SVC: O parâmetro sign não deve ser informado no QR-Code") então fiquei sem saída e não estou conseguindo emitir CTe em SVC-SP (HOMOLOGAÇÃO). Alguém pode confirmar que o erro está no servidor ou então se o componente está com algum erro ? XML's em anexo. 9-env-lot.xml 318000015133913-ped-rec.xml 318000015133913-pro-rec.xml 9-rec.xml

Recebi um retorno hoje da SEFAZ MG, fica aqui de informação, pode encerrar o chamado. "Senhor(a), Segundo retorno do nosso setor técnico, a homologação da 2020.006 ficou para 01/03/2021. A homologação da 2020.007 vai depender de definição da RFB que informou que vai marcar nova data. À disposição."

Alguém conseguiu enviar em homologação algum xml com o <indIntermed> presente ? Diferente do que vi no fórum que em sua maioria era acerca de "Indicador de Intermediador ausente", o meu problema está no contrário, a nota não emite se o <indIntermed> está presente, estou com o ACBR na 21294 de Sexta(05/02/2021) e os Schemas atualizados. Já comuniquei a SEFAZ porém não obtive retorno, verifiquei o Schema disponível na site da própria SEFAZ MG e condiz com o XML gerado pelo componente. 6155-env-lot.xml 6155-rec.xml

Bom, aqui em emissão normal está com erro na SEFAZ, mesmo com o ACBR na 21294 de Sexta(05/02/2021) e os Schemas atualizados com o ACBR e também verifiquei com o site do portal da NFe e deu erro na validação do schema ao emitir com o <indIntermed>, schema do leiaute de 28/01/2021, e também no validador da Sefaz RS apresenta o mesmo erro de validação do Schema, onde o <indIntermed> não deveria existir. Realizada a emissão em HOMOLOGAÇÃO, que pela NT está operante desde 01/02/2021. Você fez alguma alteração e conseguiu emitir com o <indIntermed> 0 ou 1 ? ou apenas emitiu sem o indIntermed ? Obs: Deixei o Xml de envio e a resposta da Sefaz anexados. 6155-env-lot.xml 6155-rec.xml

Perdão eu não tinha achado, obrigado, pode encerrar o chamado.

Gostaria de saber qual componente e como eu faço o carregamento do XML de inutilização (Não XML da NFC-e normal que foi inutilizada, e sim o XML do retorno da Inutilização), preciso carregar isso em memória e exibir para o Usuário. Nos eventos eu não achei um "teInutilizacao" apenas os outros de CTe, cancelamento e etc.