italo.giurizzato.junior

Boa tarde Professor, Para muitos provedores o acesso ao site é uma coisa, já o acesso ao webservice é outra. Verifique junto ao provedor se há necessidade de efetuar um novo cadastro para utilizar o webservice.

Boa tarde Roberto, Já esta disponivel, muito obrigado pela colaboração.

Boa tarde Vinícius, Tudo o que você sabe sobre NF-e e CT-e esqueçe, não funciona para a NFS-e. Uma delas o Valida. Que na NF-e, validamos cada NF-e. Já na NFS-e o que é validado é o lote e não o RPS, logo não adianta querer gerar o XML do RPS e posteriormente validar. A validação ocorre automaticamente logo após a montagem do lote que vai ser enviado.

Rogercon, Você esta utilizando um certificado digital para assinar o CT-e e enviar para SEFAZ, correto? Esse certificado é de uma pessoa juridica? Se sim, trata-se de uma transportadora? Se sim, foi feito o credenciamento junto a SEFAZ da UF que ela é contribuinte?

Tallys, Isso não os schemas de validação e muito menos o XML de um RPS ou Lote de RPS. O que lhe passaram é o WSDL do webservice deles e pelo que pude ver esta muito estranho é totalmente diferente dos que já vi. Esse pessoal estão entendendo que se trata de NFS-e e não outra coisa? Eles sabem o que vem a ser schemas - XSD, RPS, XML, certificado digital, etc?

Bom dia Oneide, Acredito que o problema é simples de tudo. Primeiro entre em contato com o provedor Betha e solicite a eles os schemas oficiais, ou seja, o que deve ser utilizado para validar o lote quando for enviar para eles. Se com esses schemas o problema persistir, então você deve solicitar a eles que removam o "-" do numero da IM no cadastro deles. Se os schemas que hoje é disponibilizado estiver errado, por favor, post como anexo os novos que você consegui com o provedor. Por outro lado se o problema não é os schemas, você tem que resolver com eles alterando essa informação no cadastro deles.

Bom dia Luiza, Não entendi da necessidade do XSLT. Você não vai utilizar o componente ACBrCTe?

Bom dia Maciel, Dentro da pasta que contem os fontes do componente ACBrCTe, temos um arquivo TXT com um passo a passo para resolver esse problema.

Bom dia Jek, Alteração feita e disponibilizada, vamos aguardar se para as demais UF o problema se resolva desta forma também.

Bom dia Luighi, Esqueci de lhe dizer que alguns provedores não aceita o ( . ) ou seja o código do item formatado.

Bom dia Rogercon, Uma coisa não tem nada haver com outra. A propriedade tpMed se refere ao tipo de medida como por exemplo "Peso Bruto" ou "Peso Liquido", etc. logo temos que alimentar essa propriedade, caso contrario ocorre erro ao validar o XML do CT-e. O erro informando que não é possível se conectar com a SEFAZ ai já é outra história, você tem que checar se esse erro não esta sendo causado por Firewall, antivirus, proxy, ou até mesmo a falta de acesso a internet.

Bom dia Igor, O problema não esta na assinatura e sim no grupo que se refere ao protocolo de autorização do MDF-e.

Bom dia a todos, Se vocês estão utilizando o componente ACBrNFSe, não há segredo. Vocês devem montar um rotina que alimenta o componente com os dados (siga o exemplo do programa exemplo); E para enviar utilizar a rotina do botão [Gerar e Enviar Lote]. O provedor SimplISS não possui o webservice GerarNFSe, sendo assim não utilize a rotina do botão: {Gerar NFSe] Outra coisa o componente possui dos comandos para enviar um lote de RPS sendo que um deles trabalha no modo assincrono e outro no modo sincrono, o provedor SimplISS só recebe lote no modo assincrono.

Bom dia Tallys, Peça a eles um XML de RPS ou lote de RPS a ser enviado via webservice, e também os schemas - XSD usados para validar o XML antes do envio. Desta forma vamos saber se seguem o padrão ABRASF ou não.

Bom dia Jair, Pela mensagem de erro, e por se tratar de um retorno do webservice do provedor Thema, conclu-o que o problema é no provedor e não no seu sistema. Favor entrar em contato com o provedor e relatar o problema.

