José M. S. Junior

Bom dia A recomendação é que realize os testes e homologação com o demo SATTest, conforme exemplificado neste tópico: A integração de pagamento é realizada diretamente com o Integrador, por isso não foi disponibilizado no ACBrMonitor, note que precisa gerar um XML simples com os dados do pagamento e vai obter a Retorno no diretório do Integrador. Para pagamento POS veja no tópico que é necessário utilizar o simulador POS do Ceará para homologar, isso não é funcional em Produção no CE.

Sim, precisa realizar o tratamento na geração da remessa e retorno nos pontos onde há divergências entre um layout e outro. Basta realizar a alteração conforme mencionou acima... Mas note que no seu layout tem uma posição a menos no final do arquivo, justamente para não ultrapassar o limite do arquivo. No Caso precisa tratar isso também baseado no Layout que estiver utilizando. Se desejar implementar, pode postar aqui, que realizamos a validação e atualizamos no SVN...

Quanto a alterar o valor destas propriedades teria que fazer isso após a criação da classe. Mas o número do Banco realmente não vai conseguir, é definido quando seleciona o tipo de Cobrança... Creio que por se tratar do Banco 136 esse layout deva ser implementado na Classe UnicredES que é 136. Não sei se a nomenclatura dessas classes corresponde apenas ao layout dessas UFs, mas o que vai importar de fato é o layout, ou seja o número do Banco... Aparentemente o Unicred tem um Layout padrão que está especificado como "Unidade Porto Alegre" e os demais utilizam uma estrutura muito parecida apenas alterando alguns campos e o código do Banco. Note que a reestruturação realizada nestas classes, permite implementar na classe principal "UnicredRS" e utilizá-las nas classes filhas, simplesmente alterando os campos no momento de criar a Classe filha. Isso é feito na classe UnicredES, Instancia com o código 136 e utiliza o mesmo HEADER da classe pai, apenas alterando algumas propriedades pré-definidas.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Mas o layout 240 é deste Banco mesmo? Pois esta cooperativa tem diversos layouts, se precisar alterar o número do Banco creio que será necessário utilizar outra classe, note que já existe UnicredES e UnicredSC.

Bom dia @DATAC, atualize o ACBrMonitor para última versão. Mas o problema parece ser falha na conexão mesmo. Já aumentou o timeout de conexão?

Bom dia A versão que está implementada no componente é outra, versão Layout do Arquivo: 040 esse manual em anexo é a versão 030. São pequenos detalhes que mudam, mas precisa controlar isso pela versão, note que tem os campos: LayoutVersaoArquivo, LayoutVersaoLote na classe ACBrBoleto para tratar essas situações, precisa implementar essa alteração baseado na versão que estiver passando. Pode ver um exemplo na classe do Banco Sicred, o mesmo trabalha com versões diferentes de layout.

Para atualizar o XML com o protocolo precisa passar o path completo do XML como parâmetro na Consulta.

Bom dia Para consultar Cadastro de outra UF, precisa configurar a lib com a mesma, se refere ao campo UF do arquivo ACBrLib.ini. Vale lembrar que não são todas as SEFAZ que disponibilizam WebService de Consulta Cadastro.

Bom dia O manual atualizado está disponível on-line, nele você encontra um passo a passo de como integrar o componente NFe, assim como o modelo completo de um arquivo .ini https://acbr.sourceforge.io/ACBrMonitor/PassoaPassoNFeNFCe.html Existe também vídeos explicativos com os Primeiros Passo e integrando um NFe com o modelo do .INI em anexe, além do Curso Completo do ACBrMonitor que está sendo disponibilizado as aulas: https://www.projetoacbr.com.br/forum/video/browse/13-curso-dominando-o-acbrmonitor/

Boa tarde Com o próprio ACBrMonitor é possível realizar testes, passando os comandos na pasta Monitorada pelo ACBrMonitor: https://acbr.sourceforge.io/ACBrMonitor/SATImprimirExtratoVenda.html Mas quanto a integração com a aplicação é necessário entrar com o suporte técnico do Software...

