rodrigo4t

Sérgio, bati no mesmo problema que você. Engraçado que no mês de março meu cliente conseguiu emitir todas as notas da maneira como estava o componente. Esse mês começou a dar erro e agora ele tem 300 notas esperando pra serem emitidas e esse maledeto provedor SmaraPD sem rodar. Na unit pnfsEnvLoteRpsResposta eu apliquei a mesma correção que você, convertendo do formato ISO 8601: infRec.FDataRecebimento := ISO8601ToDate(xData) Com isso consegui passar desse ponto, mas acredito ter chegado no mesmo ponto em que você parou: Nesse trecho da pnfsNFSeR, no método TNFSeR.LerNFSe_ABRASF_V2: (linha 2286) if FProvedor in [proSmarAPDv23, proAEG] then NFSe.DataEmissaoRps := Leitor.rCampo(tcDatVcto, 'DataEmissao') <--- aqui else NFSe.DataEmissaoRps := Leitor.rCampo(tcDat, 'DataEmissao'); O erro é que o conteúdo de 'DataEmissao' está voltando -1 E aqui empaquei. Você conseguiu avançar desse ponto ? Alguém tem alguma ideia ?

Só para dar o feedback a todos: Consegui fazer o envio em produção da NFS-e. Utilizei o método "Enviar" e não o "EnviarSincrono". Tive só o problema da prefeitura rejeitar a nota fiscal com o ISS devido para o código de serviço que meu cliente usa (o 7.09). Isso no entanto não é problema exclusivo do webservice, já que acontece também com as notas emitidas pelo portal. Meu cliente foi na prefeitura pra ver isso e a resposta deles foi "vamos ajustar isso no sistema", mas não deram prazo pra resolver.

Na verdade a comida de bola foi minha. Olhando o manual da abrasf o lay-out deles não prevê o campo de informações complementares. Eu parei de enviar o campo e aí a NF passou, mas agora estou com uma situação onde eles não deixam eu informar o ISS devido pro tipo de serviço prestado pelo meu cliente.

