jovitomg

Texto do campo Discriminação dos Serviços da NFS-e está cortando conforme arquivo anexo. Utilizo a Lib com a integração c#. Inicialmente, foi sugerido alterar configurações de DPI do windows, mas mesmo alterando as configurações continuou erro. Em seguida tentamos usar os parâmetros AlterarEscalaPadrao e NovaEscala da seção [DANFSe]. Mudei AlterarEscalaPadrao para 1 e NovaEscala para 94(estava 96). O texto da Discriminação saiu completo mas ocorreram algumas distorções na Danfe conforme imagem "distorcao_apos_alterar_novaescala.png". Em seguida tentamos usar o parâmetro TamanhoFonte da seção [DANFSe], mas a alteração não teve efeito, cheguei a alterar para 1 e em nenhum ponto da Danfe teve efeito. Se for possível, uma sugestão seria criar um parâmetro exclusivo para o campo Discriminação dos Serviços, porque mesmo que façam a correção para o parâmetro TamanhoFonte funcionar, diminuiria o tamanho de todos campos(imagino) sendo que os demais campos estão ok. O único com chances de ficar grande seria o de Discriminação dos Serviços.

Boa noite Diego e Italo, Funcionou. Detalhe: na configuração iniServicos estava apenas o path, mudei para o caminho completo e funcionou. Obrigado a todos.

Foi criado o parâmetro NaoImprimirLocalPrestServ para ser configurado no ACBrNFSeXServicos.ini porém, baixei a última versão da Lib(1.0.0.50) e atualizei os fontes da integração com c# e ao realizar os testes o campo "Município de Prestação do Serviço" continuou sendo impresso na danfe.

Boa noite @Italo Giurizzato Junior, atualizei em um outro cliente e funcionou sim. No primeiro cliente deve está faltando algo, mas de todo modo está resolvido sim. Muito obrigado Resolvido @Diego Foliene. Muito obrigado.

Bom dia @Italo Giurizzato Junior, baixei a versão 1.0.0.40 e os fontes mas o Label "Município de Prestação do Serviço:" continuou aparecendo, vc chegou a fazer esta alteração? Obrigado

Acho sim Italo. Deus te ouça que BH e todos os outros municipios mudem para o Padrão Nacional. Gostaria de lhe pedir para ajustar apenas este ponto: 1. Em relação à alteração que vc fez, o município não foi impresso, o que resolve parcialmente. Gostaria de pedir que não imprimisse também o label do campo porque ficou com o label e conhecendo usuário, vai ter alguém que vai falar, "olha o campo Local de prestação dos serviços está vindo vazio". É possível?

"Eu fiz essa alteração para o provedor BHISS (versão 1.00 do layout da ABRASF), porque você é o primeiro a ter esse problema com um cliente: Tanto o componente antigo quanto ao novo ninguém reclamou da presença dessa informação, e olhe que o ACBr emite NFS-e desde 2011." R: Acredito que seja porque trabalhamos com emissão em massa, onde emitimos centenas de notas médicas por mês e cada médico presta serviço em um municipio diferente. Neste caso, o municipio de prestação do serviço varia bastante. Você tem alguma informação que a prefeitura vai mudar da versão 1 para 2.04? R: Não tenho, apenas citei a possibilidade por ser um caminho natural de atualizar pra versão mais recente. Como assim BH esta adotando o novo layout? R: Não tenho esta informação, apena citei a possibilidade.

Bom dia Italo, segue meu parecer: 1. Em relação à alteração que vc fez, o município não foi impresso, o que resolve parcialmente. Gostaria de pedir que não imprimisse também o label do campo porque ficou com o label e conhecendo usuário, vai ter alguém que vai falar, "olha o campo Local de prestação dos serviços está vindo vazio". 2. Considerando a solução adotada de comparar código do CodigoMunicipio com o CodigoMunicipio do Prestador, acho que resolve hoje, mas no futuro teremos um novo problema, quando realmente tiver que imprimir o Local de prestação dos serviços(mesmo sendo igual ao CodigoMunicipio do prestador), caso que vai ocorrer quando a prefeitura atualizar seu leiaute para a versão 2.04. Então a minha sugestão é: como você fez especificamente para bhiss, caso tenha a tag MunicipioIncidencia, significa que bh já está adotando o novo leiaute, logo a tag CodigoMunicipio é especificamente para o Local de Prestação dos serviços e portanto pode imprimi-lo na Danfe, caso não tenha MunicipioIncidencia, signicica que BH esta usando a tag CodigoMunicipio para informar o municipio de incidencia e portanto não imprime na Danfe o Local de prestação dos serviços..

Boa noite @Italo Giurizzato Junior. A solução foi suprimir o campo quando for versão de leiaute que não contempla as duas tags? Preciso fazer alguma configuração nova?

Boa tarde Pessoal. MultiThread, x86, cdecl

