edu

Boa tarde, Verifiquei que houve um refactoring no código fonte do ACBr, e isso começou a ocasionar um problema ao ler o xml dos CT-e OS. A leitura ocorria, porém os dados da tag InfCTeNorm não estavam sendo lidos. Olhando o código vi que houve uma separação na leitura das tags em função do modelo do documento. Porém a função Ler_CTeOs não estava carregando as tags InfCTeNorm e InfCTeComp, que também existem nesse modelo de documento. Fiz um ajuste no código fonte para corrigir: pcteCTeR.pas

Apenas um feedback, já concluí a homologação junto a Skytef usando essa alteração e deu certo.

Sim, quando o usuário clicar num botão que você definir com a função para voltar no seu sistema, ele envia esse texto *VOLTAR* na resposta, o que por sua vez aciona variável voltar, exatamente igual ocorre quando usa a opção -2 no ItemSelecionado do evento QuandoPerguntarMenu. Fiz assim para evitar a criação de um novo parâmetro, o que envolveria alterar também a unit da PayGo (que não sei se suporta isso) e também obrigaria quem já homologou a alterar o sistema. Usei a palavra dessa forma para evitar o risco de acabar usando uma resposta válida para alguma situação. Caso ache interessante fazer isso de outra forma tudo bem. Pelo que percebi na homologação o SiTef permite voltar praticamente em todos os campos que testei, exceto claro na primeira interação. A sequência 6 da homologação é justamente para testar se o sistema está aceitando isso. Usei o "if not voltar then" porque o texto *VOLTAR* não é uma resposta que o sistema vai passar para a SiTef, pelo que entendi "RespCliSiTef.GravaInformacao(TipoCampo, Resposta);" faz a gravação do valor recebido em Resposta como um retorno ao comando.

Olá, Estou fazendo a homologação com a Skytef usando ACBrTEFApi e tudo tem corrido bem, porém há um pequeno ajuste necessário no componente para atender a sequência 6 da homologação: Cheguei a tentar contato com a Skytef para confirmar essa informação, e tive esse retorno: Na prática, o evento QuandoPerguntarCampo precisa permitir que eu envie uma instrução para voltar, assim como ocorre no evento QuandoPerguntarMenu. Assim eu posso criar um inputbox com os botões OK | VOLTAR | CANCELAR para tratar essa situação. Para permitir isso fiz um ajuste na rotina ContinuarRequisicaoSiTef. Nos comandos 30, 31, 34, 35 e 41 incluí um tratamento para que ao receber o valor "*VOLTAR*" o componente use a mesma variável Voltar que já está usando no comando 21: Segue o arquivo alterado em anexo para avaliação. ACBrTEFAPICliSiTef.pas

Boa tarde Italo, Alguns minutos atrás tive o problema e achei este post agora. Fiz o teste com sua correção mas o problema persistiu, porque ele ocorre quando emiDocAnt está sem itens. Fiz um ajuste, segue arquivo anexo. ACBrCTeDACTeRLRetrato.pas

OK, tudo certo.

