José S. Simione

Sim

Estou enfrentando o mesmo problema e estou com os fontes atualizados. Alguém tem alguma sugestão de solução?

Bom dia Italo, Esta configurado, mas não esta chegando o gerar o arquivo. Devido a falta de certificado não testei pelo programa exemplo, imaginei que mais alguém teria esse problema ou que pelo menos conseguiria uma XML aprovado de exemplo para me auxiliar. Vou mandar o programa de exemplo para o cliente e testar diretamente por ele, conforme recomendou. Retornarei com o resultado.

Efetuei um teste seguindo a sugestão da @Denise Lima. Desta vez não houve erro algum, porem o RPS não foi recebido pelo WebService, gerou apenas um XML, ao tentar envio não da retorno, consulta também sem retorno. A remoção da configuração citada aparentemente apenas ocultou a exceção. Segue o XML gerado. 2947NF-rps.xml

Ola novamente Denise, obrigado pela ajuda! Estou marcando sim, vou remover essa configuração e testar junto ao cliente, retorno com o resultado.

Bom dia Denise, Sim, em pesquisas vi que pode demorar até 24 horas para constar no WebService destino, então tentei aguardar esse período para consultar tanto pela aplicação quanto direto no site da prefeitura (pelo Usuário do meu Cliente), porem sem sucesso. A grande duvida vem desse status estar sendo gerado na ação de Enviar o RPS, seria compreensivo esse retorno durante uma consulta, mas durante o envio não. Estou tentando recriar o processo em minhas maquinas de testes para ver se consigo algo como um debug, mas infelizmente sem um certificado valido não estamos conseguindo simular por completo o processo dos clientes.

Alguém teria alguma informação para me ajudar sobre esse caso? Se alguém tiver um XML de NFSe aprovada em Campinas ja ajudaria.

Boa tarde italo, Para não exibir nenhum CNPJ de meu cliente eu editei esses campos dos XML's

Olá, Estou tendo problemas para enviar um RPS para o o webservice de Campinas/SP, infelizmente não possuo um certificado valido para efetuar teste em debug e estou sendo obrigado a testar diretamente com o cliente o que esta dificultando bastante na solução do problema, gostaria de ajuda para identificar e também saber se é um erro recorrente ou uma falha da minha parte. Não possuo muitas informações sobre o erro, mas abaixo vou anexar tudo que tenho para auxiliar na resolução: * Primeiramente identifiquei um problema nos campos de Valores e Alíquotas onde limitavam os caracteres para 2 onde descordavam do layout de Campinas, esse ajuste foi feito na unit "pnfsNFSeW_ISSDSF", em anexo. * Apos a correção do primeiro item me deparei com a seguinte exceção: 1 EACBrDFeException erro com a mensagem de:Lote nao processado ainda. Tenho em vista que o indicador 1 no inicio do erro condiz com uma falha no envio. * Possuo mais de um cliente com esse problema o que faz presumir que não umas questão de certificação. Infelizmente são as informações que possuo, visto a impossibilidade de debugar o processo. Segue em anexo as xml geradas pelos testes junto ao cliente, omitindo apenas os CNPJ contidos,. Gostaria de pelo menos alguma luz para me guiar nesse processo. Grato desde já. 2947-env-lot.xml 2947-env-lot-soap.xml 2947NF-comp-nfse.xml 2947NF-con-nfse-rps.xml 2947NF-con-nfse-rps-soap.xml pnfsNFSeW_ISSDSF.pas

Olá, Estou passando pelo mesmo problema ao tentar enviar uma NFS-e de Campinas, por acaso já obteve sucesso? Teriam alguma informação para me auxiliar?

Bom dia, Juliomar. Obrigado pelo retorno. Eu estava revisando e encontrei um problema no tamanho do campo do CPF/CNPJ do Proprietário do Veículo, estava com 14 caracteres e não era o suficiente para um CNPJ formatado. alterei para 18. Segue a Unit. ACBrCTeDACTEFR.pas

Olá, Bom dia! Estou ajustando a DACTe OS para o uso de meus clientes, efetuei alguns ajustes de alinhamento, formatação e alteração de alguns Labels. Segue o fr3 junto da unit alterada. Qualquer dúvida ou questionamento estou a disposição. Att José S. Simione DACTE_OS.fr3 ACBrCTeDACTEFR.pas

Bom dia a todos. Fiz essa alteração, efetuei o Encerramento carregando apenas o Grupo EventoMDFe do componente, sem carregar a XML do MDFe, isso resolveu o problema dos clientes no qual testei até o momento. Muito obrigado pela ajuda e colaboração de todos.

@bsoft Tentei com sua alteração, mas foi sem sucesso. O senhor chegou a testar essa alteração no ambiente de Produção? Se sim, saberia dizer de qual estado, pois meus clientes de SP não estão com este problema, pelo visto esta se concentrando no nordeste (ES, BA, CE e MG). Alguém conseguiu efetuar esse processo em Produção em algum desses estados?

O XML esta na versão 1.00, os servidores dessa versão foram desativados, nenhuma operação com esse cabeçalho será validada no novo servidor. Fica dúvida referente a Manifestos abertos na versão 1.00 que não foram encerrados, alguém saberia dizer o que será feito desses casos, visto que nem na consulta de Não Encerrados da Sefaz eles aparecem, demos considerar todos como encerrados ou sem valor fiscal a partir da data de hoje?

Quando vc diz "Os clientes de Minas Gerais não estão com problema" quer dizer que você conseguiu aprovar um CT-e OS pelo WS de Minas Gerais?

