Painel de líderes

Boa tarde, pessoal! Sei que aqui existem posts sobre o assunto, porém, estou com umas dúvidas de entendimento. Então, resolvi compartilhar com vocês, pois podem existir pessoas com as mesmas dúvidas que eu. Já revirei na internet sobre estes assuntos (ICMS / DIFAL / FCP / CEST / NCM) e estudei bastante sobre eles, porém, foram surgindo dúvidas. Após vários estudos, as minhas conclusões foram: ICMS: - O Diferencial de Alíquota (DIFAL) foi incluído na nova regra do ICMS; - A porcentagem do Fundo de Combate à Pobreza (FCP) vai variar de acordo com cada Estado e, que para isso, temos que consultar as leis de cada um para poder, finalmente, realizar os devidos cálculos; - A base de cálculo do ICMS será a base simples (pois a Nota Técnica 2015.003 v1.50 retira a tabela da sistemática de cálculo de base dupla); - É preciso observar as alíquotas internas e alíquotas interestaduais para operações interestaduais (ex: venda de SP para SC); - Haverá a partilha do ICMS para as UFs Origem e Destino, seguindo a tabela; - As empresas remetentes devem informar, no campo de “Informações Complementares”, os valores descritos no grupo de tributação do ICMS para a UF de destino, conforme escrito na Nota Técnica 2015.003 v1.60. CEST / NCM: - 1 CEST pode possuir 1 ou mais NCMs; - 1 NCM pode possuir 1 ou mais CESTs; - A partir do dia 01/04/2016, o CEST será obrigatório na NF-e; Dúvida: Existe alguma tabela atualizada e oficial com estes dois campos, e suas descrições? Gostaria de pedir para alguém que já esteja bastante interado sobre o assunto avaliar minhas conclusões. Observação: Tudo o que eu pesquiso leva à legislação (leis estaduais/federais), porém, sou extremamente leiga e não tenho paciência nenhuma de ler sobre estas leis e decretos. Sou Bacharel em Ciência da Computação, e trabalho em uma empresa de TI. Espero que alguém me ajude! Estou um pouco "desesperada" com isso haha. Obrigada, desde já!

Fiz teste no XE7, e não notei problemas no envio... o XML está sendo convertido para UTF8 corretamente... E obtive com sucesso a resposta do WebService... Entretanto encontrei problemas no método: "TDFeWebService.SalvarEnvio", que erroneamente presumia, que o XML a ser enviado sempre estava em UTF8, e isso somente será verdade, se o XML já passou pelo processo de assinatura... Enviei a seguinte correção para o SVN: -- ACBrDFeWebService -- [-] Método: "SalvarEnvio", correção para conversão de XML para UTF8, quando o mesmo não foi previamente assinado (por: DSA) Verifique: - Se seus fontes do ACBr estão corretamente atualizados... - Se os seus Schemas estão atualizados...

Juliana, obrigada por toda atenção. Eu deinstalei o AcbrMonitor e baixei novamente. Assim funcionou corretamente.

@Juliomar Marchetti Pode fechar o tópico, tudo resolvido, mais uma vez muito obrigado pela atenção e solução. vlw mesmo !!!!

Bom dia! não esses não .. mas caso use os componentes do delphi sim!

Existe um post falando sobre isso, ao que parece eles estão em manutenção sem data de retorno definida.

Vou tentar Juliano, Sou bem novato com o ACBr, na verdade mudei todo meu ERP para o ACBr há apenas 2 semanas. Se conseguir algo compartilharei com todos. Obrigado.

Agora não estamos mais falando do nome da prefeitura? sim pode estar pois tem um tamanho limitado ou é pequeno o campo no clientdataset

Bom dia favor atualizar o svn recompilar e testar!

claro pah, pelo devido retorno monetario qq coisa se faz na programação (menos mulheres, tentei e não consegui pk vinha sempre com bug)

