gostartlab

Fechando o tópico, pq encontrei um outro que me respondeu... É necessário também preencher o valor da redução para o município, mesmo quando vIBSMun e pIBSMun não tem valores/zerados

Boa tarde pessoal, tudo bem ? Estamos com a rejeição "Não informado o grupo de redução de alíquota Municipal" quando estamos fazendo a emissão de um produto que tem redução Estadual. Anexei um print do código em execução, no caso não estamos preenchendo os valores em relação as alíquotas municipais. Também o arquivo .ini que foi utilizado para emissão. acbrNFe.ini

Legal pessoal, isso mesmo @danieloliveira-mm, exatamente assim que penso também, com a interface IACBrNFe, assim a implementação concreta fica a cargo de cada projeto separadamente e entendo ser uma alteração simples para quem já utiliza as libs

Olá pessoal, tudo bem. Estou abrindo este tópico como sugestão para melhorias nas classes de alto nível para C#, visto que estão trabalhando na refatoração delas com esta notícia Refatoração das Classes de Alto nível C#. Estou pegando como exemplo a lib NFe, mas entendo que o mesmo se aplica para as demais. Hoje são gerados 2 pacotes Nuget (ACBrLib.NFeMT e ACBrLib.NFe), que entendo ser estes: - https://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/C%23/NFe/Imports/Dinamico/ A ideia seria ter 3 projetos, 1 Core/Shared e outros 2 para MT e ST, onde abre a possibilidade para referenciar o Core somente onde existe a implementação de lógica e o ST/MT ser referenciado nos projetos que farão a referência com a DLL propriamente dito.... Por exemplo eu posso ter 1 projeto que faz toda a parte fiscal, incluindo a emissão, porém posso referenciar ele em uma API (usando o MT para instanciar a implementação correta da DLL) e um outro projeto no PDV rodando localmente (usando o ST). Dando um exemplo real nosso, é que fazemos emissões fiscais tanto via API quanto em uma aplicação que roda no cliente para suporte offline, ambas compartilhando a mesma lógica (outro projeto que referencia o ACBr), porém a implementação da impressão do DANFE Resumido recebemos uma resposta que somente funcionaria com a versão ST, neste caso somente conseguiríamos fazer duplicando código. Valeu galera !

Com a versão 1.2.2 deu certo. Muito obrigado pessoal. Só tenho mais 2 pontos que sentimos falta aqui nos pacote do Nuget, se devo abrir um novo tópico aqui no fórum sobre, por favor me avise que abro. Na ACBrLib.Core.Config.PosPrinterConfig não tem a sessão Principal, é onde estamos configurando os logs. E na ACBrLib.Sat.CodigoMP, não tem os pagamentos mpBoletoBancario, mpDepositoBancario, mpPagamentoInstantaneo e mpSemPagamento (https://portal.fazenda.sp.gov.br/_layouts/download.aspx?SourceUrl=/servicos/sat/Downloads/Especificacao_SAT_v_ER_2_30_03.pdf) Mais uma vez obrigado.

Boa noite, concordo com a sua solução também. Como eu fiz um ajuste somente para minha aplicação funcionar não preciso me preocupar com compatibilidade de versões anteriores. Sabem quando teremos essa solução dos fontes distribuidos no Nuget ? Obrigado

Olá, estou iniciando com a utilização dos pacotes C# via Nuget e me deparei com o seguinte problema: Minha applicação é distribuída para Linux e Windows via pacote self-contained (1 único binário), assim não temos dependências do dotnet runtime na máquina que executaremos a aplicação. Porém na classe ACBrLibHandle.cs tem um código que não é compatível com a aplicações self-contained. Em modo de debug (localhost) funciona normalmente, porém quando vamos executar a aplicação compilada, recebo o seguinte erro: Unhandled exception. System.TypeInitializationException: The type initializer for 'ACBrLib.Core.ACBrLibHandle' threw an exception. ---> System.NotSupportedException: CodeBase is not supported on assemblies loaded from a single-file bundle. at System.Reflection.RuntimeAssembly.get_CodeBase() at ACBrLib.Core.ACBrLibHandle..cctor() in /builds/app-back/src/ACBrLib.Core/ACBrLibHandle.cs:line 29 --- End of inner exception stack trace --- at ACBrLib.Core.ACBrLibHandle.get_IsWindows() in /builds/app-back/src/ACBrLib.Core/ACBrLibHandle.cs:line 96 at Application.Agent.WorkerService.AgentWorkerServiceStartup.CreatePlataformHostBuilder(String[] args) in /builds/app-back/src/Application.Agent.WorkerService/Program.cs:line 32 at Application.Agent.WorkerService.AgentWorkerServiceStartup.Main(String[] args) in /builds/app-back/src/Application.Agent.WorkerService/Program.cs:line 22 Na ACBrLibHandle.cs hoje tem o seguinte código para definir o path padrão de carregamento das bibliotecas: static ACBrLibHandle() { MinusOne = new IntPtr(-1); var uri = new Uri(Assembly.GetEntryAssembly().CodeBase); // CodeBase não é suportado em self-contained var path = Path.GetDirectoryName(!uri.IsFile ? uri.ToString() : uri.LocalPath + Uri.UnescapeDataString(uri.Fragment)); LibraryPath = Path.Combine(path, "ACBrLib", Environment.Is64BitProcess ? "x64" : "x86"); } Acredito que algo assim resolveria o problema (estou utilizando esta versão hoje no meu fonte, porém não utilizo o path padrão das libs e sim seto o meu em tempo de execução via ACBrLibHandle.LibraryPath static ACBrLibHandle() { MinusOne = new IntPtr(-1); var baseDir = AppContext.BaseDirectory; if (!string.IsNullOrEmpty(baseDir)) { var uri = new Uri(AppContext.BaseDirectory); var path = Path.GetDirectoryName(!uri.IsFile ? uri.ToString() : uri.LocalPath + Uri.UnescapeDataString(uri.Fragment)); LibraryPath = Path.Combine(path, "ACBrLib", Environment.Is64BitProcess ? "x64" : "x86"); } } Obrigado