Italo Giurizzato Junior

Bom dia Lucas, Vamos as regras de validação que se encontram na página 10 da NT 2020/001 versão 1.04: Se modal rodoviário e Tipo Emitente for igual a Prestador de Serviço de Transporte (tpEmit=1) ou transportador que emitirá CT-e globalizado (tpEmit=3), o grupo produto predominante deve estar informado (grupo: prodPred) Observação: regra de validação aplicável em produção a partir de 06/07/2020 [COVID-19] Acredito que a regra esteja bem clara, o grupo prodPred deve ser informado caso o tpEmit=1 ou tpEmit=3, caso contrario ele não deve constar no XML. Essa regra ficara desativada até o dia 06/07/2020, portanto independente da SEFAZ estar aplicando essa regra ou não, devemos gerar o referido grupo para os dois casos de tpEmit. Com relação ao Pagamento do Frete, você não entendeu o conceito. Se temos uma operação de transporte rodoviário de Carga Lotação, devemos além de gerar e informar o CIOT no MDF-e, também definir se o pagamento do frete vai ser a vista ou parcelado e se ele vai ser feito antes de ocorrer o transporte ou somente quando o mesmo for finalizado. Se o pagamento for feito a vista ou a prazo depois do transporte ter sido realizado não devemos gerar o MDF-e com o grupo infPag. Neste caso devemos aguardar o fim e enviar o evento. Por outro lado se o pagamento é feito a vista ou parcelado e esse pagamento vai ocorrer antes do inicio do transporte, coloco as informações sobre o pagamento no MDF-e, mais precisamente no grupo infPag e consequentemente não envio o evento. Entendeu? Resumindo se temos uma operação de transporte rodoviário de Carga Lotação, devemos informar o Pagamento, se ele vai constar no MDF-e ou vai ser enviado o evento, vai ficar a critério da negociação, ou seja, se vai pagar antes de realizar o transporte ou depois.

Bom dia Antônio, Comparando o seu XML com o que eu anexei, noite que no seu não contem a tag referente ao Integrador. A configuração que estou utilizando é:

Marcos, A sua rotina de validação, valida tanto a parte genérica quanto a especifica do evento?

Eduardo, "com o nome de UF do Destino" onde ? A única UF que aparece é UFCodigo, que ao meu ver é muito diferente de UF do Destino ou UFDestino. Veja bem como é a linha: ACBrCTe.Configuracoes.WebServices.UFCodigo Ao configurar o componente informamos a sigla da UF do emitente na propriedade de configuração UF. ACBrCTe.Configuracoes.WebServices.UF := 'SP'; // Por exemplo O componente automaticamente se encarrega de atribuir o código IBGE da UF informada a propriedade UFCodigo. Resumindo: em: ACBrCTe.Configuracoes.WebServices.UF - Informamos a sigla da UF do emitente do CT-e; em: ACBrCTe.Configuracoes.WebServices.UFCodigo - O componente se encarrega de atribuir o código IBGE da UF informada. Portanto se a UF do emitente for SP ao ler a propriedade UFCodigo teremos como resposta o valor 35. No rotina que anexei, note que coloquei 2 linhas, uma com a sigla e a outra com o código IBGE correspondente a cada sigla.

Boa tarde Marcos, Muito estranho. Você esta usando o componente ACBrMDFe, correto? Esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada? Esta enviando para o ambiente de homologação, correto?

Eduardo, Se refere a UF do emitente. Você configura o componente com a UF do emitente e nunca com a UF do destinatário. Se a transportadora é do Estado de São Paulo, ela deve enviar os seus CT-e para a SEFAZ-SP, não importa para onde vai a carga se é Minas Gerais ou Rio de Janeiro (por exemplo). Sendo assim ao configurar o componente devemos informar a UF do emitente que no exemplo acima tem que ser SP.

Boa tarde a todos, Por favor vamos seguir as regras do fórum. Não fiquem colocando "n" perguntas em uma mesma postagem. Com relação ao CEP, Latitude e Longitude da forma que esta listados os campos na NT esta confuso mesmo. O correto é: Se informar o CEP não se deve informar a Latitude o Longitude. Por outro lado se não informar o CEP deverá informar a Latitude e Longitude. O diagrama anexado pelo Lucas deixa claro isso.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Eduardo, Com relação a UF é outra coisa? Se sim, por favor vamos seguir as regras do fórum. Criar uma postagem nova para uma questão nova. Mas lembre-se sempre de pesquisar, pois a sua duvida pode já ter sido respondida.

