Italo Giurizzato Junior

Boa tarde Michel,
 
Muito obrigado pela colaboração.
 
Já esta disponível as alterações.

Boa tarde Emerson,
 
Você encontra essa lista completa nos manuais e notas técnicas disponibilizadas pelos Portais Nacionais da NF-e e CT-e.

Bom dia José Geraldo,
 
Pelo histórico que temos no fórum sobre a SEFAZ-MG, acredito eu que o problema seja mesmo na SEFAZ.

Boa noite José,
 
Segundo a NT 2013/013 página 76 temos:
 
Futuros eventos diferentes de EPEC (Ex: Registro de Passagem, Carta de Correção, etc) não serão aceitos na SVC, portanto a UF desses tipos de evento deverão ser atendidas pela SEFAZ em modo de autorização normal.   As regras que irão determinar quando um evento será aceito por determinado ambiente de autorização (Normal / SVC) serão especificadas em cada evento.

Boa tarde Tagales,
 
Primeiramente se consta no site da SEFAZ que existe um evento de CC-e, quem poderia duvidar se é legal ou não?
 
Outra coisa, quando você envia um evento, o mesmo é enviado para a SEFAZ autorizadora do Emitente, no caso a SEFAZ-SP, esta por sua vez fica responsável por enviar para o Portal Nacional da NF-e.
 
Ocorre que isso não é automático, podendo levar minutos ou até horas.

Boa tarde Maikon,
 
Já faz um bom tempo que fizemos uma alteração no componente migrando a cidade de Mirassol/SP do provedor GovBR para Pronim.
 
Certifique-se se todos os fontes estão atualizados e se utilize dos Schemas que encontra-se na pasta Pronim para realizar a validação do lote de RPS.

Bom dia a todos,
 
Vejam bem uma coisa é o site da SEFAZ que ainda não esta preparado para apresentar os eventos vinculados ao documento fiscal no caso o CT-e.
 
Ao consultar a situação atual deve constar que o CT-e esta autorizado, o grupo procCTe constando todo o retorno com o protocolo de autorização da SEFAZ, mais os eventos vinculados ao CT-e em questão.
 
Neste caso tem que aparecer a CC-e.
 
Com o advento da CC-e, Cancelamento por evento o XML do CT-e "original", ou seja, com o protocolo de autorização, não deve ser mais alterado.
 
Devemos enviar ao tomador do serviço o XML contendo o evento enviado a SEFAZ, juntamente com o protocolo acusando a sua vinculação ao CT-e.

Walter,
 
O problema deve ser da forma que você esta alimentando o componente.
 
Para que seja somando devemos fazer:
 
           Prod.IndTot    := itSomaTotalNFe;
 
para não somar:
 
          Prod.IndTot := itNaoSomaTotalNFe;
 

Boa tarde Anderson,
 
Abra o Arquivo ACBr.inc e comente a definição da diretiva PL_200 e descomente a PL_104.

Boa tarde Fernando,
 
Sim, basta você alterar uma propriedade ( de zero para um ) da linha que gera essa tag isso faz com que o componente entenda que a tag é obrigatória não importando o seu valor.
 
A unit responsavel por gerar o XML é pncNFeW.pas
 
Segundo a Nota Técnica 2013/003 que trata sobre a Lei da Transparencia, temos no final da página 4 a regra de validação executada pela SEFAZ:
 
O campo “vTotTrib” é opcional para o Item e para o grupo de Totais. Considerar valor=0, se não informado.
 
O seu cliente tem o direito de achar até pelo em ovo, mas a SEFAZ considera o vTotTrib igual a zero se não informado.

Bom dia HetoAndrade,
 
O componente ACBrNFe possui duas propriedades para determinar o modelo e a versão do documento fiscal, são elas:
 
ModeloDF := moNFe ou moNFCe;
 
VersaoDF := ve200 (só para moNFe) ou ve300 (só para moNFCe) ou ve310 (ambos os modelos);
 
