Italo Giurizzato Junior

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 SAOliveira, Não utilizo e não sou o responsavel pelo desenvolvimento do ACBrNFeMonitor. Pelo que seu existe um Help, você não encontrou nada nele sobre os campos do CTe?

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 Brasil, Os schemas da pasta V310 são para a versão 3.10 tanto da NF-e quanto da NFC-e. As alterações realizadas no componente para suportar essa nova versão não estão disponiveis. Portanto você deve utilizar os schemas da versão 2.00 para a NF-e e da versão 3.00 para a NFC-e. Até onde sei somente a SEFAZ do Amazonas liberou a versão 3.10 para a NFC-e mais nenhuma outra liberou. Sugestão: Não misture as versões dos schemas, ou seja, colocar em uma mesma pasta os schemas da versão 2.00, 3.00 e 3.10 procure criar uma pasta para cada versão.

Boa noite Gustavo, Quando o provedor segue o padrão ABRASF a maneira de realizar a assinatura é igual sim.

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.

Boa tarde SAOliveira, Favor alterar, em vez de: [lacRodo001] nLacre=12345 informe dessa forma: [lacre001] nLacre=12345

Boa tarde Marcio, Coloca-se no lugar do comerciante. Você realiza uma venda no valor de 90 reais o cliente quer fazer um cheque de 100 e lhe pede um troco de 10 reais, você aceitaria? Qual é a garantia que o cheque não vai voltar, por falta de fundo ou outros motivos? O cheque ao meu ver para quem recebe é um recebimento a prazo, pois tem que depositar, esperar ser compensado para o dinheiro entrar na conta, dependendo do valor demora um ou dois dias. E você vai dar o troco em dinheiro, ou seja recebe a prazo e da o troco a vista. É como o Roberto escreveu, é raro ou ninguem faz esse tipo de transação. Se você não quer engessar o seu sistema a idéia do Roberto é muito boa, criar um cadastro de formas de pagamentos com um campo indicando se permite ou não troco. O comerciante cauteloso, vai permitir troco somente quando a forma de pagamento for em dinheiro, caso contrario não.

Boa tarde Open Net, Link do Portal do MDF-e: https://mdfe-portal.sefaz.rs.gov.br/

Boa tarde sossystem, Não tenho nenhuma aplicação emitindo NFC-e apenas NF-e e CT-e, logo não tenho todas as respostas sobre essas questões. Lembre-se apenas ajudei nas alterações do componente ACBrNFe para que o mesmo também suporta-se esse modelo de documento fiscal.