augelias

Desculpe a ignorância @Cleverson Favero, mas não compreendi o que você falou... O que havia entendido até o momento é que, devemos informar as bases quando ocorrer a situação 2 (saida para substituido e não consumidor final) e 3 (saida para consumidor final). No caso do distribuidor (situação 2), ele teria que armazenar a base para repassar para o varejista (utilizado no cálculo). No caso do varejista (situação 3), teria que "saber" que o produto teve cálculo da retenção e calcular a ST efetiva. No caso 3 mesmo que não precise apurar a base de origem, iria calcular sempre então? Seria isso?

Boa tarde! @João Paulo Müller, dá uma olhada na legislação de SC, se irão tratar da mesma forma que o RS (li praticamente toda legislação do RS para começar a entender alguma coisa). Deixar a seleção da origem da base na hora da venda, nos casos em que tem frente de caixa, por exemplo, torna-se inviável, pois o usuário normalmente não saberá qual associação fazer. Em alguma das postagens, é falado sobre armazenar o valor unitário de entrada. Será este método que irei utilizar, pois, cada nova entrada substituirá a base de cálculo unitária para ser usada na hora da venda. Sem um controle rígido por lote ou número de série registrado nos produtos, é inviável identificar qual a base de cálculo da nota associada para o produto sendo vendido, pois, basta modificar a ordem do produto na prateleira, como exemplo, que já bagunça todo o controle! Acredito que seja por isso que na legislação do RS tenha adotado este método (falha minha não ter especificado na postagem que a legislação é do RS). No momento, estou liberando uma versão do meu sistema onde irei ler todos os XMLs de notas de compra e atualizar os dados no banco de dados, tratando campos que não considerava antes. No segundo momento, irei recalcular todos os registros apurando se tem ou não base e atualizar as tabelas do sistema para que, na hora da venda, busque essa informação. Estou aceitando sugestões de como tratar esta situação, pois está dando um nó na minha cabeça!

Boa tarde @João Paulo Müller Acredito que nesta postagem abaixo você vai conseguir esclarecer tuas dúvidas (é onde estou acompanhando pra esclarecer as minhas!):

Boa Tarde Conforme a legislação que li até o momento, se não for possível identificar a base do o produto que está sendo vendido com a nota de compra, usa-se o ultimo valor de nota de entrada. Art. 28 - O contribuinte substituído, na operação que realizar com mercadoria recebida com imposto retido, emitirá documento fiscal, sem destaque do imposto, contendo, além das demais indicações: Parágrafo único - Na hipótese em que não for possível determinar a correspondência entre a base de cálculo do débito de substituição tributária e a respectiva mercadoria, tomar-se-á o valor que serviu de base para a retenção do imposto quando da última aquisição da mercadoria pelo estabelecimento, proporcional à quantidade saída. Esta será a solução que irei usar com meus clientes, pois muitos não fazem qualquer controle de notas... E para aqueles que já utilizam a importação de XML para meu sistema, já criei rotina para "revalidar" as notas importadas e buscar as informações que não tratava antes.

Bom dia @tdpsistemas Ocorreu esta mesma situação com um cliente específico utilizando a impressora DR800. Utilizo também a impressão através de spool. Até onde tive informações da Daruma, é possível ser um problema na fonte da impressora. No meu caso, como não é recorrente o erro, é bem difícil identificar. Possuo outros clientes com a mesma impressora que não tiveram este problema usando as mesmas rotinas de impressão. Qual o modelo de impressora que você está tendo esse problema?

Boa tarde @Italo Jurisato Junior Atualizei os fontes agora e consegui efetuar a transmissão e cancelamento para o provedor BHISS! Muito obrigado!

Boa tarde @Italo Jurisato Junior! Removi e reinstalei todo o ACBr hoje, testei o envio e tudo certo, mas o cancelamento estava com o mesmo erro na assinatura. Utilizei os mesmos ini do repositório para envio. Todos os testes que fiz foram com a prefeitura de Porto Alegre (BHISS). Comparei com a Unit que havia salvo que estava conseguindo enviar o cancelamento por último e fui restaurando linha a linha até que consegui enviar o cancelamento sem erro de assinatura. Anexei a unit alterada (já na versão mais recente) mas com as linhas que influenciaram na assinatura para o cancelamento para que você avalie. Espero que ajude. Obrigado desde já! ACBrNFSeWebServices.pas

Bom dia @barrys Sim, eu atribuo em tempo de execução, inclui esses parâmetros de configuração da NFSe em meu software e modifico eles conforme o a prefeitura, versão de windows e tipo de certificado que está sendo utilizado. Atribuo primeiro a SSLLib e depois os outros parâmetros caso eu modifique eles.

