gralak

Consegui fazer o envio atualizando o ACBR para a versão de hoje. No entando agora recebo a seguinte mensagem . <EnviarLoteRpsSincronoResposta xmlns:ns2="http://www.giss.com.br/tipos-v2_04.xsd" xmlns:ns4="http://www.giss.com.br/enviar-lote-rps-sincrono-resposta-v2_04.xsd" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#"> <ListaMensagemRetorno> <MensagemRetorno> <Codigo>A01</Codigo> <Mensagem>Não foi possivel atender a solicitação</Mensagem> <Correcao>Tente novamente mais tarde ou entre em contato com o atendimento.</Correcao> </MensagemRetorno> </ListaMensagemRetorno> </EnviarLoteRpsSincronoResposta> Alguma sugestão quem já passou por isso ?

Para mais detalhes Estou seguindo essas configurações, para envio do RPS em homologação. [4128104] Nome=Umuarama UF=PR ; A partir de 31/10/2024 descomentar as 3 linhas abaixo Provedor=Giss Versao=2.04 ProRecepcionar=https://ws-umuarama.giss.com.br/service-ws/nf/nfse-ws HomRecepcionar=https://v2-ws-homologacao.giss.com.br/service-ws/nf/nfse-ws

O arquivo 18112-env-lot-sinc-soap.xml esta com essa disposição.

Código : E173 Mensagem: Lote de RPS não assinado. Correção: Assine o lote de RPS Após a disponiblização do servidor em UMURAMA - PR para envio de NFSe em Homologação para o Servidor GISS, já seguindo a configuração a baixo no arquivo .ini recebo a mensagem E173 - Lote de RPS não assinado, estou enviando apenas 1 RPS por vez e no arquivo RPS consta a assinatura como destacado. A cofiguração do componente esta para libOpenSSL, xsLibXml2, LT_TLSv1_2. Como devo proceder agora ?? <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI=""> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>AzpwwLoDtttV15QoVmMmfcTk0yk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>REMOVIDO==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>REMOVIDO</X509Certificate> </X509Data> </KeyInfo> </Signature> ; A partir de 31/10/2024 descomentar as 3 linhas abaixo Provedor=Giss Versao=2.04 ProRecepcionar=https://ws-umuarama.giss.com.br/service-ws/nf/nfse-ws HomRecepcionar=https://v2-ws-homologacao.giss.com.br/service-ws/nf/nfse-ws

Código : E173 Mensagem: Lote de RPS não assinado. Correção: Assine o lote de RPS

Outra coisa que achei diferença foi o arquivo de SCHEMA que esta com o ACBR do WSDL. https://cianorte.oxy.elotech.com.br/iss-ws/nfse203.wsdl o Schema esta em anexo... a Tag tsAliquota apresenta diferença... nfse_v2_03.xsd

Pessoal a impressão de ALIQUOTAS de (ISSQN, PIS, COFINS, INSS, IR, CSLL, CPP) estão sempre com 4 casas decimais e os VALORES com 2 casas decimais como segue no fonte e no eschema de validação, no entanto a própria impressão no site da prefeitura que usa ELOTECH traz com 5 casas decimais. Para resolver o caso da aliquota de ISS com 5 casas alterei o fonte Elotech.GravarXML.pas na procedure TNFSeW_Elotech203.Configuracao; colocando FormatoAliq := tcDe5; Alterei também o Schema para não dar erro de validação e enviar a NFSe // Alterado também o SCHEMA da ELOTEHC // <xsd:simpleType name="tsAliquota"> // <xsd:restriction base="xsd:decimal"> // <xsd:totalDigits value="6"/> // <xsd:fractionDigits value="5"/> <-Aki colocado 5 digitos // <xsd:minInclusive value="0"/> // </xsd:restriction> // </xsd:simpleType> No entanto a criação do RPS gera com 5 casas decimais nas aliquotas, mas os valores somente com 2. Como devemos preceder nesse caso ? Sabendo que deve ser mesmo com 5 casas decimais para aliquotas e valores.

Não tem uma data especifica, somente esse recado de recomendação.É possivel que venha a ativar depois do dia 31/10/2024. Contudo se o ACBR ja conseguir alterar para podemos trocar as URLs ja deixamos preparados na homologação para alterar assim que liberar. Recomendações: Estamos disponibilizando um ambiente de homologação do novo ambiente para que os desenvolvedores de suas aplicações responsáveis pela transmissão de recibos provisórios realizem testes e as devidas adequações. Todas as empresas que atualmente emitem nota por RPS já possuem um cadastro valido nesse ambiente, caso sua empresa não tenha acesso ao mesmo, favor entre em contato com o atendimento

As URLS já estão disponiveis e ativas.

Comunicado RPS Informamos que a partir de 31/10/2024 a Gissonline não atenderá mais requisições dos serviços do webservice produção.ginfes.com.br e homologação.ginfes.com.br para recepção de recibos provisórios de serviços (RPS), consultas e cancelamentos para as respectivas notas fiscais de serviços eletrônica (NFSE). A partir dessa data Todas as requisições para processamento de recibos provisórios de serviços (RPS), cancelamentos e consultas de NFS-e serão atendidas somente pelo novo WSDL oficial da Gissonline. Endereços dos WSDL Produção: https://ws-umuarama.giss.com.br/service-ws/nf/nfse-ws?wsdl Homologação: https://v2-ws-homologacao.giss.com.br/service-ws/nf/nfse-ws?wsdl Após alterar o arquivo.ini com as novas URLs citadas a cima, recebo o seguinte retorno. Erro de Conexão: soap:VersionMismatch - A SOAP 1.2 message is not valid when sent to a SOAP 1.1 only endpoint. o componente esta configurado para OPENSSL como TLS 1.2 e o WINDOWS também nas opções de internet. Como devo proceder nesse caso ?

OK seguirei a sugestão...

Configurando o ACBRNFeX junto do exemplo que acompanha o ACBr, estou me deperando com esse retorno no envio da NFSe para o MEI em ambiente nacional Código : E0034 Mensagem: A situação do convênio do município emissor informado na DPS deve ser "ATIVO" no cadastro de convênio municipal do sistema nacional. A empresa emissora realmente é do MEI e configurado o provedor como proPadraoNacional. Segue em Anexo o XML da NFSe enviada. nota.xml

Bom dia Italo falei com alguns contadores e explicação foi a mesma. Desconto INCONDICIONADO é aquele desconto mais habitual que é negociado no ato do pagamento que não depende de nada para ser concedido, esse desconto não agrega BASE DE CALCULO então não é gerado imposto sobre esse valor. Desconto CONDICIONADO é aquele desconto que geralmente é aplicado sob uma determinada situação por exemplo: 10% de Desconto no pagamento em pontualidade, esse valor de desconto faz parte da BASE DE CALCULO então é gerado um imposto sobre esse valor também. Isso foi a explicação que me passaram então acredito que seja necessário a implementação do campo de desconto incondicionado no XML também.

Vou me informar e volto a postar.

Concondo contigo Italo, contudo o campo DescontoIncondicionado também não deve somando ao item? No caso não seria melhor apresentar Result[i].AppendChild(AddNode(tcDe2, '#', 'ValorDesconto', 1, 17, 1, NFSe.Servico.ItemServico[i].DescontoCondicionado + NFSe.Servico.ItemServico[i].DescontoIncondicionado)); ???