Bom dia Dorian, Favor atualizar os fontes dos programas exemplos. Depois abra o programa exemplo do ACBrMDFe que esta na pasta: ...\Exemplos\ACBrMDFe\Delphi Veja as rotinas dos botões: Encerramento e Cancelamento, note que são semelhantes e são eventos que são vinculados ao MDF-e.

Bom dia Binho, Quando vamos efetuar uma alteração ou implementação, devemos ter como base os Manuais e Notas Técnicas e não um exemplo de outro. Se o outro estiver errado, você vai deixar o seu errado também. Como se trata do DACTE vamos tomar como base o Manual do DACTE versão 1.00b disponivel no Portal Nacional do CT-e. Página 16, temos uma tabela dividida em 3 colunas: 1- Informações Específicas do Modal Rodoviário Lotação; 2- Tipo 3- tpVeic, em veic Com isso concluimos que devemos utilizar o conteudo da TAG tpVeic para determinar o que vai aparecer no campo Tipo, no DACTE, correto? Vamos então ao Manual do CT-e versão 1.04c que também encontra-se disponivel no Portal Nacional do CT-e. Página 129, campo #28, tpVeic - Tipo de veículo - Preencher com: 0 = Tração ou 1 = Reboque Concluimos que, deve ser impresso no DACTE é as palavras Tração ou Reboque e não Próprio ou Terceiro. Portanto a sua alteração esta errada. Volto a lhe dizer, o DACTE feito em Quick Report esta em conformidade com os Manuais, se alguem detectar algum erro favor avisar para que possamos efetuar a correção.

Boa noite Luighi, É o código do serviço que se refere a NFS-e. O seu formato é xx.xx, e o contador da empresa que vai emitir a NFS-e tem que saber esse código. Como informar, vide o programa exemplo.

Boa noite Binho, Qual DACTE você fez a alteração? Me parece que o que foi feito em Quick Report já esta em conformidade com o Manual.

Boa noite Tallys, O que eu pude ver esse provedor não segue o padrão ABRASF.

Boa noite Open Net Vamos continuar usando o seu exemplo: Carga 1,2,3,4,5 MDFE 10 é ref a carga 1,2,3 de PR - MG MDFE 11 é ref a carga 3, 4 de MG - RJ O caminhão é o mesmo que vai transportar as cargas: 1,2,3,4 e 5. Os MDFe 10 e 11 são emitidos. Quando o caminhão chegar em MG e descarregar as cargas 1, 2 e 3 o motorista deve informar a transportadora que a mesma realize o encerramento do MDFe 10. Consequentemente quando chegar no RJ e descarregar as cargas 3 e 4 a transportadora deve encerrar o MDFe 11. Vamos deixar claro que os MDFe 10 e 11 foram emitidos de uma vez, visto que ao chegar em MG e descarregar as cargas 1, 2 e 3 nenhuma outra carga vai estar dentro do caminhão que não seja a 4 e 5. Pois se outra carga for incluida o MDFe 11 não tem mais valor. Se isso ocorrer o MDFe 11 tem que ser encerrado ou cancelado e um novo ser emitido. Neste caso o DAMDFE em PDF deve ser gerado e enviado por e-mail para que seja impresso no local onde encontra-se o caminhão.

Boa tarde Turbo Drive, Utilize certificado A1, neste caso um unico certificado pode ser instalado em todos os PDV do estabelecimento comercial. Ao instalar o certificado A1 tem uma opção que faz com que ele não peça a senha toda vez que ele é utilizado.

Boa noite Gustavo, Você chegou a ver o programa exemplo?

Maravilha, continue com os testes, realizando o encerramento e o cancelamento, lembre-se que esses dois são eventos. Precisando estamos as ordens.

Boa tarde Rômulo, Vou verificar as suas alterações e subir assim que possível. Quanto ao retorno, lembre-se que o componente gera o XML do RPS e o envia para o webservice, que por sua vez processa e estando tudo OK retorna o XML da NFS-e. O componente extrai do retorno o XML e salva-o separadamente. Logo você deve sim entrar em contato com eles. Muito obrigado pela colaboração.