Bom dia! Achei estranho que utilizando o DistribuicaoDFe o evente de CCe é retornado corretamente. Sendo assim toda NFe que o DistribuicaoDFe retornar eu devo utilizar o ConsultaNFeDest também? Porque fica estranho o meu cliente ver uma NFe emitida para ele e só depois que for feito a manifestação ele ficar sabendo que a NFe já está cancelada. @Tiago Ravache, eu salvo os xml na sim, fica os chave-nfe.xml e chave-resnfe.xml e não consta nada do evento de cancelamento.

Eu acho que a versão em fortes está com problema ! precisa de correção! se quiser contribuir por favor fique a vontade

Bom dia Paulo, A TAG que contem o valor do funco de combate a pobreza fica dentro do grupo ICMSUFDest que só pode ser gerado quando a venda for interestadual e a consumidor final. Essa informação consta na Nota Técnica que trata sobre o assunto. Sendo assim ou esse contador só sabe contar até 10 ou a SEFAZ de MG mudou as regras mas não alterou o Web Services para aceitar a nota.

Bom dia Italo... aumentei pra 100.000 e não resolveu... vou ir voltando as versões do componente pelo tortoise pra saber a partir de qual commit começou esse problema pra ver se dá alguma pista. sds, Leandro

Pra falar bem a verdade eu não uso a impressão ... Pego o arquivo de pagamento (retorno) e submeto ao software do banco do brasil (a empresa tem conta) paga realizar o pagamento em lote e de forma automatizada ... O próprio software do banco do Brasil faz a impressão com a autenticação. Mas acho que tem o relatório em dois tipos via Fortes e Fast ...

Juliomar, Opa, acompanho o trabalho da equipe do ACBr, estou usando desde 2005 e sou muito grato pelo esforço deles, e sempre que posso tento contribuir da melhor forma possível.Quanto ao projeto de atualização automática, ele já existe e está funcionando em nosso ERP, porém o código está em nosso repositório privado, em breve nossa equipe escolherá uma licença para então podermos publicá-lo.

Boa tarde, estava com o mesmo problema usando uma Daruma (DR800). Solucionamos o problema limitando o Tamanho da página do Fortes Report (Provavelmente os drivers possuem um limite desse tamanho). - Ao executar a função "CalcularTamanhoDaPagina" ele resultava um valor superior a 4000. Limitando esse valor a 3276, a impressão sai corretamente, sem cortar o QRCode. Segue a unit em anexo para análise. Att, Evandro ACBrSATExtratoFortesFr.pas

Vlw, Italo! Agora está tudo ok! Obrigado e Deus te abençoe.

anexe o xml

Boa tarde Caetano, Tente: ACBrNFSe.WebServices.ConsLote.NFSeRetorno.XML_NFSe

Ola Cristiano, muito obrigado pelo retorno. Fiz o contato com a sefaz, conforme informado e realmente as informações como Razão, endereço ... ficam armazenados em base de dados no (CADESP). Segue a baixo email da sefaz. ------- Resposta da Mensagem 6888272 Prezado Fernando, Os dados a seguir são preenchidos automaticamente pelo equipamento, com base nas informações do CADESP: · Razão social · Nome Fantasia · Endereço completo · Regime Tributário A alteração desses dados deve ser feita no CADESP. Alguns dias depois os novos dados são enviados automaticamente ao equipamento SAT quando este for conectado à internet. Caso os dados não sejam alterados, verifique se os dados foram alterados no CADESP. Se estiverem corretos no CADESP verifique se o SAT está conectado à internet e se os equipamentos de borda entre a rede local e a Internet permitem a livre comunicação com: · Qualquer endereço pertencente ao domínio "fazenda.sp.gov.br" na porta HTTPS (TCP-443); · Qualquer endereço pertencente ao domínio "rnp.br" e "ntp.br" na porta NTP (UDP-123). Entende-se por equipamentos de bordas os firewalls, roteadores, Proxys, UTM, IPS, ou qualquer outro dispositivo que implemente o conceito de filtro de pacotes e que possam impedir tais comunicações. Caso a comunicação com a Sefaz estiver regular, o contribuinte pode efetuar um bloqueio do SAT e posteriormente um desbloqueio do equipamento. Quando o contribuinte bloqueia o SAT, o equipamento busca um arquivo de parametrização de bloqueio no sistema da Sefaz. Ao efetuar o desbloqueio, o SAT busca um arquivo de parametrização de uso no sistema. Em tese, isso fará com que os dados cadastrais sejam atualizados no SAT. Para mais informações sobre o bloqueio: http://www.fazenda.sp.gov.br/guia/sat/bloqueio.shtm Para mais informações sobre o desbloqueio: http://www.fazenda.sp.gov.br/guia/sat/desbloqueio.shtm Caso o problema persistir envie pelo Fale Conosco: · CNPJ do contribuinte; · Número de Série do SAT com o dado desatualizado; · A informação de que o(s) dado(s) foi/foram atualizado(s) no CADESP e a data dessa alteração. Atenciosamente, Secretaria da Fazenda do Estado de São Paulo Obrigado pela atenção.

