José M. S. Junior

Boa tarde, Notei que está preenchendo o código desconto como "0" que corresponde a não conceder desconto, veja: https://acbr.sourceforge.io/ACBrMonitor/TabelappreenchimentoArquivoINI1.html Como preencher o campo TipoDesconto ou TipoDesconto2 (Tipo de Desconto) 0 - NaoConcederDesconto 1 - ValorFixoAteDataInformada 2 - PercentualAteDataInformada 3 - ValorAntecipacaoDiaCorrido 4 - ValorAntecipacaoDiaUtil 5 - PercentualSobreValorNominalDiaCorrido 6 - PercentualSobreValorNominalDiaUtil 7 - CancelamentoDesconto

Creio que no momento da homologação eles podem solicitar os XMLs gerados pela aplicação. No demo SATTest pode ver exemplos de como obter o XML a partir do componente. A utilização com Integrador Fiscal, toda validação e comunicação é realizada pelo mesmo. O que o ACBr faz é gerar o XML na pasta de monitoramento do Integrador, por isso é necessário um timeout mínimo para aguardar essa resposta do Integrador.

Aparentemente está ocorrendo alguma incompatibilidade com seu Certificado Digital. De uma olhada neste tópico, parece ter ocorrido o mesmo problema

Bom dia Marcio o Certificado está instalado corretamente? ao abrir pelo navegador deveria solicitar o certificado e ao menos mostrar a página abaixo: Esse erro 500 indica que não está conseguindo o acesso... Quais as configurações SSL está utilizando? Tente da seguinte forma: Quanto a alterar a versão do layout, realmente é em tela... Não é comum alternar versões entre os DFe, outra opção seria editar o próprio arquivo ACBrMonitor.ini e utilizar o método ACBr.LerIni.

Bom dia No manual em que o Banco está se baseando especifica essa questão de ter que deixar em branco as posições não utilizadas? Teoricamente deveria ser dessa forma mesmo por ser um campo Alfa, mas no Manual base utilizado para implementar esse Banco tem uma observação quanto a isso "G069" onde diz que precisa sem complementado com zero.

Olá, Devido a contradições na leitura do campo "Nosso Número" nos arquivos de Retorno dos bancos, adicionamos a propriedade: LerNossoNumeroCompleto no componente ACBrBoleto para definir a forma de leitura desse campo. Ao gerar a Remessa o próprio componente se encarrega de calcular o digito que complementa o Nosso Número e também outras particularidades. Mas ao ler o arquivo de Retorno o componente sempre lê apenas o Número Fixo, assim como é passado na geração da remessa, porém muitos queriam obter esse número de forma completa, ou seja, com o dígito verificado e demais particularidades. Como solução criamos uma nova propriedade "LerNossoNumeroCompleto" para configurar isso, com essa opção selecionada pode obter o NossoNumero completo assim como é retornado no arquivo, caso contrário permanece da mesma forma, lendo apenas o Número Sequencial, conforme alimentado no componente. Essa nova propriedade já está configurada para o Banco Sicred, se houver necessidade para os demais Bancos, pode ser utilizado essa configuração para o mesmo fim.

Boa tarde, em ambiente de Produção ocorre o mesmo erro? Verifique se consegue acessar a url pelo seu navegador... Outro detalhe, notei que está utilizando a versão 1.0 na geração do GNRE, está correto?

Boa tarde Precisa passar as tags abaixo no arquivo .ini [infRespTec] CNPJ= xContato= email= fone= veja o modelo completo no manual: https://acbr.sourceforge.io/ACBrMonitor/ModeloNFeINICompleto.html

Bom dia, também é possível passar diretamente o número do banco... Basta passar zero (0) na tag "indiceACBr" e passar o código 084 na tag "Numero"

@Marcio Tullio, por favor atualize para ultima versão e refaça os testes

Boa tarde, Segue um modelo com dados básicos. Não significa que funciona exatamente com estes campos para o seu cliente, vai depender do tipo de operação dele, rota, etc... Mas são as informações iniciais que precisa preencher para gera o MDFe MANIFESTO_mod.txt

Boa tarde, se possível anexe o manual que a sua agencia está utilizando para que possamos analisar melhor. Pois na verdade o campo que setá sendo preenchido no retorno não se trata da Carteira e sim o Tipo de Cobrança.

Boa tarde A mensagem de multa impressa no boleto é sempre em R$, note que está preenchendo o valor calculado baseado no percentual que informou. Se notar na remessa vai ser informado o percentual conforme estabelece o manual.

Pode ser isso que está ocorrendo neste caso então @Italo Jurisato Junior?

Bom dia Tem um projeto em desenvolvimento na pasta Branches do repositório mas ainda não está disponível junto ao componente ACBrBoleto original.

O Tipo de Cobrança corresponde ao campo CaracTitulo Valores válidos para o campo CaracTitulo 0 - Cobrança Simples 1 - Cobrança Vinculada 2 - Cobrança Caucionada 3 - Cobrança Descontada 4 - Cobrança Vendor https://acbr.sourceforge.io/ACBrMonitor/TabelappreenchimentoArquivoINI.html

Este processo realmente é burocrático, mas como não existe o equipamento POS em produção, creio que os dados são pré-configurados no seu sistema (Bandeira, Adquirinte), não é algo que vai precisar digitar toda vez ou solicitar ao cliente. O ID pagamento já vai obter através do método EnviarPagamento, os demais dados estão previamente cadastrados ou serão valores fixos. Para o POS (até o momento) o IDPagamento é o principal que precisa ter registrado na base de dados para cada pagamento realizado.

O problema parece ocorrer apenas na geração do PDF, pode ser o tipo de fonte dos itens, experimente mudar a fonte (por exemplo Arial) em "Alterar Fonte Itens" depois Salve as alterações.

Sim, pois só apos autorizar pagamento no Simulador, vai conseguir consultar... Isso é feito manualmente durante a homologação.

Bom dia, qual versão do ACBrMonitor está utilizando?

Não consegui simular o problema... Mas estamos investigando, o retorno do envio foi autorizado pelo XML, mas na resposta não foi gerada...

Por favor anexe seu ACBrMonitor.ini

Correto, a tabela de identificação de Ocorrencias é a do manual da lib https://acbr.sourceforge.io/ACBrLib/IndicedeCodigosTituloINI.html

Bom dia Sim, o passo 2 é utilizado para homologação junto a SEFAZ utilizando o Simulador. Como não existe uma integração real com o equipamento POS está sendo utilizado valor fixo, o que muda será apenas os campos retornados pelo Simulador (ID, ChaveAcesso, Número de Aprovação). No passo 3 precisa forçar a digitação, visto que não tem como obter essa informação direto do aparelho POS até o momento. Diferente do que ocorre com o TEF, onde já consegue obter os dados através da integração com o Agente Financeiro.

Experimente diminuir a largura na configuração do cupom