Olá, Antes de mais nada, vi que esse é um assunto um pouco batido aqui no fórum e que já existem aqui vários tópicos, mas todos todos encontram-se sem resposta há algum tempo e acabaram sem solução, por isso optei por criar este. Um de meus clientes, que está no regime do simples, mencionou a necessidade de emitir CF-e com as CST 04 e 08 para o PIS e COFINS, pois do contrário ele sofreria bitributação. Seu contador alegou o mesmo, e disse inclusive que havia feito contato com o Sefaz/SP sobre isso. Como creio já ser de conhecimento de todos, devido a forma como o manual disponibilizado pelo Sefaz/SP está redigido geralmente usa-se a CST 49 para o PIS e COFINS na emissão de CF-e SAT quando a empresa é do regime do simples. Mas devido a insistência do cliente fiz contato com o Sefaz/SP e recebi o seguinte retorno: "No caso do PIS/Pasep e da Cofins, os valores registrados no CF-e-SAT devem ser escriturados conforme orientações da Receita Federal do Brasil, órgão responsável por estes tributos." Após algumas pesquisas, localizei este link no site da Receita Federal com perguntas a respostas sobre EFD contribuições: Perguntas e Respostas EFD Contribuições.pdf Na página 42, a questão 95 fala justamente sobre qual CST pode ser usada por PJ optante pelo simples. Embora fale sobre NF-e, creio ser perfeitamente aplicável a NFC-e e ao SAT CF-e também. E esta questão coloca que empresas optantes pelo simples podem usar as CST 49, 02, 03, 04 e 08 para PIS e COFINS (obviamente, depende do caso). Após algumas pesquisas verifiquei que a CST 49 pode ser usada por empresas do regime normal também, mas em algumas situações onde não há valor, como transferência de estoque. Se apenas empresas optantes pelo simples podem usar esta CST em vendas faz sentido o manual de especificações do SAT indicar esta CST como sendo para empresas optantes pelo simples. Mas ao mesmo tempo, isso não limita estas empresas a usarem apenas esta CST. Analisando o código do do ACBR vi que a unit "pcnCFeW.pas" estava limitando a CST a opção 49 quando a empresa era simples, gerando com uma tag errada caso usasse outra, o que ocasionava uma rejeição no SAT: "código de situação tributária do PIS inválido (diferente de 49)". Como já apareceram aqui no fórum vários casos além do meu, o Sefaz/SP indica que deve seguir as normas da Receita Federal, e a Receita Federal abre a possibilidade para uso e outras CST para PIS e COFINS além da 49, creio que isso é suficiente para um ajuste no componente para permitir estas CST. Fiz este ajuste comentando as linhas 409 a 414 e 507 a 512 da unit, segue o arquivo com os ajustes. Com este ajuste as tags geradas se basearão apenas na CST selecionada, sem considerar o regime. Meu cliente já está emitindo cupons com as CST 04 e 08, que já foram transmitidos e aceitos pelo Sefaz, sem nenhuma rejeição nem no SAT nem no site retaguarda do SAT. pcnCFeW.pas

Não sei se isso o ajudará porque quase não uso WebBrowser e meu Delphi é 2009, mas algum tempo atrás tive problemas de compatibilidade. Meu programa rodava bem no Windows 7 mas quando migrei para o 10 os sites ficavam desfigurados. Após pesquisar descobri que o problema estava relacionado a emulação do Internet Explorer, o WebBrowser do meu programa trabalha de forma a emular o Internet Explorer 7. Para resolver é preciso fazer um ajuste no registro do Windows, com base nas informações do site da Microsoft criei uma função para automatizar isso: https://msdn.microsoft.com/en-us/library/ee330730(v=vs.85).aspx: // versões IE: 7, 8, 9 10 e 11 Procedure SetIEEmulation(VersaoIE : Integer); Var R : TRegistry; V : Integer; Begin V := 11001; Case VersaoIE Of 7 : V := 7000; 8 : V := 8888; 9 : V := 9999; 10 : V := 10001; 11 : V := 11001; End; // internet explorer 11 = 11000 ou 11001 // internet explorer 10 = 10000 ou 10001 // internet explorer 9 = 9000 ou 9999 // internet explorer 8 = 8000 ou 8888 // internet explorer 7 = 7000 // https://msdn.microsoft.com/en-us/library/ee330730%28v=vs.85%29.aspx // resumidamente, esta função grava um valor no registro que força a emulação da versão do Internet Explorer para o programa indicado // só é preciso o nome do programa, não é necessário o path completo R := TRegistry.Create; Try R.RootKey := HKEY_CURRENT_USER; R.OpenKey('SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION\',False); // código para emular o internet explorer 11 R.WriteInteger(ExtractFileName(ParamStr(0)),V); Finally R.CloseKey; R.Free; End; End; Para emular o Internet Explorer 11 chame a função do seu programa apenas uma vez, desta forma: SetIEEmulation(11); Não testei se isso funcionará no seu caso (também não tenho o XE7), mas talvez ajude.

O erro que verifiquei ocorre nos campos posteriores a posição 37 devido ao incremento de um caractere, o seu parece não ter relação com isso.

Olá, Fiz uma correção no arquivo de remessa do banco Sicredi, formato cnab 240: na linha 1566, função GerarRegistroTransacao240, estava assim: Space(2) + // 037 a 037 - Dígito verificador da coop/ag/conta Alterei para Space(1) + // 037 a 037 - Dígito verificador da coop/ag/conta O arquivo não passava na homologação devido ao deslocamento dos campos seguintes gerado pelo caractere extra. Como é possível ver no manual e no próprio comentário na linha, é esperado apenas um espaço nesta posição. ACBrBancoSicredi.pas