Eu atualizei os fontes mas parece que o Schema padrão da Abrasf não tá funfando... quando eu tento enviar a nota, ao validar o schema, dentro da função SSL.Validar: Element ''{http://www.abrasf.org.br/nfse.xsd}InformacoesComplementares'' is unexpected according to content model of parent element ''{http://www.abrasf.org.br/nfse.xsd}InfDeclaracaoPrestacaoServico''.'#$D#$A

Sérgio, você teve problemas com a senha ? Depois de muita luta eu consegui fazer o envio, mas recebo mensagem de "senha inválida" mesmo utilizando a senha que meu cliente usa pra fazer a emissão pelo portal. Estou aguardando o Italo liberar os fontes atualizados, mas desconfio que terei problemas com a senha ainda.

Italo, o técnico da prefeitura acabou de confirmar Os schemas que eles utilizam são os publicos disponíveis no site da ABRASF, não foi feita nenhuma modificação própria. São os schemas que o Herivelton já publicou aqui.

A visita não foi de grande serventia... o contador disse que haviam dezenas de pessoas com o mesmo problema da senha. Sobre os arquivos .XSD, resposta padrão: Dentro do wsdl acima tem o link: http://tributacao.vilavelha.es.gov.br:80/tbw/services/Abrasf23?xsd=1 Italo, mandei um e-mail pro suporte da SmaraPD solicitando os schemas, vamos ver o que eles respondem.

Herivelton, onde você achou esses schemas ? Direto com a SmaraPD ?

Italo, o contador do meu cliente está nesse exato momento na prefeitura de vila velha esperando ser atendido por um funcionário da área técnica. Eu já pedi que ele me coloque em contato com esse funcionário quando for atendido porque aí eu vou solicitar os schemas pra ele. Na documentação fornecida pela prefeitura não constam os schemas, apenas o endereço do webservice.

Bom, nada ainda... - Atualizei o ACBR, recompilei e reinstalei os componentes no Delphi, alterei o arquivo cidades.ini para a seguinte forma: [3205200] Nome=Vila Velha UF=ES Provedor=SmarAPD NomeURL_H=tributacao.vilavelha.es.gov.br:8080 NomeURL_P=tributacao.vilavelha.es.gov.br:80 (estranho que no meu caso, no momento do envio ele já acrescenta /tbw na frente dos servidores) - Confirmei que o meu cliente consegue acessar o site da NFS-e da prefeitura de Vila Velha, ele conseguiu emitir uma NFS-e por lá, apesar de ter vários problemas no processo. - Debuguei a unit ACBRNFSeWebServices e verifiquei que no bloco abaixo: case FProvedor of proSimplISS: ATexto := StringReplace(ATexto, '%Senha%', ParseText(SenhaWeb, False), [rfReplaceAll]); proSMARAPD: ATexto := StringReplace(ATexto, '%Senha%', EncodeBase64(SHA1(SenhaWeb)) , [rfReplaceAll]); proIPM: ATexto := StringReplace(ATexto, '%Senha%', ParseText(SenhaWeb, False), [rfReplaceAll]); else ATexto := StringReplace(ATexto, '%Senha%', SenhaWeb, [rfReplaceAll]); end; A senha está sendo alterada com o hash base64, conforme orientação do suporte do SmaraPD, mas mesmo assim estou recebendo o retorno de "senha incorreta" Minha ultima alternativa agora é o contador do meu cliente que está indo pessoalmente na prefeitura tentar falar com alguém que verifique se há alguma autorização pendente.

Vou atualizar os fontes do ACBr também, a última atualização que tenho aqui é de 9/2 e estou achando estranho o meu arquivo cidades.ini não ter passado quando deixei igual ao seu.

Herivelton, eu tentei enviar em produção a nota mas precisei configurar o cidades.ini assim: [3205200] Nome=Vila Velha UF=ES Provedor=SmarAPD NomeURL_H=tributacao.vilavelha.es.gov.br:8080 NomeURL_P=tributacao.vilavelha.es.gov.br:80 Você conseguiu enviar alguma NFS-e ? Quando eu tentei, recebi uma mensagem de senha incorreta, mesmo utilizando a senha que o cliente acessa o sistema de emissão de NFS-e no portal. Liguei pra SmaraPD e me disseram que preciso aplicar um hash na senha e me deram um endereço de e-mail do suporte para solicitar o manual de desenvolvimento do webservice.

hmm, então eles estão usando o serviço principal do SmaraAPD e não a versão que o Italo falou. Herivelton, a prefeitura te respondeu com o endereço do ambiente de homologação ?

Obrigado Italo! Eu estou esperando alguém da prefeitura responder com o endereço do webservice de homologação, aí eu altero e faço os testes.

Herivelton, já me deu uma luz.... eu não tinha conseguido nem isso. O único retorno que eles me deram foi o do webservice de produção: http://tributacao.vilavelha.es.gov.br/tbw/services/Abrasf23?wsdl Eu pedi o endereço do webservice de homologação mas eu desconfio fortemente que eles não ativaram um. Eu lembro de quando eles ativaram o servidor com o sistema de Vitória, eu cheguei a ir lá na prefeitura conversar com o responsável técnico, na época eles disseram que não iam montar servidor de homologação pq não tinham espaço físico pra estrutura no lugar..

Bom dia pessoal. Mais alguém aí foi pego de surpresa com a alteração repentina do sistema de emissão de NFS-e da prefeitura de Vila Velha ? Simplesmente mudaram o sistema hoje e fui comunicado só hoje pelo meu cliente, não sei há quanto tempo eles já sabiam dessa mudança. Antes eles utilizavam o mesmo sistema desenvolvido pela prefeitura de Vitória, e olhando o manual do recadastramento parece que eles optaram por uma solução própria baseada no padrão Abrasf 2.3. Não encontrei sequer links pros webservices de homologação pela documentação. Alguém que atende o municipio de vila velha tem maiores informações ?

Alguém já passou por isso ? tem alguma dica ?

Olá pessoal, Estou com um erro estranho. Comecei a trabalhar com SAT em um cliente hoje e de cerca de 10 CFes emitidos, apenas um deu "erro desconhecido". Puxando o log pelo aplicativo da Bematech, apareceu o seguinte: 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature><SignedInfo>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature><SignedInfo><CanonicalizationMethod>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature><SignedInfo><SignatureMethod>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature><SignedInfo><Reference>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature><SignedInfo><Reference><Transforms>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature><SignedInfo><Reference><Transforms><Transform>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature><SignedInfo><Reference><Transforms><Transform>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature><SignedInfo><Reference><DigestMethod>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature><SignedInfo><Reference><DigestValue>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature><SignatureValue>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature><KeyInfo>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature><KeyInfo><X509Data>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Abortando parsing. Elemento '<CFe><Signature><KeyInfo><X509Data><X509Certificate>' não deveria constar nos dados do cupom 05/11/2019|10:02:08|AC-SAT|info|Erro de validação com o xsd: Element '{http://www.w3.org/2000/09/xmldsig#}Signature': This element is not expected. 05/11/2019|10:02:08|AC-SAT|info|Erro ao validar dados de venda com o xsd 05/11/2019|10:02:08|AC-SAT|erro|Erro ao receber os dados de venda 05/11/2019|10:02:08|AC-SAT|erro|Erro ao realizar a validação dos parâmetros 05/11/2019|10:02:08|SAT-AC|info|487567|06010|1999|Erro desconhecido|| Achei estranhíssimo. Fui olhar o cupom fiscal gerado antes da transmissão e a única coisa diferente que percebi era que a unidade de medida estava PÇ, com cedilha. Fiz a alteração para PC, mas o erro persiste. Alguém tem uma dica do que pode ser isso? Segue o XML gerado do cupom: <?xml version="1.0" encoding="UTF-8"?><CFe> <infCFe versaoDadosEnt="0.07"> <ide> <CNPJ>05960725000145</CNPJ> <signAC>S0uSqUkOAdI5O3Uy9jFbG76qaNtopXLUgWjRE9DjM9+TYo9HpLOtS1C1I9daPZSHtJ+2eQRffZj/PcTZh09AgiKHQ+LoxXWrX2Gmg98RFZzl0vMwdAGQG4l8Nooa6qAPYjOetp5UlPpSTRBcTNA/m9UBriw2nNOGKUzywRndO3s1i+bMDZNjYrpBA+dUDso1NegT4f8AZ4uxKKJ9PJYg8Z+d8sx4O6ySSUZsoogJjtGP8en03ATOigYOeN/kd7ZqUxWA/srLZeZhx4T+jng5+q3jpd1zk4vCAGMoF49j+Zl6RhL4HBHE6SFctXbPe/zAbnkEsMHXx+rWn6GMjg0zHw==</signAC> <numeroCaixa>001</numeroCaixa> </ide> <emit> <CNPJ>54113238000152</CNPJ> <IE>626169220119</IE> <indRatISSQN>N</indRatISSQN> </emit> <dest> </dest> <det nItem="1"> <prod> <cProd>V90088</cProd> <xProd>ELASTICO PARA BAGAGEIRO 2MTS COD 67202</xProd> <NCM>56041000</NCM> <CFOP>5102</CFOP> <uCom>PC</uCom> <qCom>2.0000</qCom> <vUnCom>4.90</vUnCom> <indRegra>A</indRegra> </prod> <imposto> <vItem12741>1.32</vItem12741> <ICMS> <ICMS00> <Orig>0</Orig> <CST>00</CST> <pICMS>18.00</pICMS> </ICMS00> </ICMS> <PIS> <PISAliq> <CST>01</CST> <vBC>9.80</vBC> <pPIS>0.0200</pPIS> </PISAliq> </PIS> <COFINS> <COFINSAliq> <CST>01</CST> <vBC>9.80</vBC> <pCOFINS>0.0800</pCOFINS> </COFINSAliq> </COFINS> </imposto> </det> <total> <vCFeLei12741>1.32</vCFeLei12741> </total> <pgto> <MP> <cMP>04</cMP> <vMP>9.80</vMP> </MP> <MP> <cMP>04</cMP> <vMP>9.80</vMP> </MP> </pgto> </infCFe> <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="35191154113238000152590007051490000067995817"> <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>DRFr+0AWdyOA0NTr+kZyBZH2r4lQHAnKd73Ns7I3GXw=</DigestValue> </Reference> </SignedInfo> <SignatureValue>sgkxIBdiFjADvhfsfnvKogr6VDBUJpRsshjY0vMctx7QjCNq6iA7aY4bbw6SRIppnvb673Hdzyla1MGzG7KtDePT3TPnLhyuw9R7734QJorXkde79XBs9pvWVPGcRt55fpWHfZodyWFmvE4clpWksFg0EZjAW+LUuhwMeQmHz0mF789CkZf9xMTpxtiDJbiwuBwGCI1nItGrDUTlOdnKqNR2r+TEQ7XmAGnYJrmrMnRWWbA+lsAFCEsDL1NkAHCGWefZDbx4jeIx4YFsRGeJA7s7hKp8U55/oSxi8gvDwyiKKdrQByhNzP/0pMSrAlS7yxWdm2OfefetlWNFnUUksg==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIGlDCCBHygAwIBAgIJARpXZzTcM28WMA0GCSqGSIb3DQEBCwUAMFExNTAzBgNVBAoTLFNlY3JldGFyaWEgZGEgRmF6ZW5kYSBkbyBFc3RhZG8gZGUgU2FvIFBhdWxvMRgwFgYDVQQDEw9BQyBTQVQgU0VGQVogU1AwHhcNMTkxMTAxMTQ0MTI3WhcNMjQxMTAxMTQ0MTI3WjCBzTESMBAGA1UEBRMJMDAwNzA1MTQ5MQswCQYDVQQGEwJCUjESMBAGA1UECBMJU2FvIFBhdWxvMREwDwYDVQQKEwhTRUZBWi1TUDEPMA0GA1UECxMGQUMtU0FUMSgwJgYDVQQLEx9BdXRlbnRpY2FkbyBwb3IgQVIgU0VGQVogU1AgU0FUMUgwRgYDVQQDEz9DQkEgQk9SUkFDSEFTIEUgUExBU1RJQ09TIENPTUVSQ0lPIEUgSU1QT1JUQUNBTyA6NTQxMTMyMzgwMDAxNTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDL6Ku0b7Yzkk75DG6BhC1HPliA4QJ5PT3y0jl7G/K2ZmJKMXxqoSOamoBw7WsRLFVrItA/UR8ml2c/nMPYTIe/bYmF9qwVQ1/S4C0rZGuFPjFakBwItCMbiCc6VrI/u1q7cURURDWUChsys5RkxwhjoBReBEnIpMro/XQuqe+LIJvvnExRnOodFQbukHgKUMOTyRdhygBk32R0cK2k+g31DRHJh6DZ2Hy1HI792KsinOWPl9dYlKGmkDE0GRhSNRoYB1EYMT/FeXO1n4yKmDErywGttOpUdb8I5cguMHOlRalfNnJag65fvZb7MXBxreRmA5WIj1KTV6VjBYoo7FxbAgMBAAGjggHwMIIB7DAOBgNVHQ8BAf8EBAMCBeAwdQYDVR0gBG4wbDBqBgkrBgEEAYHsLQMwXTBbBggrBgEFBQcCARZPaHR0cDovL2Fjc2F0LmltcHJlbnNhb2ZpY2lhbC5jb20uYnIvcmVwb3NpdG9yaW8vZHBjL2Fjc2VmYXpzcC9kcGNfYWNzZWZhenNwLnBkZjBlBgNVHR8EXjBcMFqgWKBWhlRodHRwOi8vYWNzYXQuaW1wcmVuc2FvZmljaWFsLmNvbS5ici9yZXBvc2l0b3Jpby9sY3IvYWNzYXRzZWZhenNwL2Fjc2F0c2VmYXpzcGNybC5jcmwwgZQGCCsGAQUFBwEBBIGHMIGEMC4GCCsGAQUFBzABhiJodHRwOi8vb2NzcC5pbXByZW5zYW9maWNpYWwuY29tLmJyMFIGCCsGAQUFBzAChkZodHRwOi8vYWNzYXQuaW1wcmVuc2FvZmljaWFsLmNvbS5ici9yZXBvc2l0b3Jpby9jZXJ0aWZpY2Fkb3MvYWNzYXQucDdjMBMGA1UdJQQMMAoGCCsGAQUFBwMCMAkGA1UdEwQCMAAwJAYDVR0RBB0wG6AZBgVgTAEDA6AQBA41NDExMzIzODAwMDE1MjAfBgNVHSMEGDAWgBSwhYGzKM12KikkS19YSm9o2aywKjANBgkqhkiG9w0BAQsFAAOCAgEAPUWELFrkAf/WW1GOWdCK06oH6B2/xgO0wZtTMYJwVhklZrdKbh5GK4ji7YmId5OClBhEA7oFfENkGiOUX3GjAlkW9s32M0o00voJKgH3H90GIhj0zTM+ztCYytTMtOrNJ0fdFq8dhgOeGNeUj/6Q8qjPKvrzz4RpNkVYpc232Ctu3DYY+5wXfgJ9wdHlLm6qsOeZX6xmZzqCplng/hAopPQEtYHre48n8aCooI+Ucg7XUwNSDp7sqbphibZh4AANhmJn0AZw6RRg4eew2KBsLwIjT5XL4maMKyLpDONP0fF5nL8o+g0ZhJB5AWXmf3nAC6VNjqPLR78kVIMPGMoUMsbdaJPqoItun/qyl7JBtv+nE0zCJs/+Qz6C5iObIt+hHc1xkoG2mavGn20mzVZMzw+B2ipnIBR/pXB42oUQUeuVy4oe5vnFezn6f3L9RXsG2TC9rTNiYMpGpLh5+B9a3qk9kX+8VpuCI+FH4ETFJsdCbk9AyHrtlBTdld4LPQX9Vn6Yj7XBBtbnIMUu3xZ9oJmsoUIHLpUIogCy8oSCdQ0NvgqFDz9hAyXpznBQp6vrFFTP0n2yMZNw1IALiNTML9J/w/kkSTIcGpp4kFHGffmNe6gP1yBwM+Z+gkUsJVmRiI4eua8Y7W9hDHMQmvo81F0GoYyTkRwVDT9y8K3hyok=</X509Certificate> </X509Data> </KeyInfo> </Signature> </CFe>

Bom dia pessoal, Bom, olha só a palhaçada da prefeitura de Vila Velha: Meu cliente foi emitir as NFS-e ontem e a nota era rejeitada com um erro de alíquota de ISS inválida. Mesmo sistema que havia transmitido as NFs anteriores, sem alteração nenhuma. Depois de muito analisar, ligamos pra prefeitura de Vila Velha e conseguimos a informação que eles mudaram a máscara do campo ItemListaServico: Onde antes eu enviava no formado 7.09 passou a ser 07.09. Problema: no código fonte do arquivo pnfsNFSeW_ABRASFv2.pas, tem o seguinte bloco dentro do método TNFSeW_ABRASFv2.GerarServicoValores: if FProvedor <> proGoiania then begin case FProvedor of proBethav2, proSisPMJP, proVirtual: Gerador.wCampoNFSe(tcStr, '#29', 'ItemListaServico', 01, 05, 0, OnlyNumber(NFSe.Servico.ItemListaServico), DSC_CLISTSERV); proNotaInteligente: Gerador.wCampoNFSe(tcStr, '#29', 'ItemListaServico', 01, 05, 1, NFSe.Servico.ItemListaServico, DSC_CLISTSERV); proVitoria: begin if copy(NFSe.Servico.ItemListaServico, 1, 1) = '0' then Gerador.wCampoNFSe(tcStr, '#29', 'ItemListaServico', 01, 05, 0, copy(NFSe.Servico.ItemListaServico, 2, 4), DSC_CLISTSERV) else Gerador.wCampoNFSe(tcStr, '#29', 'ItemListaServico', 01, 05, 0, NFSe.Servico.ItemListaServico, DSC_CLISTSERV); end; else Gerador.wCampoNFSe(tcStr, '#29', 'ItemListaServico', 01, 05, 0, NFSe.Servico.ItemListaServico, DSC_CLISTSERV); end; Pro provedor Vitória, é cortado o zero à esquerda se houver. Agora, eu não sei se a alteração do fomato foi geral e tanto Vila Velha quanto Vitória passam a entender o formato novo, ou se foi uma liberdade tomada pela prefeitura de Vila Velha. Se foi isso, o correto seria separar o provedor e criar um específico pra Vila Velha; no entanto, tem um outro ponto na história: não achi válida a criação de um novo provedor no ACBR porque a prefeitura de Vila Velha está mudando os sistemas e a informação que tivemos é que eles vão contratar outro provedor pra assumir os serviços de ISS. Não sabemos exatamente quando isso irá acontecer. Será que alguém aqui que trabalhe com a prefeitura de vitória pode confirmar se aconteceu a mesma modificação por lá, pra saber se eu subo a alteração da Unit pro projeto ou não ?

Boa tarde pessoal, Vamos ver se alguém já passou por uma situação similar ou se de repente me dá uma luz com uma situação. Tenho um cliente, pessoa jurídica, que fez a compra de um gerador vendido por pessoa física. No Espírito Santo existe um treco chamada "nota fiscal avulsa", que é um talonário emitido pela SEFAZ-ES que permite que pessoas mesmo não tenho inscrição estadual ou empresa aberta façam a venda de mercadorias. Agora o problema: o bentido do gerador deu problema e precisa ser devolvido. Quando meu cliente gera a NF de devolução contra uma pessoa física, no método Validar do ACBRNFe eu já recebo a seguinte mensagem: element {http://www.portalfiscal.inf.br/nfe}cpf: this element is not expected. expected is ( {http://www.portalfiscal.inf.br/nfe}cnpj Vejam que o erro acima não é uma rejeição da RFB, é um erro de validação do schema. O negócio é, qualquer NF-e emitida contra pessoa física funciona normalmente, a falha de validação do schema só acontece nesta NF de devolução. Alguém já passou por uma situação similar ? Existe alguma forma de transmitir a NF-e sem a validação do XML previamente a transmissão ?

Bom dia pessoal, Eu fiz uma atualização ontem do ACBr e o meu módulo de envio da Reinf começou a apresentar um erro na primeira compilação. Quando fui verificar, vi que a tag "Ideevento.tpAmb" foi removida de todos os eventos do componente. Agora a identificação se estamos enviando em produção ou produção restrita é só na configuração do componente, dentro de Webservices.Ambiente ?

Boa tarde pessoal, Eu estava com problema em um cliente de Guarapari - ES, cidade que usa o SmaraPD na versão 1.0. Ele enviava a quantidade do ítem de serviço com duas casas decimais, mas o RPS truncava para um valor inteiro. Depois de confirmar com o suporte do SmaraPD que eles aceitam a quantidade com casas decimais, eu fiz a seguinte alteração no arquivo pnfsNFSeW_SMARAPD.pas: na linha 128 eu modifiquei: Gerador.wCampoNFSe(tcInt, '', 'quantidade' , 01, 005, 1, FNFSe.Servico.ItemServico.Quantidade, ''); para Gerador.wCampoNFSe(tcDe2, '', 'quantidade' , 01, 015, 1, FNFSe.Servico.ItemServico.Quantidade, ''); Segue o arquivo anexo com a modificação pnfsNFSeW_SMARAPD.pas

Pessoal, eu também estou com um caso muito estranho aqui em SP... um cliente está tentando emitir nota há quase uma hora, mas aparece apenas um erro de "falha de validação nos dados da nota!", mas sem mensagem de erro adicional de erro na estrutura ou algo do gênero. Já validei o XML em outras ferramentas mas não tem problema algum na estrutura do XML. Mais alguém está com problema pra emissão de NF-e em SP ?

Boa tarde Ítalo, A migração está sendo tão malfeita, que o site da prefeitura de cachoeiro sequer disponibiliza ainda os manuais ou schemas para o provedor novo. Tudo no site da NFS-e ainda aponta para o software da Ábaco. Eles provavelmente só irão disponibilizar as informações quando o sistema já entrar direto em produção, na próxima segunda-feira. Quando o sistema novo entrar em vigor, eu posto os schemas aqui.

Pessoal, desculpe a mensagem anterior, só agora debugando os fontes eu percebo que o próprio ACBRNFSe aplica o Hash à senha. Eu consegui passar pelo erro de senha, mas tenho um retorno que o campo "codatividade" não foi preenchido. Olhando os fontes do ACBr não consigo encontrar qual campo do componente deve ser preenchido para que a informação seja enviada no XML. Alguém pode me ajudar ?