Italo Giurizzato Junior

Boa tarde a todos, O componente ACBrNFSe atende sim a cidade de São Paulo.

Boa tarde Moisés, No manual do MDF-e existem vários modelos de DAMDFe e nenhum deles possui um quadro para apresentar o percurso. Caso deseje fazer alterações fique a vontade, os fontes estão disponíveis. O que você não pode é remover o que existe, apenas acrescentar.

Boa tarde Roberto, O Cancelamento e o Encerramento são eventos vinculados a um MDF-e. Como só podemos cancelar ou encerrar um MDF-e uma unica vez, logo o numero do evento é sempre um. Um MDF-e cancelado não pode ser encerrado e por outro lado um MDF-e encerrado não pode ser cancelado. Em nenhum manual ou nota técnica diz que devemos trocar ou acrescentar o protocolo de cancelamento/encerrado no XML do MDF-e. Sendo assim o XML do MDF-e sempre vai conter o protocolo de autorização de uso, mesmo que o mesmo tenha sido cancelado ou encerrado. Caso ocorra um problema técnico durante o cancelamento ou encerramento e você ficar sem o XML de retorno da SEFAZ que contem o protocolo de cancelamento/encerramento, a principio não existe um Web Service especifico para consultar a situação de um evento. O que você pode fazer é consultar a situação do MDF-e. Não sei lhe informar pois não fiz esse teste, mas acredito que ao realizar essa consulta, caso o MDF-e possua algum evento vinculado a ele, por exemplo de cancelamento ou encerramento, alguma informação sobre o evento vai constar nesse retorno. Faça o seguinte teste: 1. Envie dois MDF-e. 2. Cancele o primeiro 3. Encerre o segundo 4. Consulte a situação dos dois MDF-e. Anexe os XMLs do teste acima para que possamos avaliar o resultado.

Boa tarde a todos, Emerson, muito obrigado pela colaboração, mas antes de enviar para o repositório vou analisar com calma o que você fez para que não gere efeitos colaterais na versão vigente. Em uma olhada rápida acredito que será necessário alterar algumas coisas. *-*-*-*-*-*-*-*-*-*-*-*-*-*- Emerson, fiz algumas alterações e enviei para o repositório, favor atualizar os fontes e testar.

Boa tarde, Onde tem isso? Mostre a linha que tem essa função.

Boa tarde a todos, Marcos, Antes o MDF-e aceitava, NF-e ou NF (comum de papel) ou CT-e ou CT (comum de papel). Agora só aceita NF-e ou CT-e ou MDF-e (no caso de multimodal).

Boa tarde, Alem do repositório Trunk2 existe um outro chamado Branches e neste temos: C:\ACBrBranches\Projetos\ACBrNFSeMonitor\Delphi É preciso compatibiliza-lo com o Trunk2 e fazer melhorias.

Boa tarde, O XML que você anexou é o do RPS e não do envio do lote de RPS. O XML de envio de Lote contem o grupo <EnviarLoteRpsEnvio>.

Boa tarde, Simples entre em contato com a prefeitura, desta forma você vai saber se essa contadora é contadora de história ou não.

Roberto, Notei que você fez a sua implementação em fontes desatualizados. O nível de igualdade entre o provedor CTA e IssDSF é muito grande, mais de 90%. Ainda acredito que seja possível com pequenas alterações no IssDSF atender 100% o CTA. Notei que no pnfsNFSeG você duplicou o bloco de linhas do proIssDSF para o CTA e acrescentou a tag TokenEnvio. Mas essa tag não existe no Schema que você disponibilizou junto com os fontes alterados. O que precisamos saber é se para a cidade em questão o provedor IssDSF fez uma alteração no layout ou se a prefeitura comprou o Web Services e fez algumas alterações. Se foi o provedor que fez algumas alterações essa tag <TokenEnvio> podemos deixar ela como opcional, desta forma se a mesma não for preenchida não será gerada, desta forma podemos atender as duas situações.

Bom dia Roberto, Vou analisar.

Já fiz uma alteração e enviei para o repositório. Agora esse terceiro parâmetro tem um valor padrão que é uma string vazia.

Bom dia, Passe uma string vazia.

Marcio, No grupo Veic001 o campo UF segundo o seu TXT esta em branco. E a mensagem de erro diz que o tag UF esta vazia.

Boa noite a todos, Se Blumenau e São Paulo usam o Prodam, acredito que devemos alterar o nome do provedor de SP para Prodam.

Boa noite Marcio, Muito obrigado pela colaboração, ainda hoje estarei enviado para o repositório. Quanto ao provedor ISSNet o problema que seria criado um método somente para ele.

Boa noite Dimas, Desculpe a demora, alem de atualizar os fontes, é necessário reinstalar os componentes usando o ACBrInstall_Trunk2.

Boa noite Caetano, Favor anexar o XML de retorno ao realizar a consulta em uma NFS-e cancelada.

Boa noite Caejr, No caso do provedor Thema somente o Lote é assinado, os RPS não. Antes de cancelar devemos carregar o XML da NFS-e. Favor anexar os XML gerados após a execução do método Cancelar.

Boa noite Arce, Muito obrigado pela colaboração, ainda hoje vou enviar para o repositório.

Boa noite Edilson, Alem de instalar o Certificado, a cadeia de certificados da certificadora foi instalada também?

Boa noite Roberto, Eu não migrei o provedor CTA para o Trunk2 pelo simples fato de ser exatamente igual ao provedor IssDSF. Sugiro que no arquivo Cidades.INI informe como provedor: IssDSF a cidade em questão. Refaça os testes.

Boa noite Augelias, Segundo o arquivo INI do provedor temos: [Assinar] RPS=0 Lote=1 Isso significa que o XML do RPS não deve ser assinado somente o Lote. Acho que esta explicado o motivo do XML do RPS estar sem a assinatura.

Boa noite Arce, Para que a chave esteja ficando diferente, isso é porque você esta atribuindo o valor zero ao campo cCT isso faz com que toda vez que o componente for gerar o XML ele gera o código do CT-e de forma randômica. O que você tem que fazer é gerar o cCT randomicamente com até 8 dígitos. Salva essa informação com as demais no banco de dados. E quanto for alimentar o componente com os dados do CT-e atribua ao campo cCT o valor gerado. Exemplo: // // Dados de Identificação do CT-e // Ide.cUF := DM_CTA.EmpresaCodigoEstado.AsInteger; Ide.cCT := DM_CNT.ConhecimentoCTChave.AsInteger; // Código Aleatório Ide.CFOP := DM_CNT.ConhecimentoCFOP.AsInteger; Ide.natOp := 'PRESTAÇÃO DE SERVIÇO'; Isso faz com que o componente sempre gera a chave igual, para o mesmo CT-e.

Boa noite Marcio, Os dados do veículo estão incompletos. [Veic001] cInt= RENAVAM= placa=BNF-7110 tara=1200 capKG=1300 capM3=8 tpProp= tpVeic= tpRod= tpCar= UF= CNPJ= RNTRC=12345678 xNome= IE= PropUF= ProptpProp= tpProp= O que esta em negrito é o que esta faltando. O que esta em vermelho se refere ao proprietário do veiculo, caso o proprietário seja o próprio emitente do CT-e não se faz necessário informar.