mscorteganha

Perfeito, Entrarei em contato com eles, e reporto aqui assim que tiver um retorno.

Boa tarde @Italo Giurizzato Junior, Existe alguma de confirmarmos esta situação?

Boa tarde @Italo Giurizzato Junior, Emitente está situado no estado da Bahia. Este CT-e atende as regras para o CT-e Simplificado. Montei o mesmo CT-e utilizando o programa de exemplo do ACBR e recebo o mesmo retorno. A mensagem de serviço paralisado (curto prazo) é retornada.

Boa tarde. Se entendi bem, o emitente tem que estar habilitado para emitir um CT-e Simplificado? Atualmente o cliente emite CT-e Normal sem problemas. Em algumas operações, foi orientado pelo tomador de serviço a emitir o CT-e simplificado para diminuir a quantidade de documentos emitidos. (esta operação atende aos requisitos do CT-e Simplificado)

Boa tarde Srs, Estamos desde o dia 19/11/2024 recebendo a mensagem de serviço paralisado (curto prazo) quando tentamos emitir um CT-e Simplificado, em produção. Consultamos hoje (21/11/2024) a disponibilidade do serviço no site do DF-e (https://dfe-portal.svrs.rs.gov.br/Cte/Disponibilidade) e conforme imagem o serviços está disponível. Se tentarmos emitir o CT-e em homologação, o cte é emitido sem problemas. Fontes do ACBr atualizados na data de hoje (21/11/2024). Schemas atualizados. Para CT-e do tipo NORMAL, a emissão está ocorrendo sem problemas em produção. Alguma dica como proceder neste caso?

Após incluir o comando "CLO" antes do "OPN" não recebemos mais o erro. Agradeço ao @Daniel Simoes pela valiosa dica.

Vou tentar fazer este procedimento @Daniel Simoes. Reporto aqui quando tiver um retorno. Agradeço a atenção.

O Sistema trata esta situação, desativando o ACBRTefAPI, para poder comunicar com o pinpad via ACBRAbecsPINPAD. Ativa quando necessário e desativa quando necessário.

Utilizamos o ACBrAbecsPinPad para exibir o QRCode do PIX em um PINPAD (Gertec PPC930). Em alguma situações (ainda desconhecidas) recebemos em tela o seguinte erro. Error: 9 - Error decoding data received via "Secure Communication"; or Cleartext command received with "Secure communication" established. A solução provisória, é fechar a comunicação com o componente e abrir novamente. Alguém já passou por algo parecido?

Bom dia, Após última atualização da DLL payGO Windows para versão 4.1.30.0 o problema parou de ocorrer.

Bom dia, Vou enviar e reporto aqui.

Olá pessoal, Notei um comportamento anormal no TEF (mesmo utilizando o demo). Quando envio alguma mensagem para o PINPAD utilizando o método "ACBrTEFAPI1.ExibirMensagemPinPad(Msg)", e após tento solicitar o CPF no PINPAD utilizando o método "ACBrTEFAPI1.ObterDadoPinPad(dpCPF)" o PINPAD mostra a informação para digitar CPF mas logo em seguida, aparece a mensagem "PROCESSANDO" e interrompe a digitação do CPF no PINPAD. Se chamar na sequencia o método "ACBrTEFAPI1.ObterDadoPinPad(dpCPF)" funciona normalmente. Utilizando o TEFAPIDemo.exe, basta clicar no botão "Msg PinPad" e em seguida no botão "Solicita CPF", que o problema irá ocorrer. Alguém já passou por isso? *** estou utilizando a nova DLL (4.1.27.1) com o componente TACBrTEFAPI. *** estes testes foram feitos em homologação.

Obrigado pelo retorno. Realmente tinha um erro no meu código, e não estava enviando a observação corretamente. Agradeço a disponibilidade e peço desculpas pela falta de atenção.

Bom dia, Estou tentando gerar um CT-e Complementar (versão 4.0) e mesmo alimentando o componente com a tag Compl.xObs := "minha observação" não está indo a tag no XML. É permitido observações no CT-e Complemtar? O interessante é que na versão 3.0 esta observaçõ pe enviada no XML do CT-e complementar.

Segue arquivo ACBrNFeNotasFiscais.pas com ajuste para regra de validação 772, incluindo exceção "UF entrega x UF emit". ACBrNFeNotasFiscais.pas

Boa tarde. Ainda seguindo nesse erro de validação (772). Deve-se acrescentar na validação as exceções, (UF local de entrega e UF local de retirada) conforme manual de orientações. "Exceção 1: A regra de validação não se aplica se informada UF do local de entrega (tag: entrega/UF) diferente da UF do emitente (tag: enderEmit/UF) e não informada UF do local de retirada (tag: retirada/UF); Exceção 2: A regra de validação não se aplica se informada UF do local de retirada (tag: retirada/UF) diferente da UF do destinatário (tag: enderDest/UF) e não informada UF do local de entrega (tag: entrega/UF); Exceção 3: A regra de validação não se aplica se informadas UF do local de entrega (tag: entrega/UF) e UF do local de retirada (tag: retirada/UF) diferentes entre si; (NT 2015.003)". Ajustei no código, apenas a exceção para a UF do local de retirada. (ACBrNFeNotasFiscais.pas) if not UFCons then begin GravaLog('Validar: 772-Op.Interstadual e UF igual'); if (nfe.Ide.idDest = doInterestadual) and (NFe.Dest.EnderDest.UF = NFe.Emit.EnderEmit.UF) and (NFe.Dest.CNPJCPF <> NFe.Emit.CNPJCPF) AND (NFe.Entrega.UF = NFe.Emit.EnderEmit.UF) then AdicionaErro('772-Rejeição: Operação Interestadual e UF de destino igual à UF do emitente'); end; Isso deve-se ao seguintes cenários. SEFAZ SC UF Emitente = 'SC' UF Destinatário = 'SC' UF Local Entrega = 'RS' CFOP = '6949' Nota Autorizada. SEFAZ RS UF Emitente = 'RS' UF Destinatário = 'RS' UF Local Entrega = 'SC' CFOP = '6949' Utilizando estas informações você receberá a Rejeição 523 "Rejeição: CFOP não é de Operação Estadual e UF emitente igual à UF destinatário [nItem: 999]". Esta é uma rejeição facultativa, a critério da sefaz. ***Ainda não sei como funciona a questão da coloboração com a equipe do ACBR para implementação dos ajustes.