Bom dia a Todos! @Italo Jurisato Junior, estou passando pelo mesmo problema, o que o senhor disse faz sentido, porem a rejeição não seria essa: "Rejeição: Emissor não habilitado para emissão do CT-e". Seria possível isso ser um erro no retorno da Sefaz ou teria algum outro possível motivo? Grato pela Atenção! Att

Boa tarde! Em alguns teste encontrei um pequeno problema com relação ao child de Documentos de Transportes Anteriores, esses campos não eram impressos quando o tipo de serviço era igual a Subcontratação ou Redespacho. Efetuei essa correção na DACTE padrão e em modelo adaptado para 3.00 que utilizo com alguns clientes. Segue os fr3 para analise. Qualquer dúvida estou a disposição! DACTE_Ve300.fr3 DACTE.fr3

Boa tarde Carlos, Bom, primeiramente não poderíamos fazer dessa maneira, porque isso iria fazer com que a TAG não fosse criada mesma na versão 2.0. E a ideia desses ajustes é mandar a 2.0 intacta perante as alterações previstas para a 3.0. Tendo isso em mente eu tentei aprovar um CT-e em Homologação com essa alteração sugerida, e me deparei com uma validação da SeFaz. O senhor conseguiu aprovar um CT-e 3.00 com esse fonte? Se sim gostaria de ver o XML para estudar essa mudança. Att José S. Simione

Bom dia Juliomar, Durante alguns testes encontrei um problema com o campo cInfManu, pois esse campo na versão 2.00 é tratado como um numérico onde as informações são gravadas assim: '1,2,3...', porem na versão 3.00 esse campo passou a ser char de 2 passando a ser alimentado assim: '01,02,03...' essa mudança interferiu na impressão desse campo na DACTe 2.0. Criei novos métodos de conversão na pcteConversaoCTe para atender a versão 2.0, e inseri eles na leitura, gravação e impressão do campo. Segue as Units alterar para verificação. Grato pela atenção e aguardo retorno. pcteCTeW.pas pcteConversaoCTe.pas pcteCTeR.pas ACBrCTeDACTEFR.pas

Bom dia, Juliomar. Só queria saber se esta tudo o que o código que não foi subido, ainda estou no aguardo desse fonte, caso tenha algum problema com o código estou a disposição para discutirmos sobre. Obrigado pela atenção! Att José S. Simione

Bom dia! Obrigado pela colaboração. Estava revendo o código referente a DACTe e encontrei um pequeno erro, no campo cInfManu, eu criei uma logica para formatar o campo com pontuações, esqueci de validar para que o ponto final, não fosse impresso caso o campo fosse vazio. Fiz uma pequena alteração nesse trecho para corrigir. Alterado de: for i := 0 to CTe.infCTeNorm.aereo.natCarga.cinfManu.Count - 1 do begin if (i > 0) then FieldByName('cInfManu').AsString := FieldByName('cInfManu').AsString + ', '; FieldByName('cInfManu').AsString := FieldByName('cInfManu').AsString + TpInfManuToStr(CTe.infCTeNorm.aereo.natCarga.cinfManu.Items[i].nInfManu); end; FieldByName('cInfManu').AsString := FieldByName('cInfManu').AsString + '.'; para: for i := 0 to CTe.infCTeNorm.aereo.natCarga.cinfManu.Count - 1 do begin if (i > 0) then FieldByName('cInfManu').AsString := FieldByName('cInfManu').AsString + ', '; FieldByName('cInfManu').AsString := FieldByName('cInfManu').AsString + TpInfManuToStr(CTe.infCTeNorm.aereo.natCarga.cinfManu.Items[i].nInfManu); end; if (FieldByName('cInfManu').AsString <> '') then FieldByName('cInfManu').AsString := FieldByName('cInfManu').AsString + '.'; Foi o único ajuste, peço desculpas pela falta de atenção nesse ponto e segue a UNIT com essa alteração. Att José S. Simione ACBrCTeDACTEFR.pas

Bom dia, Italo! Alterei o campo cInfManu para lista, conforme discutido acima. Segue as UNITs com as alterações já descritas no post e o campo em lista, mandarei também um modelo de DACTe 3.00 que estou usando com meus clientes. Grato pela atenção e aguardo o retorno. Att, José S. Simione pcteCTeW.pas pcteConversaoCTe.pas pcteCTe.pas pcteCTeR.pas DACTE_Ve300.fr3 ACBrCTeDACTEFR.pas

Bom dia, Italo! Obrigado pela atenção! Ótimo, vou estudar o campo de exemplo e ver como trabalhar com um campo assim. Se alguém souber como ler esses tipos de campo me ajudaria com algum exemplo de logica ou código. Att José S. Simione

Bom dia! O senhor chegou a ver o exemplo que dei? Devo concluir que você concorda e que é dessa maneira que devemos fazer? Devo pedir um pouco mais de atenção, pois não estou questionando se o item é uma lista ou não, e sim o fato de ser uma lista sem um grupo e que isso geraria uma XML peculiar como o exemplo que dei acima. No schemas temos a mesma questão o item não se encontra dentro de uma tag <xs:sequence> que indicaria o grupo desse item. Outro fato seria que no manual todo não existe outro campo que seja 0 - n que não pertença a um grupo, o que leva a crer que seja um erro no manual, que não seria o primeiro. Agradeceria uma resposta um pouco mais conclusiva, pois a outros pontos nesse post que gostaria de concluir.