José M. S. Junior

Pode utilizar das duas formas.... Se passar via .ini vai dar preferência para o mesmo, mas o Contrato e Senha precisa estar gravado nas configurações (em tela)

Se conseguir um passo a passo podemos tentar simular o problema, mas até o momento não identificamos... Mas de fato a aplicação pode definir o mesmo path do .exe caso não encontre o path especificado...

Boa tarde, esse erro pode estar relacionado a diversos fatores: Problema na instalação do certificado, Windows desatualizado, configuração SSL do componente... Nas configurações SSL Type está utilizando TLS_1.2 ?

Esse path de rede está acessível a partir desta máquina? O erro inicial aparentemente é que não está encontrando o arquivo... Estas configurações de diretórios é padrão para todos os DFes, o diretório definido vai ser utilizado para gerar todos os DFes. O tipo do documento CTe / NFe e a estrutura Evento / Data / CNPJ.... É definida pelo próprio componente. É necessário verificar os logs para saber exatamente qual a sequencia de métodos e retornos, mas todos os DFes utilizam essa parametrização de diretórios e não ocorre esse tipo de problema, imagino que seja alguma restrição ou lentidão no acesso ao diretório.

Como está configurado os diretórios no ACBrMonitor.ini? Se possível anexe o mesmo...

Verifique após qual método está ocorrendo a alteração. Se possível anexe o log.txt do ACBrMonitor.

Bom dia, favor atualizar os fonte. Obrigado!

Bom dia, a sequencia do CFe é definida pelo próprio aparelho... Experimente extrair o log do aparelho para ver se identifica algo quanto ao momento de quebra de sequencia, mas segundo os fabricantes a casos que isso realmente pode ocorrer.

Poderia anexar um arquivo de retorno válido para homologação?

O aparelho realmente esta utilizando a versão 0.07? De uma olhada neste post sobre possíveis erros:

Bom dia, pode realizar testes utilizando o EmuladorSAT utilizando a dll do MFe, mas para homologar de fato com a SEFAZ vai precisar sim do aparelho MFe, podendo ser um aparelho SDK específico para desenvolvimento.

Bom dia José, note os fontes atualizados estão passando por uma refatorações, muitos métodos em comum entre bancos estão sendo unificados, centralizando na unit ACBrBoleto, as particularidades de cada banco estão sendo adicionadas em funções separadas nas quais podem ser parametrizadas conforme a exigencia cada banco. Note que no problema citado neste tópico foi resolvido dessa forma... Está tendo outras divergências? Se sim por favor poste quais as posições no arquivo está com problema.

Bom dia, é o nome da tag que diferencia se é ou não Substituição tributária para o código CST que informar.

Bom dia No Somatório dos itens na tag "vIPIDevol" aparentemente está errado a soma, não deveria ser: 525.33?

Boa tarde Não tem parâmetro para isso.. Se possível anexe o XML para verificação.

Esta correção foi realizada hoje... Ainda não está no ACBrMonitor, mas estará na versão semanal (ainda esta semana) juntamente com outros ajustes que estão sendo realizados.

Bom dia, Atualizado este ajuste no repositório. Obrigado!

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.

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, 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.

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.

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.

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?