Wess

Bom dia Sergio, o interessante é você consultar um analista contábil pra te ajudar nesse quesito, ele saberá (ou ao menos deveria) responder todos seus questionamentos acerca do assunto com maior exatidão. Há várias regras e situações diferentes para cada empresa, então fica complicado lhe passar como são feitos os cálculos sendo que pode resultar em problemas futuros, ao menos em minha opinião, não é mesmo? Abraço

Atualizamos em nossos clientes e começou a ocorrer em MS também

Mesmo problema em PE, apenas em homologação pelo visto. Vale lembrar que utiliza o servidor do RS lá.

Bom dia, estive passando pelo mesmo erro mas resolvi atualizando TODAS as DLLs do diretório do Integrador em %APPDATA% e utilizando o Integrador 1.6.86. Veja se isso não irá resolver pra você caso ainda não tenha resolvido. Lembrando que pode ser necessário desbloquear a dll para correto funcionamento.

Boa tarde Italo, acredito que o que nosso colega tentou nos passar é que a propriedade IntegralHeight já vem setada como True, e dessa forma a impressão ficava como nas duas primeiras imagens, após setar para False, tal questão foi resolvida. Então presumo que a sugestão seria que essa propriedade viesse de padrão como False, correto? Desculpe-me a intromissão, mas acredito que seja esse o caso.

Bom dia prezados, segue anexo do ACBrNFeServicos.ini com alteração na URL de consulta 2.0 para PB_H, conforme especificado em: URLs consulta ENCAT Aproveitando (acredito estar no mesmo assunto ainda), percebi que nenhuma consulta funciona, ao menos em homologação para PB, nas URLS disponibilizadas pelo ENCAT, e quando consultado o QR Code, apenas direciona para a URL precisando digitar a chave de acesso, e por fim continua retornando "Nenhum registro satisfaz a pesquisa". Alguém mais com esse problema? Grato desde já. ACBrNFeServicos.ini

Concordo que varia de homologador pra homologador apesar da clareza de alguns requisitos, inclusive aconteceu conosco na última homologação. Infelizmente há usuários que optam por emitir tudo em contingência e não se preocupam com as consequências futuras, é uma realidade na qual acredito que o trabalho que podemos fazer é basicamente de orientação, e lógico, não desenvolvendo ferramentas que facilitem tal prática. O ideal para tentar resolver da sonegação, ao meu ver, seria ter que enviar por exemplo, o CNPJ da SH, CNPJ do contribuinte, e CNPJ da contabilidade, ou seja, digamos que sejam detectadas inconsistências em um dos usuários no sentido de sonegação ou algo assim, seria fácil para analisar os contribuintes de determinada SH com possíveis problemas, como o ocorrido há poucos anos com aquela empresa que tinha uma tecla para emitir cupom "frio", onde começa descobrindo em um usuário, porém provavelmente vários outros usuários deviam utilizar desse recurso. Não digo que essa questão iria resolver a sonegação propriamente, mas vejo que seria uma forma efetiva de "punição". Em relação à homologação, comentei pelo fato de que há inúmeros sistemas sem critério nenhum, que simplesmente emitem o cupom e não seguem um padrão, que querendo ou não, acabam prostituindo o mercado e gerando em alguns casos até concorrência desleal, mas com certeza algo que não seja tão "louco" como o credenciamento do PAF, que tem alguns requisitos sem nexo.

Finalmente algum anúncio relacionado, entretanto recuso-me a acreditar que poderão exigir um equipamento específico para transmissão, apoiaria totalmente algum tipo de processo de "homologação", como o que já existe hoje pro PAF, mas burocratizar com outro equipamento (certamente custando um olho da cara) é o fim...

O provedor de Concórdia é o IPM, se não me engano há poucos meses atrás um pessoal de Santa Catarina implementou o provedor IPM no ACBrNFSe, como desenvolvemos uma solução própria aqui na empresa, não sei lhe informar em termos de funcionalidade, mas aparenta estar funcionando corretamente apesar de não seguir padrão ABRASF.

@Suporte Acodi Bom dia, como agora é um url na web e não mais um executável que precisa ser enviado pro dropbox, vou postar por aqui mesmo para outras pessoas já utilizarem caso necessário... http://simuladorposceara.azurewebsites.net/ O funcionamento é igual ao simulador anterior.

Boa tarde @João Paulo Alcântara, primeiro você gera o XML da venda, exatamente como é no SAT, depois você vê se o pagamento é TEF/POS e manda os comandos de acordo com o que tá no Demo do ACBrSAT, os comandos variam se for TEF ou POS, após retornar o status do pagamento como sucesso, você envia a venda, e se a venda for enviada com sucesso fosse envia a resposta fiscal do pagamento. Consulte o Demo do ACBrSAT na aba do MF-e, tem um botão pra cada comando que deve ser enviado, pra entender a ordem de envio como disse anteriormente tem no manual, é só dar um Ctrl+F pela palavra "fluxo". Não to com nenhum XML do pagamento mas no manual tem também o exemplo.

