EMBarbosa

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN . Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Olá. Parece que ficou faltando um retorno melhor aqui. O código atual já atende a versão S1.0 e talvez até a versão S-1.1... e permite o preenchimento de várias remunerações, usando o remunPerApur. Já os campos mencionados (tpInsc, nrInsc, codLotacao e qtdDiasAv), de acordo com o manual precisam ser preenchidos. Veja abaixo: O seu código não, contempla essa funcionalidade. Ele repetiria o várias tpInsc dentro de um mesmo ideEstabLot. Caso esteja verficando outra documentação, por favor nos avise para que possamos verificar melhor. Bom trabalho por aí.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. As alterações já foram para o SVN. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. As alterações já foram para o SVN. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Se é usando a Lib, pode ser esse forum mesmo. Se você não está conseguindo obter esse protocolo e dados de confirmação na hora do envio, então me parece que realmente não é possível no caso do eSocial. Veja essa informação que está nas perguntas frequentes do e-Social (link logo abaixo: Fonte: Perguntas Frequentes

Em primeira análise, parece que é o contrário... No NCM seguinte : 01061200;Baleias, golfinhos e botos (mamíferos da ordem Cetacea); peixes-boi (manatins) e dugongos (mamíferos da ordem Sirenia); otárias e focas, leões-marinhos e morsas (mamíferos da subordem Pinnipedia);01/04/2022;31/12/9999;Res Camex;000272;2021 Tem ponto e vírgulas na descrição e isso está confundindo o Excel... o jeito seria usar um escape nessas descrições... https://stackoverflow.com/a/8501818/460775 Edit: o @EliasCesar já percebeu isso também.

Mude o nível de log para paranóico (4) e tente novamente por favor. Anexe o log gerado.

Por favor, anexe o log da Lib, para que possamos avaliar a situação.

Pela sua imagem não dá pra ver. Verifique se a aba Webservice das configurações está configurada com a UF do Emitente corretamente. Depois veja se as configurações foram salvas (botão "Salvar Configurações"). Daí, analise o conteúdo do arquivo que você está passando para a lib: "D:\Savio\Demos\C#\NFe\Demo\ACBrLib.NFe.Demo\bin\Debug\Arqs_NFe\saida_55.xml". Veja se ele realmente é um xml de NFe/NFC-e válido ou se está faltando alguma informação como a UF do Emitente.

Seu log está muito estranho. Só tem a finalização da Lib. Qual modelo da Lib você está utilizando? ST ou MT (MultiThread)?

Olá, pra gente poder ajudar melhor, precisamos saber exatamente qual o ambiente em nuvem que está utilizando. É qual versão do Windows? é 32 ou 64 bits? Sua aplicação é 32 ou 64? Está rodando sua aplicação por IIS? As fontes truetype padrões (Arial, Times, etc...) estão instaladas?

I/O 32 significa que o arquivo está em uso/aberto por outro processo/rotina. No caso, pode até não ser um arquivo, mas talvez a porta do pinpad. Você precisa verificar, talvez debugando a aplicação.

Pra poder identificar o problema, precisamos saber pelo menos qual é a última revisão que funciona e não uma revisão antiga que funciona... 2 anos podem ter milhares de revisões... Mas você conseguiu identificar o que é enviado a impressora de diferente nas duas revisões? Se você conseguir, isso pode ajudar... Infelizmente não tenho uma impressora dessas e não posso testar... Siga por favor o que o BigWings mencionou acima até encontrar a última revisão que funciona: Assim você vai estar ajudando a equipe a encontrar o problema.

A questão é que se você descobrir a versão que funciona, fica mais fácil de analisar as alterações e quando o problema surgiu. Daí talvez seja possível entender como corrigir. Isso claro, se é que existe mesmo um problema.

Olá pessoal A SEF de Santa Catarina (SC) publicou um novo Ato DIAT (55/2022) que estabelece o leiaute do Bloco X conforme os requisitos LVIII e LIX que entra em vigor imediatamente. Além de definir o leiaute, esse Ato também desobriga o PAF-ECF de ter uma função que após cada Redução Z informe ao contribuinte usuário a existência de transmissões pendentes. Vamos analisar o material para avaliar se haverá impactos nos nossos componentes relacionados ao Bloco X. Fonte: Ato DIAT (55/2022) Anexo do ato com o leiaute: https://legislacao.sef.sc.gov.br/html/atos_diat/2022/AtoDiat_22_055_Anexo_Unico.pdf

Claro! @MessiasNatal13 Já adicionei no nosso Backlog. TK-3080.

Podemos fazer isso aos poucos a medida que vamos recebendo contribuições... muito obrigado pela sugestão.

Moderação: Movido para fora do Boteco

Olá. Creio que sim. Mas, já houveram várias modificações nessa parte do código... Por exemplo as relacionadas nesse tópico abaixo Se ainda estiverem com problemas, por favor, queiram detalhar o problema para que possamos analisar melhor. Desculpe a demora no retorno. Mas eu não entendi bem a modificação já que os dois "IF" são excludentes, um para pegar a versão 2.5 e o outro pra pegar justamente as versões simplificado S1 e posteriores...

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 26739. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Explicação... The IDE forces all unit filenames to lower case. Even renaming the files to the casing that we want, which matches the casing in code, eventually the IDE will put it back to lower case. the reason why the IDE does this: on case sensitive filesystems (e.g. Linux), it also checks for the file in all lowercase. Keeping files lowercase saves a lot of headaches if the code is ever used on Linux. (otherwise the case in the USES clause must match exactly) Mas pra nós isso não é sempre um problema. Afinal fica muito difícil pra nós lermos os nomes dos arquivos se estiverem tudo em letras minúsculas. A solução: A configuração que muda esse comportamento está em: Tools->Options->Environment->Naming Ou Ferramentas -> Opções -> Ambiente -> Nomeação Fonte: https://forum.lazarus.freepascal.org/index.php?topic=34514.0

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum.

Isso não parece ser um problema de escala. Quando a escala está incorreta, todo o DANFe fica estranho, não apenas alguns campos. Não sei se observou, mas o mesmo problema está acontecendo na imagem Tela1.png... O que mais uma vez indica que não é um problema de escala. Tudo indica que o problema é alteração local dos arquivos fontes do Fortes ou dos relatórios padrões do ACBr, como o @Daniel Simoes indicou acima.

No caso, a pergunta mais importante é: Por que vocês estão alterando essa propriedade? Essa é uma propriedade antiga que influencia na formatação do XML gerado em memória pelo componente. Atualmente acho que ela não tem muita serventia exceto testes. Como você mesmo disse, ele fez a contribuição do código e nós aprovamos pois faz sentido. Se quiser fazer a contribuição para isso ser incluído nos outros eventos, ficaremos gratos.