Gostaria novamente de falar sobre o campo "Município de Prestação do Serviço". Este campo no caso das emissões da prefeitura de BH está me trazendo um grande transtorno. Estou numa sinuca de bico pq se eu envio na tag CodigoMunicipio o município onde foi prestado o serviço, o webservice não deixa informar o a natureza de operação "Tributada no municipio". Se eu informa qualquer outro valor no campo Natureza de operação, fica errado, pq a tributação é no municipio. Isso pq ele trata este campo como se fosse o município de incidencia do issqn. Dito isso, gostaria de solicitar que fosse disponibilizado um parâmetro para configurar se deve ou não imprimir o campo "Município de Prestação do Serviço" na danfe. É possível ou teria uma solução pra resolver meu problema? Link do primeiro tópico que abri abordando este assunto: https://discord.com/channels/798697718800318484/800042186783588364/1143611377487974510

Boa tarde Italo, ja havia envido no e-mail, pode conferir se recebeu pfv?

Ao enviar uma nota para a prefeitura de Funilândia/MG, aparentemente o retorno da prefeitura vem corretamente, mas na lista de erros de retorno do ACBrLib vem o erro abaixo: [Erro1] Codigo=X999 Correcao= Descricao=Erro de Conexão: Invalid date ) Este mesmo erro também acontece quando consulta a nota.

Boa tarde Italo, Entendi seu ponto: No manual abrasf da versão 1.00, não tem na coluna descrição da tag "CodigoMunicipio" o texto "Código do município da prestação do serviço", mas me parece que foi apenas questão de "falha" mesmo. Como na versão 2.04 tem este texto no campo descrição da mesma tag, a princípio poderíamos inferir que se trata do "Código do município da prestação do serviço". Vamos fazer o seguinte: Respondendo suas perguntas: 1. Desfaz essa alteração, ou seja, continua como estava antes? Pra mim não faz diferença neste momento, mas me parece uma informação útil, fica a critério de vcs. 2. Muda o titulo do quadro "Local da Prestação de Serviço" para "Município de Incidência de ISSQN"? Não precisa mudar, porque vai afetar todos que utilizam. É mais fácil eu fazer uma alteração na minha aplicação pra gravar na tag CodigoMunicipio o código do município da prestação do serviço quando se tratar de BH que vai resolver. Muito obrigado pela antenção.

Bom dia Italo, Em relação a este tópico eu só abri porque entendo que está errado, não é por que o cliente pediu. O cliente apenas relatou o problema, mas se fosse algo para agradá-lo eu teria o bom senso de nem abrir o tópico, porque realmente não faz sentido alterar uma Lib compartilhada por causa de uma alteração específica pra um cliente. Não digo que a melhor solução é alterar o título "Município de Prestação de Serviço", aliás minha opinião é que não seria mesmo. Mas se não tenho a informação no xml, imprimir na Danfe "alguma coisa" estaria incorreto ao meu ver. Minha opinião é que, se não tem a informação, o melhor é não imprimir este campo. De todo modo, se não for possível, podemos encerrar o tópico e agradeço pelos retornos.

Nosso entendimento está igual em relação a Local de prestação do serviço e Local de incidência do ISSQN serem informações distintas. O ponto que estou colocando, usando o exemplo do xml que anexei neste chamado, informei no campo Local de incidência do ISSQN a cidade de Curvelo, veja o anexo tela_emissao_bh.png que o campo se refere ao Local de incidência do issqn. Veja também que no xml, este campo é gerado na tag CodigoMunicipio do grupo Servico. Pode-se concluir que para a prefeitura de BH, este campo é o município de incidência do issqn, mas não tem como concluir que é o município de prestação dos serviços.

Boa tarde Italo, baixei os fontes e atualizei a Lib para a 1.0.0.34, mas não saiu a impressão do município de incidência do issqn. Eu fiquei na dúvida sobre o ajuste que fez: Você alterou para sair o município de incidência no quadro outras informações, certo? Mas o problema do ticket é sair no campo Município de prestação dos serviços o município do prestador ou do orgão gerador, que não é necessariamente o município da prestação do serviço. A minha sugestão é que o município de prestação do serviço fosse impresso apenas quando tivesse esta informação no campo próprio do xml ou então mudar o nome do campo no pdf para município de incidência do issqn.

Boa tarde Italo, Eu gerei uma nota no ambiente de homologação, direto no site da prefeitura de BH. Veja que o campo "Cod/Município da incidência do ISSQN" que foi preenchido no site e que está impresso na danfe é Curvelo/MG. Propositalmente eu coloquei um município de incidência do issqn diferente do município do prestador e do tomador para ficar fácil identificar no xml. A minha sugestão é que se não tem campo de município de prestação do serviço, seria melhor não imprimir na danfe, porque imprimir o município de incidência do issqn neste campo do danfe acaba ficando uma informação incorreta Segue anexo o pdf e xml. pdf_nf.pdf xml_nf.xml