No caso da NF-e versão 3.10 não foi liberado ainda as URLs de hologação e produção das UF: AM, CE e MG, as UF: MS e PR só não foi liberado as de produção, as demais UF já estão liberadas.
 
As URLs liberadas já fazem parte do código do componente, basta atualizar os fontes.
 
Quanto a NFC-e não temos todas as URLs das UFs do projeto piloto, caso você venha conseguir, favor nos informar para que possamos atualizar o componente.
 
No fragmento de XML que você postou note o seguinte, temos duas TAGs, uma chamada versao cujo valor é 3.10 e a outra chamada verAplic cujo valor é 3.00
 
Lembre-se a TAG verAplic se refere a versão da Aplicação da SEFAZ, a sua aplicação pode estar na versão 1.59, mas emiti NF-e na versão 3.10.
 
Temos que nos basear na TAG versao esta sim contem a versão do XML e nela consta o valor 3.10.
 
Como o fragmento de XML postado se trata do retorno a uma consulta ao status de serviço, podemos concluir que o ambiente de homologação da UF (código 51) esta funcionando para a versão 3.10
 
Não sei se ficou claro.

Bom dia Rafael,
 
Você deve estar executando um LoadFromFile antes do Imprimir, isso faz com que ele carrego para o componente mais uma vez o CT-e.
 
Deve-se executar um Clear antes de executar um LoadFromFile.

Boa tarde Hasa,
 
Eu não participei no desenvolvimento do ACBrNFeMonitor, para que eu possa realizar uma alteração no mesmo, preciso estudar e compreender todo o seu código fonte.
 
E isso demanda tempo.
 
A minha sugestão é você mandar uma MP - Mensagem Privada ao André, Daniel e Isaque.
 
Se não me falha a memória são eles que desenvolveram e realizam as devidas alterações e correções no ACBrNFeMonitor.

Bom dia Edson,
 
O componente segue o que esta estabelecido no manual.
 
A SEFAZ ao retornar o resultado de uma consulta sobre a situação atual de uma NF-e, a estrura do XML retornado é:
 
Informações sobre a autorização da NF-e;
Lista de eventos (se houver) vinculados a NF-e;
 
Por outro lado quando você enviou uma carta de correção, o componente salvou um XML contendo os dados de envio e o retorno da SEFAZ acusando a vinculação deste evento a NF-e em questão.
 
E ao enviar uma solicitação de cancelamento para a mesma NF-e, o componente salvou um outro XML contendo os dados de envio e o retorno da SEFAZ acusando a vinculação deste evento a NF-e em questão.
 
Portanto você tem os XMLs de cada evento separadamente.
 
Para a SEFAZ, quando solicitamos uma consulta, ela entende que queremos um histórico completo referente a NF-e consultada, ou seja, a sua autorização e a lista de eventos caso existam.
 
Mas nada lhe impede de desenvolver uma rotina própria para extrair desse retorno somente o que deseja.

Igor,
 
Da mesma forma que a sua aplicação defini qual será o numero do CT-e ( TAG nCT ) ela deve também definir o código aleatório ( TAG cCT ).
 
Ambos, numero e código devem ser armazenados no registro juntamente com os demais dados do CT-e no banco de dados.
 
Por outro lado o LoadFromFile que utilizamos para carregar para o componente o conteudo de um XML, possui dois parametros.
 
Sendo que o segundo é um valor booleano, cujo padrão é True, isso diz ao componente para que ele gere novamente o XML.
 
Se você executar desta forma: LoadFormFile( sArquivo, False );
 
O XML vai ser lido e nada vai ser gerado, portanto a chave do CT-e lido não corre o risco de ser alterada.

Boa tarde Elvis,
 
E os schemas, estão atualizados?
 
Você esta usando os schemas do pacote PL_CTe_200a_NT2013_013.zip que esta dentro da pasta: ...\Exemplos\ACBrCTe\Delphi\Schemas\V200 ?

