gralak

Estou com a mesma situação, embora preenchidos a configuração com IDCSRT e CSRT e gerado no XML de envio o IDCRTS e hashCSRT a sefaz retorna. Status: 975 Motivo: Obrigatoria a informacao do identificador do CSRT e do Hash do CSRT <infRespTec> <CNPJ>00000003000900</CNPJ> <xContato>SAC</xContato> <email>[email protected]</email> <fone>44999999999</fone> <idCSRT>02</idCSRT> <hashCSRT>lMUtGBqZDF+jKS0FCxR53RxRjqU=</hashCSRT> </infRespTec>

Bom dia Pessoal no fonte ACBrBPeXmlWriter.pas no informativo da function Gerar_Comp ao informar a IE esta colocando a do EMITENTE gerando um erro no envio, fiz a alteração aqui para mim e voltou a funcionar informando da tag COMP. Segue a imagem da alteração que eu mesmo fiz.

Bom dia Fiz o teste de envio, impressão e pagamento Tudo certo agora 100%

Segue a imagem da documentação ! https://www.sicredi.com.br/media/produtos/filer_public/2022/09/26/manual_cnab_240_1-8_260922.pdf

Recebi um retorno do PJTech deve ser substituido por ZEROS quando o DIGITO da AGENCIA conter LETRAS na composição EXEMPLO: AI = 00 A3 = 00

Pessoal estou com uma situação que o DIGITO da AGENCIA são LETRAS no CASO AI Observei que no fonte ACBrBancoSicredi.pas na function a baixo esta assim, conforme destacado. Montando um código semelhante a esse 74891.12420 00012.507182 AI108.281080 1 99140000000600 Como devo proceder nesse caso ? Fontes atualizados dia 26/11/2024 function TACBrBancoSicredi.MontarCodigoBarras ( const ACBrTitulo: TACBrTitulo) : String; var CodigoBarras, FatorVencimento, DigitoCodBarras, CampoLivre, Modalidade:String; DigitoNum: Integer; begin with ACBrTitulo.ACBrBoleto do begin FatorVencimento := CalcularFatorVencimento(ACBrTitulo.Vencimento); Modalidade := IfThen(Trim(Cedente.Modalidade) = '', '1', Copy(Trim(Cedente.Modalidade),1,1)); { Monta o campo livre } CampoLivre := Modalidade + { 1-Com registro ou 3-Sem registro. Por enquanto vou deixar 1 mais tenho que tratar menhor essa informação } '1' + { 1-Carteira simples } OnlyNumber(MontarCampoNossoNumero(ACBrTitulo)) + PadLeft(OnlyNumber(Cedente.Agencia),4,'0') + { Código agência (cooperativa) } PadLeft(Cedente.AgenciaDigito,2,'0') + { Dígito da agência (posto da cooperativa) } PadLeft(OnlyNumber(Cedente.CodigoCedente),5,'0')+ { Código cedente } // Ver manual página 86 - CNAB240 ou 51 - CNAB400 '1' + { Filler - zero. Obs: Será 1 quando o valor do documento for diferente se zero } '0';

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.