Antônio, Acabei de realizar um teste e não ocorreu esse erro. Veja os arquivos de envio e de retorno. 20200324171258-ped-GravarProp-soap.xml 20200324171258-res-GravarProp-soap.xml

Boa tarde Robinho, Muito obrigado pela informação, já incluímos em nosso fórum de noticias.

Olá Pessoal, Foi publicado ontem (23/03/2020) a resolução 5.876 em anexo: RESOLUCAƒO N. 5.876, DE 20 DE MARC‡O DE 2020.pdf Resumo: 1. Prorrogar, até 31 de julho de 2020, a validade dos certificados do Registro Nacional de Transportadores Rodoviários de Cargas - RNTRC; 2. Suspender, até 31 de julho de 2020, a aplicação da alínea "d" do inciso I do artigo 6º (relação de veículos, devidamente cadastrados na frota da ETC junto ao RNTRC, acompanhada dos respectivos Certificados de Inspeção Técnica Veicular Periódica - CITV); da alínea "e" do inciso II do artigo 6º (relação de veículos, devidamente cadastrados na frota da ETC junto o RNTRC, acompanhada dos respectivos Certificados de Inspeção Técnica Veicular Periódica - CITV); do inciso V do §2º do artigo 16 ( cópia do Certificado de Inspeção Técnica Veicular Periódica - CITV); do inciso IV do §2º do artigo 19 ( cópias do CITV´s); e a exigência de Certificado de Inspeção Técnica Veicular - CITV; 3. Suspender, até ulterior Deliberação da ANTT, as obrigações e penalidades relacionadas ao cadastramento da Operação de Transporte, com a consequente geração do CIOT, para as contratações que não envolverem TAC e TAC-Equiparado.

Boa tarde Antônio, Você esta enviando para o ambiente de produção ou homologação? O componente esta configurado com o certificado digital? Se sim, ele não esta vencido?

Boa tarde Antônio, Favor atualizar os fontes, pois fiz a alteração para compatibilizar com versões antigas do Delphi no dia 18/03/2020 18/03/2020 Compatibilização do programa exemplos com versões mais antigas do Delphi. Por: Italo Jurisato Junior

Bom dia Antônio, Você anexou o XML de envio e não o de retorno.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Claudio, Esse envio via XML, como é que funciona? Devemos gerar o XML e través do site carregar ele? Ou devemos enviar esse XML para o webservice do empresa (provedor) contratada pela prefeitura? Esse XML segue o layout da ABRASF, se sim, qual versão? Ou se trata de um layout próprio?

Bom dia Walison, Desculpe pela demora, favor atualizar os fontes e faça novos testes. Criei os seguintes campos para serem usados na versão 2: ValorFECP, TotalFECP, MultaICMS, MultaFECP, JurosICMS, JurosFECP, AtualMonetICMS e AtualMonetFECP.

Bom dia a todos, Através das URLs que o Renato postou acima, cheguei a conclusão que a cidade de Ponta Porâ/MS não utiliza mais o provedor ISSNet e sim um outro provedor que vamos chamar de PortalInteg2. O provedor ISSNet segue a versão 1 do layout da ABRASF, já analisando os serviços disponibilizados no webservice do PortalInteg2 se referem a versão 2 do layout da ABRASF. Sendo assim vai ser necessário implementar um novo provedor que podemos chamar de PortalInteg2 ou PortalIntegv2, criar um arquivo INI para ele, e alterar o arquivo Cidades.ini, mais precisamente o provedor que atende a cidade de Ponta Porâ/MS.

Bom dia Flávio, Pra que facilitar se pode complicar. Essas adaptações são melhorias no código? Se sim, porque não anexa a unit que foi alterada para que possamos analisar e quem sabe envia-la para o repositório, assim todos saem ganhando. Observação: o XML que você anexou se refere ao MDF-e e não ao evento que ocorreu erro de validação. Pela mensagem de erro me recordo que o componente possuía um bug, mas já deve ter sido corrigido.

Bom dia Gustavo, Já chegou a conversar com algum contador?

Bom dia Pessoal, Foi publicado a versão 1.04 da Nota Técnica 2020/001 - MDF-e Integrado. A única alteração se refere a duas regras de validação que tiveram as suas datas de ativação postergadas. Abaixo as regras: Resumo: v1.04 - Adiamento para 06/07/2020 das RV´s 725 e 726 em produção em virtude do COVID-19. Schema e evento de pagamento (opcionais) entram na data original da NT 06/04/2020

Bom dia Pessoal, Quanto a informação acima a SEFAZ-RS acrescentou uma observação. OBSERVAÇÃO: O serviço está disponível nessa etapa para CT-e das UF´s autorizadas pela SVRS.