Boa tarde, Utilizo a LIb com integração c# e o cliente relatou o seguinte problema: O campo "Município de Prestação do Serviço" do PDF está exibindo incorretamente o município de incidência do ISSQN. O cliente alega que o município de incidência do ISSQN é Belo Horizonte, mas o local de prestação do serviço foi em outro município. xml_problema_municipio.xml

Boa tarde Pessoal. No .ini eu consegui configurar o parâmetro NomeLongoNFSe e deu certo para o que eu precisava. Seguem duas observações: 1. Na Lib, embora funcione carregando o parâmetro do .ini, não tem a propriedade para configurar via aplicação. Este ponto para meu caso não é um problema, mas estou relatando para caso vocês achem interessante, disponibilizar a propriedade para configuração também via Lib. 2. No meu caso fiz da seguinte maneira: gerei o arquivo na pasta padrão(propriedade PathPDF) e depois renomeei de acordo com o meu padrão. Obrigado

Mesmo erro: Então tem que entrar em contato com o pessoal do Quasar, certo?

Verifique se está sendo salva no seu arquivo ACBrLib.ini o caminho do IniServicos(você usou o ConfigGravarValor para definir ele?) eu defini direto no .ini IniServicos=C:\Projetos\Main\Release\ACBrLib\x64\ACBrNFSeXServicos.ini Alinhe a Producao na seção [IdentificacaoRPS] com o campo Ambiente e o campo Produção do INI de config. - Conferi todos, no arquivo xml de envio que anexei no post anterior gerou o Producao com 2 e abaixo os valores no .ini Ambiente=1 Producao=0 Veja também se está usando TLS1.2 no SSLType. SSLType=5

Sim, baixei o .ini do svn: [3130101] ; Atualizado em 12/07/2023 Nome=Igarape UF=MG Provedor=ISSDigital Versao=2.00 ProRecepcionar=https://igarape.quasar.srv.br/nfe/snissdigitalsvc HomRecepcionar=https://igarape.quasar.srv.br/nfe/snissdigitalsvc Estou anexando o xml e o log pra ver se conseguem me ajudar achar algo que ainda esteja faltando. 1434-env-lot-sinc.xml ACBrLibNFSe-20230713.log

Eu baixei a Lib 1.0.0.33 e atualizei os fontes dos projetos de integração c#. Eu refiz o teste com o .ini que passou e deu o mesmo erro. O teste que vc fez foi passando Producao = 2?

Eu fiz um teste, mas continua gerando o erro: <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.</faultstring> </soap:Fault> Eu entrei em contato com o pessoal do Quasar e eles me enviaram um link de integração diferente, vou anexar aqui o e-mail que me enviaram e um exemplo de xml de envio: Segue em anexo os documentos necessários para que seja feito a Integração com o nosso sistema O endereço para a integração via Webservice é: : https://igarape.quasar.srv.br/nfe/ Através deste endereço o contribuinte poderá realizar os testes de envio e a integração definitiva para homologação das notas. Envio em anexo também os manuais e esquemas necessários para que o contribuinte possa adaptar seu sistema próprio de emissão de notas fiscais. No sistema de ISS DIGITAL, há a opção de realizar a verificação e também a opção de baixar estes manuais. Acessando o menu NF-e\Integração via Webservice Seguem algumas observações: 1- O contribuinte não precisa de certificação digital. O sistema de integração necessita das informações de acesso ao ISS DIGITAL (inscrição municipal/senha/frase secreta) 2- O ambiente é o mesmo para teste e homologação, porém o que irá definir se a nota será de teste ou definitiva é a informação da tag "produção", ou seja, se informada "produção 2" notas de teste serão validadas, se informado "1" notas definitivas serão validadas. 2.1 Notas de teste (produção 2) não totalizam valores na guia / receita e poderão ser excluídas após finalizar os testes . Basta encaminhar um e-mail solicitando a exclusão. 2.2 Notas de homologação definitiva (produção 1) geram guias de recolhimento para o contribuinte. E somente são canceladas pela prefeitura mediante análise de requisição de cancelamento. 3- O contribuinte deverá baixar no ISS DIGITAL o arquivo das Atividades Cnaes, que serão necessárias para realizar a integração (menu Relatório\Atividades) 4- A nota de teste é identificada no sistema de ISS DIGITAL, com a nomenclatura T00000*. Quando a nota for para homologação, a numeração será a mesma utilizada pelo ISS Digital. Seguem em anexos os manuais, modelo RPS, tabelas de municípios, países, e schemas referentes a integração via webservice e o exemplo do arquivo RPS no formato .xml e no padrão ABRASF. Qualquer dúvida estamos à disposição. Atenciosamente, Suporte Quasar modeloxml.xml