Bom dia @Danilo Ziza Experimente o seguinte: Configure para utilizar WinCrypt e SSLXMLSignLib como MsXml, é o que estou utilizando aqui para transmitir as notas, as outras propriedades não modifiquei.

Boa tarde @Italo Jurisato Junior! Segue a unit. Desculpa não ter conseguido analisar ainda o que influenciou no cancelamento, mas aqui está bem corrido e quando apaga um incêndio, tem que correr pra apagar os outros né! hahahahaha! Já testei inclusive em micros de clientes e agora estou conseguindo enviar o cancelamento que não estava fazendo depois da ultima atualização que fiz do repositório. Eu fui verificando o log de alterações e restaurando as units que foram modificadas até isolar somente esta para conseguir enviar o cancelamento. Obrigado pela atenção! ACBrNFSeWebServices.pas

Bom dia @Amarildo de Matos! Somente na sexta ao final do dia que consegui enviar o cancelamento sem erro de assinatura para a prefeitura. Comecei a fazer um rollback de cada versão do arquivo "ACBrNFSeWebServices.pas" e testar até que cheguei na revisão 15912 de 14/11 e consegui enviar o cancelamento se erro de assinatura. Houve diversos ajustes referente as rotinas de cancelamento nestas ultimas alterações e alguma delas pode ter influenciado na assinatura e vou tentar identificar o que pode ser para ajudar na análise. Obrigado por toda ajuda!

Aproveitando para acrescentar uma informação: Este arquivo de teste em anexo, para validar no site da receita federal, ao modificar a tag: <CancelarNfseEnvio xmlns="http://www.abrasf.org.br/nfse.xsd"> para <CancelarNfseEnvio> e tentar validar o arquivo, o mesmo retorna como válido. Desculpe a ignorância, mas esta informação é utilizada para assinar o XML @Italo Jurisato Junior? Não seria isso que pode influenciar para dizer que o arquivo assinado é válido ou não? Obrigado! 201800000001244-ped-can.xml

Boa tarde @Italo Jurisato Junior Realmente, está bem estranho, conforme o link que passei acima que estou utilizando para validar os XMLs, as notas de envio valida perfeitamente, os de cancelamento, acusa que não estão assinados. Já modifiquei diversas configurações dos arquivos .INI e parâmetros para utilização do certificado, em todos os testes, consigo enviar mas não cancelar. Para ajudar, anexo aqui um envio de nota aprovado e um pedido de cancelamento que não foi aprovado, ambos testados no site da receita para validar a assinatura digital e ocorrendo o que relatei acima. Agradeço desde já qualquer ajuda! 99363-env-lot-soap.xml 201800000001244-ped-can.xml 201800000001244-ped-can-soap.xml 99363-env-lot.xml

Olá @Amarildo de Matos testei com o schema do repositório, baixei direto o do site da prefeiura de porto alegre e sempre o mesmo erro. Já restaurei um bhiss.ini mais antigo que tinha no meu repositório para teste, também não funcionou. Testei em outros computadores, com outras versões de windows e certificados diferentes (usando micros de clientes) e sempre a mesma mensagem. Obrigado pela resposta

Bom dia! Estou com dificuldade no cancelamento de notas fiscais de serviço para a prefeitura de porto alegre (BHISS). Algum tempo atrás, já havia respondido um tópico com este mesmo assunto onde, na época, havia resolvido este problema trocando a configuração da SSLLib. Não localizei no fórum nenhum tópico que falando sobre essa situação. Comparei a estrutura do XML com XML antigos que haviam sido aprovados e não identifiquei diferenças. Ao validar a assinatura de um XML antigo através do site https://www.receita.fazenda.gov.br/Aplicacoes/SSL/ATBHE/assinadoc/ValidadorAssinaturas.app/valida.aspx o mesmo é validado, mas os XMLs atuais acusa como inválido. (XML de envio de notas atuais também são validados). Tentei todas as formas de configuração do certificado no meu sistema (capicom, wincrypt, openssl). Utilizei o Demo_ACBrNFse e também obtive os mesmo resultados. O arquivo anexado 2018/1229 é o que está com erro na assinatura, o 2018/853 a assinatura é validada. obs: Consigo enviar notas sem problemas de assinatura. Estou com todas as fontes e DLLs atualizadas. Agradeço desde já por qualquer ajuda! 201800000001229-ped-can.xml 201800000000853-ped-can.xml