Note que são dois métodos acessíveis de locais diferentes... ACBrBoleto1.GerarPDF; ou ACBrBoleto1.ListadeBoletos[0].GerarPDF(); O primeiro acessando direto pelo componente ACBrBoleto vai gerar todos os títulos em um único arquivo, o segundo vai gerar apenas o título do index da lista. obs: Está disponível apenas para Fortes Report até o momento.

Boa tarde Não precisa atribuir nenhuma propriedade para isso, basta chamar os novos métodos a partir do Titulo que deseja gerar ou enviar e-mail. ex: for i:= 0 to ACBrBoleto1.ListadeBoletos.Count -1 do begin ACBrBoleto1.ListadeBoletos[i].GerarPDF(); end;

Bom dia Diogo, Note que foi realizado um refactory recente nas classes desse Banco, inclusive já adicionado o layout UnicredSC. Estamos utilizando a classe ACBrUnicredRS como classe base para os demais layout desse banco, apenas mantivemos a nomenclatura da classe para não ter problemas para quem já utiliza. Está bem parecido com o que voce implementou. Se possível, verifique se é possível adptar seguindo o padrão das classes que já estão implementadas (ACBrBancoUnicredES e ACBrBancoUnicredSC). Ou realizar os ajustes Na classe ACBrBancoUnicredRS, aparentemente o layout que utilizou é o mesmo utilizado nesta classe.

Boa tarde @Igor Assis Creio que não entendeu a funcionalidade da lib. A informação para geração dos Boletos sempre precisará estar na sua base de dados, a lib vai fica na aplicação local em cada estação onde for necessário gerar Boletos, baseados nas informações que alimentar a lib é que vai gerar o Boleto, podendo ser um por vez, simplesmente limpando a lista e gerando o próximo , ou todos os boletos do mesmo cedente no caso de Geração de Remessa. Estando com as rotinas implementadas na sua aplicação poerá simplesmente chama-las passando as dados. Os dados do cedente podem ficar gravados no arquivo .ini com as configurações da lib, mas também pode passar os dados do cedente e banco via método utilizando o Boleto_ConfigurarDados ou mesmo junto com os dados do titulo em Boleto_IncluirTitulos.

Bom dia Fábio, o código de baixa e devolução que está utilizando para as Instruções não está de acordo com o Manual do Santander, veja no Manual quais códigos deve utilizar:

Atualizado no SVN.

O componente ACBrNFe não tem uma função para esse fim... Creio que foi implementado apenas para o MFe pois foi a exigência para homologação no CE. Mas acho que para esse fim poderá utilizar a impressão da NFCe em ESCPOS modelo: "ppTexto", porta: "c:\temp\nfce.txt' . Vai gravar o cupom em modo Texto, assim como ocorre no método do MFe.

Boa tarde Sim, vamos adicionar essa propriedade nas configurações da lib.

No ACBrMonitor não utilizamos a geração de Pagamentos para o Integrador Fiscal, quando se utiliza o Integrador Fiscal, ele é o responsável por realizar toda a comunicação com a SEFAZ o ACBr apenas gera o XML assinado no diretório do Integrador Fiscal e aguarda a resposta do mesmo. No caso do pagamento deve ser passado para o Integrador, um XML comum, apenas com dados de pagamento.

Favor atualizar os fontes... Foi implementado esta classe baseado no refactory realizado na classe ACBrBoletoUnicredRS, favor realizar os testes.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Quais as configurações SSL que está utilizando? É possível simular esse erro com o Demo ACBreSocial?

Os diretórios para gravação de arquivos estão todos configurados na biblioteca ACBrLib.ini ? Verifique os campos: PathSalvar= PathSchemas= PathNFe= PathInu= PathEvento= Não deixe esses campos em branco, senão vai tentar gravar no diretório do NetBeans e pode não ter permissão.

Boa tarde Realmente essa funcionalidade de retornar o Extrato em ESCPOS existe apenas para o CFe com MFe. Se notar, a função GerarImpressaoFiscalMFe apenas chama os métodos de geração do Extrato EscPos normal e apenas obtem o buffer do componente POSPrinter no final. Creio que poderia ser feito da mesma forma utilizando o Extrato EscPos da NFCe.