Boa noite! correção no svn! favor testar obrigado

Boa tarde Paulo, O Fortes Report é Free e o ACBr possui componentes para imprimir o DANFE da NF-e e NFC-e usando esse Report.

Bom dia Maurício, Infelizmente as empresas que implementaram os web services para recepcionar as notas de serviço para as prefeituras não seguem um mesmo layout. Algumas seguem a versão 1 do layout proposto pela ABRASF, outras seguem a versão 2, outras resolveram acrescentar ou remover algo desses layouts e por fim existem as empresas que não seguem nenhum dos dois. Essas empresas chamamos de provedor, sendo assim os que seguem a versão 1 temos o seguinte: Ao enviar o lote de RPS temos como resposta apenas o numero do protocolo que nada mais é o numero do recibo quando enviamos o lote de NF-e (fazendo uma comparação). Depois temos que consultar a situação do lote, que nos retorna se o mesmo foi recebido, se ainda esta em processamento, se foi processado com erros ou se foi processado com sucesso ( Situação: 1, 2, 3 ou 4). Caso a resposta seja 3 ou 4 devemos consultar o lote, se a situação for 3 será retornado a lista de erros, as rejeições, por outro lado se a situação for 4 teremos como resposta o XML da NFS-e. Já os provedores que seguem a versão 2 do layout não existe a consulta a situação do lote, ou seja, o lote é enviado e depois realizamos a consulta ao lote. Outra coisa, o componente possui 3 métodos de envio: Enviar, Gerar e EnviarSincrono. Existem provedores que implementaram apenas um deles, por exemplo o Enviar, outros provedores implementaram o Enviar e o Gerar e outros implementaram os 3. E para mostrar a falta de padronização tem provedor que simplesmente implementou o método Gerar e Cancelar. Neste caso o envio tem que ser unitário, ou seja, só podemos enviar apenas um RPS por vez, e o retorno do Gerar, temos como resposta o XML da NFS-e caso o processamento tenha ocorrido com sucesso ou temos a lista de erros caso tenha ocorrido falhas.

Boa tarde Akai, Esses caras são doentes, que coisa mais em noção. Enquanto muitos se esforçam em padronizar, sempre tem um que bebe gasolina, viaja na maionese e faz uma coisa dessa. Lamentável. No trunk2 todos os DF-e se utilizam de uma mesma rotina para realizar a assinatura. Sendo assim esse tipo de assinatura esta fora, portanto esta fora também esse provedor.

Bom dia Hercules, Lembre-se que no caso da NFC-e quando enviamos um lote com apenas uma NFC-e a conexão é síncrona, ou seja, o retorno após o envio já é o protocolo de autorização ou a rejeição. Quando enviamos um lote com 2 ou mais NFC-e a conexão é assíncrono, ou seja, o retorno após o envio é o numero do recibo, que utilizamos para realizar a consulta, o retorno desta consulta temos o protocolo de autorização ou a rejeição.