Boa tarde HetoAndrade,
 
Na estrutura do XML da NF-e que é exatamente a mesma usada pela NFC-e, não existe nenhuma TAG para informar o valor do Troco.
 
Sendo assim, você pode incluir no XML no campo observação ou não incluir em lugar algum, apenas imprimir no DANFE.

Boa tarde a todos,
 
Favor atualizar os fontes.
 
Fiz um merge usando as units postadas pelo Paulo Henrique.
 
Fico no aguardo de um retorno.

Bom dia Jonas,
 
Muito obrigado pela colaboração, ainda hoje estarei disponibilizando.

Bom dia ta4e,
 
A cidade do Remetente da carga é a mesma onde encontra-se o depósito da transportadora?
 
Se sim, não há necessidade de emitir um CT-e para realizar a coleta, ou seja, transportar a carga do remetente até a transportadora.
 
Caso contrario deve-se emitir um CT-e como lotação uma vez que toda a carga do caminhão vai do Remente até a transportadora.
 
A transportadora neste caso seria o Destinatário.
 
Quando a entrega efetiva feita com os caminhões menores, com certeza teremos cargas destinadas a destinatários diferentes, correto?
 
As cidades dos Destinatários é a mesma onde encontra-se a transportadora?
 
Se sim, a transportadora deve emitir uma Nota Fiscal de Serviço e não um Conhecimento de Transporte de Carga, sendo este último destinado a acobertar o transporte intermunicipal e interestadual.
 
No caso de emissão do CT-e, é necessário emitir um para cada destinatário, não importa que o remetente seja o mesmo.
 
A não ser que você tenha uma autorização expedida pela SEFAZ informado que você possui um Regime Especial, que lhe permite a emissão de CT-e Globalizado.
 
Para saber mais sobre este tipo de CT-e, por favor pesquise no fórum, você vai encontrar outras postagens sobre o assunto, bem como um Boletim Técnico emitido pela SEFAZ esplicando como emitir corretamente um CT-e Globalizado.
 
Espero ter ajudado.

Bom dia Marcelo,
 
Por favor atualize os fontes novamente, pois hoje fiz algumas alterações e o seu problema pode estar resolvido.
 
Caso contrario favor postar como anexo um XML da NFS-e para que eu possa testar e efetuar as correções?

Bom dia Rodrigo,
 
Com o advento do envio Sincrono, foi dito que não teriamos mais o recibo como retorno, somente o protocolo de autorização.
 
Mas, andei notando que no -pro-rec.xml que é o retorno do processamento esta sendo retornado sim o numero do recibo.
 
Não sei lhe informar se todas as SEFAZ, vão disponibilizar o numero do recibo junto com o protocolo de autorização ao realizar um envio no modo Sincrono.

Bom dia a todos,
 
Com certeza estão mexendo.
 
A SEFAZ-SP por exemplo agora possui 2 conjuntos de URLs, uma para versão 2.00 e outra para a 3.10, tanto para o ambiente de homologação quanto o de produção.

Boa noite Cezar,
 
Da forma que você esta obtendo o numero do protocolo: WebServices.Retorno.Protocolo
 
Só funciona se o lote tiver apenas 1 CT-e.
 
Aconselho você obter o numero do protocolo de forma diferente.
 
Estude o arquivo exemplo: EnviarLote.txt que encontra-se dentro da pasta: ...\Exemplos\ACBrCTe, mais precisamente o código após a linha 45.
 
Note que é executado uma consulta se utilizando do numero do recibo.

Boa noite HetoAndrade,
 
A CC-e foi disponibilizada na versão 2.00 do CT-e.
 
Me parece que da até para emitir uma CC-e na versão 2.00 para corrigir um CT-e da versão 1.04, nunca realizei esse teste.
 
Quanto a alimentar os campos, os seus exemplos estão corretos.