Marcio Rossato

Alguém sabe uma forma definitiva de evitar o problema de duplicidade? Nunca ouvi falar deste problema ocorrer no emissor gratuito.

Boa tarde, acabei de atualizar os fontes, problema corrigido sim. Além disto vi que houve mais melhorias neste fonte do Santander. Obrigado pela atenção @DJSystem

Após atualizar os fontes, gerou tudo ok novamente. obrigado.

Mesmo problema aqui, layout incorreto falta digito nestas duas posições

Bom dia, alguém poderia me indicar onde estão estas funções? obrigado

Boa noite, ainda não foi atualizado, sempre que baixo os fontes preciso corrigir manualmente. se você não quiser mexer no código fonte sugiro que não use o campo nosso número, use o campo seunumero pois ele parece estar correto.

João Ricardo, já revirei o site da sefaz procurando XML de NFCe (SP), mas não achei. Se vc encontrar posta aqui por favor. vlw.

vlw, obrigado.

Olá Daniel, no meu caso, todos clientes usam SAT, só que os SATs vivem dando defeito, eu mando pra garantia está demorando pra retornar. Já tive SAT da elgin que demorou 60 dias pra retornar. Neste caso eu ativo o NFC para os clientes não deixarem de emitir cupom até retornar o SAT da garantia. Agora tenho 2 clientes sem SAT (na garantia) e NFC não funcionando.

Acabei de testar novamente: Erro Interno: 0 Erro HTTP: 6 Forbidden (403) - 'https://homologacao.nfce.fazenda.sp.gov.br/ws/nfeautorizacao.asmx' o retorno é este. meus clientes não trabalham domingo, se não normalizar, amanhã vai ser tenso !

Atualizei os fontes do ACBR, mas não consegui virar o layout. pediu tag nova, com campo novo. vou ter que estudar isso com calma. Mandei email novamente, não veio a resposta automática mais.

estou testando aqui ambiente de homologação também está com problemas. vou tentar usar o layout 4.00 pra ver se o problema é este. pq ainda estava com 3.10. Ja enviei email para a sefaz, e retornam que os servidores deles estão ok.

Boa tarde, estou desde ontem com problemas no NFC SP Erro 403 - Forbidden em 2 clientes com windows 10

Bom dia leonardobeluzi, vc teve algum progresso?

Funcionou pra mim também, vlw !

Avecchi, boa noite, vc teve algum sucesso com isso ?

Boa noite o manual é antigo, de 2009. Porém é o manual que me foi enviado pela atendente do Santander, portanto é o mais atual que eles fornecem. Independente da versão do manual, outra questão que evidencia a necessidade da correção é que no arquivo remessa envia-se 7 dígitos e no retorno lê-se 8 dígitos, cedo ou tarde este dígito a mais iria gerar problemas. Segue Manuais, arquivo remessa e retorno. Codigo de barras - 012015.pdf Layout Cobrança 240 - 092009.pdf Layout Cobrança 400 - 102009.pdf Nosso Numero Santander.xls CB151213.REM COBST_QQKS_02_161216P_MOV.TXT

Boa noite o manual é antigo, de 2009. Porém é o manual que me foi enviado pela atendente do Santander, portanto é o mais atual que eles fornecem. Independente da versão do manual, outra questão que evidencia a necessidade da correção é que no arquivo remessa envia-se 7 dígitos e no retorno lê-se 8 dígitos, cedo ou tarde este dígito a mais iria gerar problemas. No meu caso, enviei na remessa nosso numero 26, o componente calculou corretamente o dígito 4 (Salvei o PDF ). Após importar o retorno o nosso número passou a ser 264-0. O 4 quer era dígito passou a incorporar a última dezena do nosso número .

Realmente o problema continua, segue tópico onde sugeri uma correção, paliativamente você também pode tentar fazer esta correção até que o pessoal do ACBr analise minha sugestão e talvez publique.