Recomendo a leitura integral do manual: http://www.sefaz.ce.gov.br/content/aplicacao/internet/CFe/arquivos/manual_de_utilizacao_integrador_fiscal_14.pdf Algumas dúvidas já podem ser tiradas ali mesmo, como nosso colega comentou, a principal diferença está em operações TEF e POS, que passam pelo integrador também, e com POS tudo passa pelo servidor da SEFAZ enviando e retornando status dos pagamentos. De resto é só configurar igual o SAT selecionando o modelo "mfe_Integrador_XML" que o ACBrSAT faz o resto pra você.

Acostume-se, webservice do Bloco X funciona quando quer... Eles estão em constante mudança.

está com schemas atualizado e setado no componente pra versão 3.0?

A princípio só falta informar o grupo <ICMSUFDest> por se tratar de operações interestaduais com não contribuinte do ICMS.

Configure ACBrCTe1.Configuracoes.Geral.ModeloDF := moCTeOS; ACBrCTe1.Configuracoes.Geral.VersaoDF := ve300; Provavelmente resolverá

@tbalbinos Aqui mandando por compl.xOBS saiu normal, como na print; @LeonardoZanella Até onde sei não tem CST 20 para CT-e OS, ao menos de acordo com o manual...

Bom dia, até onde eu saiba não, acredito que o pensamento deles é justamente esse, o contribuinte guardar seus próprios XMLs, sei que é um caso especial esse, porém é a visão do fisco. O sistema não possui uma rotina pra gravação do XML no bd? Eu recomendaria a criação.

Show, depois que passamos na homologação não acessei mais nenhum portal relacionado ao PAF, comentei apenas baseado no que o nosso homologador havia passado.

Em relação a todos esses problemas de enviar hoje, e amanhã fosse tentar novamente começar a dar erro já é normal, em nossa homologação a transmissão nem foi cobrada, simplesmente por não funcionar. Por isso acho interessante conversar com seu homologador caso tenha a homologação marcada para logo, e foque em outros detalhes do Bloco X, a transmissão está bem complicada mesmo, eles estão mexendo bastante no webservice, ora é layout antigo, ora é o novo layout que nem foi publicado ainda. Durante nossa homologação semana passada o homologador já disse que é quase certo que será adiado até janeiro para postos de gasolina e poucas outras áreas, até março para lojas de roupas se não me engano e similares, e agosto/18 para demais estabelecimentos. Não foi nada publicado ainda, mas foi o que nosso homologador nos disse, e aparentemente irá se concretizar.

Estude o webservice DistribuicaoDFe, e sim, possível com o ACBr.

É obrigatório sim, @Valdeir Caires, me chama inbox q te mando um link do dropbox com o simulador, ele tem 5MB, e não sei se devo postar por aqui o link...

Pode ser enviado sim, eles publicaram que o que for enviado em produção até o dia 16/09/2017 em produção será desconsiderado, que seria pra testar o ambiente de produção mesmo, após essa data não deve ser enviado, e no início de outubro deve entrar em vigor, vide: http://bell.unochapeco.edu.br/lts/?p=3129

Bom dia, desculpe-me pela demora, sim, após as últimas alterações que fiz consigo enviar os arquivos de estoque e redução z, tanto em ambiente de homologação quanto ambiente de produção(devemos aproveitar para testar até dia 16, após esse prazo e até o final do mês de setembro não deverá ser mais usado, pois já não serão apagados os arquivos do banco de dados da SEFAZ). O que acredito que está sendo o problema é o NumeroCredenciamento do ECF, não do PafEcf, apesar da mensagem citar o PAF como não vinculado, seria justamente o contrário, o ECF não vinculado ao PAF, nesse caso, seria o número do credenciamento do usuário do seu programa, que aí sim eles bateriam o cadastro dele com a listagem dos ECF vinculados ao seu número. Para caráter de teste, consigo enviar com NumeroCredenciamento (na tag ECF) como 111111111111111. Edit: No site de validação preciso desmarcar a opção de validar paf-ecf pois não possuo nenhuma impressora em produção aqui para teste, apenas ecf de desenvolvimento. Mas pelo webservice pode jogar como true mesmo. Dentro de alguns dias verei se consigo providenciar uma ecf de cliente para tal teste, mas por enquanto foi possível finalizar essa etapa com ecf desenvolvimento mesmo.

@Otnael Rocha Silva Provavelmente está passando a tag com um valor incorreto amigo, tenta verificar qual é o Número de credenciamento do aplicativo perante a SEFAZ, pela mensagem ele está batendo as informações lá na SEFAZ e vendo que não fecha a combinação informada no XML. <PafEcf> <NumeroCredenciamento>1506XXXXXXXXX</NumeroCredenciamento> <NomeComercial>XXXXXXXXX</NomeComercial> .. .. </PafEcf> Provavelmente após corrigir o valor informado irá passar o xml. Edit: O problema não está na estrutura gerada por nenhuma das duas aplicações, mas sim no valor passado na tag em questão.