Bom dia @André Guimarães! Anexei o arquivo BHISS.ini que estou utilizando (o mesmo do repositório). Instalei o certificado no micro e estou usando esta configuração de SSL: AACBrNFSe.Configuracoes.Geral.SSLLib := libWinCrypt; AACBrNFSe.Configuracoes.Geral.SSLXmlSignLib := xsMsXml; também estou usando todas as DLLs atualizadas do repositório e registrei o capicom e msxml5. Se não me engano tive este mesmo problema (são tantos que não dá pra lembrar de todos! hahahaha!) e resolvi mudando este parâmetro acima (xsMsXml). Espero que com essas informações te ajudem! BHISS.ini

@HRomano, Troca no arquivo Cidades.ini. Estava consultando na minha máquina e realmente mudou, comparei com os arquivos do repositório e os arquivos que utilizo no sistema e estão diferentes, acabei me passando e não te relatei antes.

Bom dia @HRomano Vou relatar o que me aconteceu esta semana para ver se te ajuda: Esta semana falei com o pessoal da Ábaco, eles informaram que removeram todos os usuários do modo homologação e recadastraram com base nos que já estavam em produção. Solicitei que me recadastrassem para continuar a usar o servidor deles com meu certificado, sem precisar usar os certificados de clientes. Até ontem a noite estava conseguindo emitir notas em modo de homologação para a prefeitura de Canoas/RS.

Bom dia Por favor, segue alteração para envio para o repositório do servidor de homologação no arquivo Cidades.ini para a cidade de Sapucaia do Sul/RS, provedor Infisc. De: homol.sapucaiadosul.infisc.com.br Para: sapucaiadosul-homol.infisc.com.br [4320008] Nome=Sapucaia Do Sul UF=RS Provedor=Infisc-v11 NomeURL_H=sapucaiadosul-homol.infisc.com.br NomeURL_P=nfse.sapucaiadosul.rs.gov.br Obrigado desde já! Cidades.ini

Boa tarde Italo, Desculpe a demora na resposta. A segunda mensagem acredito ser a configuração do uso do certificado, pois não consegui ainda utilizar este novo padrão de DLLs no meu computador, até onde consegui verificar aqui nos fontes. Quanto ao primeiro erro do prefixo nos campos, conforme o manual da Abaco, após retirar os mesmos acredito que irá validar sem problemas para a prefeitura de Canoas/RS Obrigado desde já!

Segue arquivos de um cliente que peguei hoje, validados em 16/03, usando uma versão anterior do sistema (liberei essa versão em 28/12/2017), logo, os fontes do ACBr utilizados estão com as alterações até essa data. Em alguns posts acima coloquei um exemplo validado e outro não do software em produção de uma versão mais recente do sistema com os fontes atualizados do ACBr até semana passada: 361-env-lot.xml 361-rec.xml

Italo, Realmente, os clientes atuais que estão rodando o sistema sem as ultimas alterações do repositório estão funcionando 100%. Após a atualização dos fontes e efetuar os testes na minha máquina que começou a apresentar estes erros. Ainda estou fazendo diversos testes para tentar identificar esta mensagem. Mas mesmo alterando o endereço do servidor de homologação não estou conseguindo validar. Segue alteração Cidades.ini: NomURL_H=https://enfs-hom.abaco.com.br/canoas no arquivo Abaco.ini não fiz a alteração do servidor de homologação. Consultei no manual da prefeitura (https://www.e-nfs.com.br/docse-nfs_canoas/portal/e-nfs_canoas/NFSE_INTEGRACAO_PADRAO_WS_ABRASF1_V202_CANOAS.pdf). Anexo está o arquivo de envio e recepção. 37-env-lot.xml 37-rec.xml

Bom dia Italo, Acrescentando ao que já reportei para ver se ajuda em sua análise: Estou debugando os fontes para ver o método de uso dos certificados com o servidor Ábaco de Canoas, e não estou conseguindo mais reproduzir a validação. Estou recebendo a mensagem: Não sei te dizer se tem a ver com as configurações que lhe passei ou com a configuração da forma de uso do certificado. Acrescento também o arquivo INI para sua análise, pois os endereços que constam no arquivo do repositório não são os mesmos utilizados pelo servidor da Ábaco. Obrigado desde já! Abaco.ini

Consegui validar a nota somente após a remoção dos dois prefixos em uma base de um cliente (pois meu cadastro com a prefeitura foi excluído). Não testei apenas uma ou outra.

Boa tarde Italo! Formatei a máquina e baixei os fontes esta semana, mas comparei agora os fontes alterados da minha máquina com a revisão 14860 e a única diferença é as linhas comentadas que eu alterei. É necessária alguma configuração para o provedor Abaco de Canoas/RS para que não inclua o texto "LOTE" no IdLote e o texto "RPS" no ID e somente os numeral?