Bom dia Estou homologando o boleto junto ao Santander. E percebi que após importar o arquivo retorno a linha digitável ficou diferente do esperado na remessa. Ao analisa o fonte ACBrBancoSantander.pas verifiquei que a divergência está no nosso número conforme detalhes: A Remessa: LInha 700: PadLeft(RightStr(NossoNumero,7),7,'0') + DigitoNossoNumero + // 63 a 70 O Retorno : Linha 1034: NossoNumero := Copy(Linha,63,08); Note a diferença, na remessa o nosso número tinha 8 dígitos sendo que os 7 primeiros é o nosso número e o 8º dígito é o Digito Verificador (que foi calculado anteriormente). No Retorno o fonte simplesmente lê os 8 dígitos como sendo o nosso número incorporando o dígito verificador. Sugiro a seguinte correção no retorno: Arquivo Fontes\Boleto\ACBrBancoSantander.pas Linha 1034: NossoNumero := Copy(Linha,63,07); //DigitoNossoNumero := Copy(Linha,70,01); //por hora comentando pois o digito é calculado sempre que necessário No meu caso após esta mudança a linha digitável ficou OK PS: Fonte trunk2 atualizado neste exato momento. Obrigado Márcio ACBrBancoSantander.pas

Bom dia, também tive este erro durante a homologação, falou definir a carteira = 101

Bom dia estou problemas também, o numero do documento está correto, o problema é no nosso número, que causa erro na linha digitável. Estou atualizando o fonte agora para verificar se o erro ainda ocorre. Se caso ocorrer irei sugerir uma correção.

Dei uma lida na integra a decisão do ministro, no final o mesmo decide: Pelo exposto, concedo a medida cautelar pleiteada, ad referendum do Plenário, para suspender a eficácia da cláusula nona do Convênio ICMS nº 93/2015 editado pelo CONFAZ, até o julgamento final da ação. e a Cláusuloa nona é: Cláusula nona Aplicam-se as disposições deste convênio aos contribuintes optantes pelo Regime Especial Unificado de Arrecadação de Tributos e Contribuições devidos pelas Microempresas e Empresas de Pequeno Porte - Simples Nacional, instituído pela Lei Complementar nº 123, de 14 de dezembro de 2006, em relação ao imposto devido à unidade federada de destino. Portanto me parece que a decisão suspende todo o efeito do convênio, inclusive o fundo de combate a pobreza.

Bom dia, alguém sabe se a decisão afeta também o Fundo de Combate a Pobreza ? Todos sites que tenho lido fala do DIFAL apenas

Pessoal boa tarde, conseguimos aqui replicar o problema em ambiente de teste com o emulador da receita. Ocorre que o SAT(emulador) para de responder, o sistema fica travado e o usuário finaliza o sistema. Quando o SAT(emulador) volta a funcionar o cupom é emitido. Parece que ele fica em alguma fila e processa mesmo com o sistema já fechado. A solução que encontrei aqui foi simples, antes de enviar o cupom para o SAT, realizar uma consulta do status operacional. // VERIFICAR SE O SAT ESTÁ OPERACIONAL 1, CÓPIA ABAIXO statusSAT := ACBrSAT1.ConsultarSAT ; if ACBrSAT1.Resposta.codigoDeRetorno <> 8000 then begin ShowMessage('SAT não está operacional: ' + statusSAT ); result := false; exit; end; Vejam o print do emulador, todos os comandos de consulta do status operacional, que não foram executados antes, são executado de uma vez, com intervalo de milésimos de segundos quando o emulador e reiniciado: [2016-07-27 18:03:02.731]:Numero de Serie: 123456789 [2016-07-27 18:03:02.743]:EMULADOR DO SAT OFF LINE [2016-07-27 18:03:02.783]:Debug ativado [2016-07-27 18:03:02.790]:Carregando parametrizacoes. [2016-07-27 18:03:02.953]:Sincronizando Relogio NTP. [2016-07-27 18:03:02.955]:Aguardando Comunicacao. [2016-07-27 18:03:02.958]:INICIO CONSULTA [2016-07-27 18:03:02.959]:FIM CONSULTA [2016-07-27 18:03:03.039]:INICIO CONSULTA [2016-07-27 18:03:03.040]:FIM CONSULTA [2016-07-27 18:03:03.174]:INICIO CONSULTA [2016-07-27 18:03:03.175]:FIM CONSULTA [2016-07-27 18:03:03.250]:INICIO CONSULTA [2016-07-27 18:03:03.251]:FIM CONSULTA [2016-07-27 18:03:03.341]:INICIO CONSULTA [2016-07-27 18:03:03.342]:FIM CONSULTA [2016-07-27 18:03:03.403]:INICIO CONSULTA [2016-07-27 18:03:03.405]:FIM CONSULTA Ainda não dá pra afirmar com certeza se isto irá resolver pois estou começando a colocar em produção hoje, porém tudo indica que fazendo esta consulta antes do envio, não deve ocorrer o problema mais. vlww