Italo Giurizzato Junior

Boa tarde a todos, Cristiano, o CTeDistribuicaoDFe funciona de forma idêntica ao NFeDistribuicaoDFe. Me parece que esse serviço já era para estar disponível a quase 1 ano mas a SEFAZ liberou a Nota Técnica e os Schemas em dezembro/2016. Galebobr, já inclui o evento. Favor atualizar os fontes e iniciar os testes.

Boa tarde GalegoBR, Muito obrigado pela correção, já esta no repositório.

Boa tarde Wemerson, Na configuração do Internet Explorer, você desmarcou as opções de revogação de certificados?

Boa tarde Saulo, Lembre-se que o Encerramento e o Cancelamento são eventos e não existe nenhum Web Service para consultar a situação de um evento enviado. O que existe é um Web Service para consultar a situação de um MDF-e enviado. O que você pode fazer é realizar essa consulta e analisar o XML de retorno, para ver se neste consta alem da situação do MDF-e mais os eventos vinculados ao mesmo.

Boa tarde a todos, Transferi o tipo de navegação as funções de conversão e constantes para as Units do pcnComum, pois os mesmos são utilizados tanto pelo CT-e quanto pelo MDF-e. Hugo, favor atualizar os fontes e fazer novos testes. Muito obrigado pela colaboração.

Boa noite Jair, Vou analisar a rotina para tentar descobrir o que esta ocorrendo com o provedor DBSeller.

Boa noite, Realmente esta faltando a TAG <cteDadosMsg> mas você colocou no lugar errado. Favor atualizar os fontes e realizar novos testes.

Boa noite, Primeiramente, todos os fontes de todas as pastas estão atualizados? Se sim, veja este exemplo: Imp.infTribFed.vPIS := 15.00;

Boa noite Leonardo, Status 999 é erro no Web Services da SEFAZ. Não tem o que fazer, apenas esperar eles corrigirem o problema.

Boa noite a todos, Um CT-e só pode ter 2 ou mais NF-e quando estas tenham si emitidas pelo mesmo remente e cujo destinatário é o mesmo. Caso contrario é um CT-e para cada NF-e. Por outro lado se a transportadora tiver a autorização de emitir CT-e Globalizado, o mesmo poderá ter várias NF-e, mas todas tem que ter sido emitidas pelo mesmo Remetente ou todas são para o mesmo Destinatário.

Boa noite Felipe, Para emitir um CT-e é preciso informar pelo menos um documento originário. Esse documento originário pode ser a chave de uma NF-e ou os dados de uma NF comum (papel) ou os dados de uma Declaração. Se o remente da carga é obrigado a emitir NF-e devemos informar a chave, caso contrario o CT-e será rejeitado. Se a SEFAZ não realizar essa rejeição, abra-se uma brecha para que o emitente da NF-e possa cancelar a mesma. Peça ao seu cliente que mostre como ele emitia um CT-e sem informar a chave da nota, com certeza ele deve informar como sendo uma declaração.

Boa noite Marina, Se o responsável pelo Seguro for 2 - Responsável pela contratação do serviço de transporte (contratante) será necessário informar o CNPJ ou CPF do Responsável pelo seguro.

Boa tarde a todos, Até tem um tal de TesteEnvioLoteRPS, mas o componente não o utiliza, mesmo configurado como homologação.

Boa tarde Jair, Favor anexar os XML gerados ao tentar enviar o lote de RPS.

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.